Forum Replies Created
-
AuthorPosts
-
cmcgrath5035Moderator
I agree with @kiwigrant’s approach, also use care connecting grounds between your logic sifter implementation. Use the input power GND terminal.
Most stepper driver I/Os are in fact Opto-Isolators, the inputs simply anode and cathode of an led. As mush as possible, isolate driver ground noise from tinyG when possible. Check out the Schematics.
cmcgrath5035ModeratorOK, that is strange, I replied to your April 7 but my reply did not appear either.
And I have not seen anything new from you since my April 4 post
cmcgrath5035ModeratorTest, are yyou there?
cmcgrath5035ModeratorSorry, missed thia post a while ago.
Did you get up and running?M3enab pin is an output, not an input. When using Gshield, which was developed for GRBL FW, all motors are enabled/disabled by the GRBLEnab pin which connects to the shield.
Did you flash or compile using the Gshield header files?
cmcgrath5035ModeratorWoa, sorry, I depend on notifications when issues show up and somehow it got turned off.
G2core Probing – Have you seen this wiki item https://github.com/synthetos/g2/wiki/Gcode-Probes#configuring-probe-input
It answers some of your questions and a lot more.
Are you probiing directly from CLI, or using a CAM interface such as Chilipeppr or cnc.js?
cmcgrath5035ModeratorI see over at https://github.com/synthetos/TinyG/issues that your are or were having port connection issues. Did those get resolved?
I ahve no idea what Mojave is, from your description assume it is a recent macOS release.It seems logical that tinyG would bring motion to a stop before reversing direction. How quickly it reverses might be modified with jerk settings.
But 2-3 seconds sounds unreasonable, unless tinyG is waiting for the next command. How do you have flow control configured in CoolTerm and tinyG?
I’d avoid XonXoff, it seems port drivers have become buggy over time.Control environments like Chilipeppr and cnc.js bypass hardware flow control and use buffer fill messaging to improve response.Heat and ticking – an overheated motor will have reduced conversion efficiency (current pulses into motion) at high temps and may exhibit difficulties with extreme micro-stepping. Or the ticking may just be tinyG holding current position while waiting for the next line of Gcode.
I’ll probably need more info on your machine setup. What you describe could also be ball screw binding, for example.
cmcgrath5035ModeratorHere is a link to an old post by someone using a tinyG machine to extrude ceramic paste
https://synthetos.comtopics/3d-printing-with-tinyg-rotational-axis-a-trouble/#post-10855
What you are trying to do is essentially sames as a 3Dprinter that dedicates a motor to feed hard plastic into an extruderI don’t see how spindle speed control could be precisely synchronized to the current velocity of the syringe tip which tinyG will vary according to jerk settings and xyz velocity commands
You might want to scan thru the Issues section on the wiki for similar questions https://github.com/synthetos/TinyG/issues
I have not used cnc.js in a while, but do believe A axis is supported but needs to be enabled.
cmcgrath5035ModeratorThanks for the info, apparently the Wiki is out of date.
cmcgrath5035ModeratorI believe it is a true statement that Gcode does not have a freehold command equivalent.
Gcode does have an M6 bitchange command, not supported by tinyGIn the Chilipeppr environment this can be overcome using a chillipeppr_pause directive in a comment.
Read this
https://github.com/chilipeppr/widget-gcodelist/blob/master/README.mdThat should hopefully work for you.
- This reply was modified 4 years, 7 months ago by cmcgrath5035.
cmcgrath5035ModeratorI don’t think reloading FW is required or desired. AVRDUDE, the core downloader, does a check on the installed image, if it exits without error the FW image is most likely installed correctly and accurately.
As for the startup errors, I believe it is tinyG responding to cnc.js startup commands that it does not understand. Have you tried posting that sequence on a cnc.js forum? I am no expert and do’t have a machine to play on at the moment
Are you attempting to tweak $tr while a gcode file is running? You can’t do that.
cmcgrath5035ModeratorSorry for delay.
I have no knowledge of HSMXpress and limited cnc.js experience.
Here are some more or less generic comments based on reported errors I see
Is your design in inch or mm? Frequently arc errors are the result of lost computation precision, made worse by repeated mm to inch conversions. tinyG uses mm as the native mode, so regenerating your Gcode in mm may help.
Or, changing the post processor to not use arcs will usually eliminate the arc errors.Are you making parameter tweaks then attempting to resume from the recoverable error? That is not likely to work. When such an error occurs, there is still a queue of pre-computed movements waiting to be executed based on the original parameter set. Resetting or power cycling tinyG will recompute the movements then using your modified parameters.
cmcgrath5035Moderator(I sent a message with this same description to Synthetos via the website last week, and received no response.)
Sent via “Contact Us” ? I am supposed to be copied on those, did not see anything. Something there not working right.
I was getting a resumable error when I tried my first Gcode run. So I started changing things in the post processor to address this, as described in various internet posts.
What post processor are you referring to?
And please share your perception of a ‘resumable error’.
What CAM software are you using?(Chilipeppr, cnc.js, Coolterm, etc.)Do you have limit switches attached and enabled? Flashing red usually menas limit switch activated, causing a had stop of tinyG, recoverable only by reset (push button or power cycle). You could disable limit switches while you experiment with motion.
Spurious limit switch firing is usually attributable to wiring issues. Can you describe how you have the switches connected to tinyG?A look at yur parameters might be helpful.
Run $$ in a console, scrape the output to a text file, put the file on a Cloud share and provide a URL.cmcgrath5035ModeratorIf you received a return address, I think safe to assume you will get a replacement back.
cmcgrath5035ModeratorSpec says 2.5A
cmcgrath5035ModeratorI have no direct experience with your situation, so most of this is a bit of conjecture on my part.
My read of the tinyG Tuning process (https://github.com/synthetos/TinyG/wiki/TinyG-Tuning)
implies setting the current pot somewhat higher than a setting that produces minimal skipped steps. The problem is that the optimal setting this way is highly dependent on the load on the spindle – optimal for pine will not be the same as for aluminum or foam board.
Setting the pot for ‘minimum noise’ is not likely optimal. I would expect perceived noise to always be minimum at max pot, but that does not necessarily translate to maximum energy transfer to the milling process.
As the motor core heats up, less magnetic energy is generated by power pulses.
Perceived ‘noise’ from the motors is a combination of the frequency with which pules of energy are sent and the duration of those pulses. The higher the pulse current setting, the shorter the pulse will be. But once a stepper has made it step movement, excess current during the hold position phase of the movement cycle will heat up the motor core.Damage a motor with bad commands?
Maybe, but I find it difficult to say any stall could bend a motor shaft (that would be bad). Core heating could change ‘noise’. Repeatedly ramming a motor into a stop might tend to loosen a pulley? (belt machine)? check your Allen set screws.To really damage a motor the heat dissipated in the winding would have to be high enough to melt a winding wire and perhaps fuse it to an adjacent one.
Not much help, probably
-
AuthorPosts