My TinyG/Chilipepper setup keeps getting lost. The last two job I’ve run have had the first couple of operations go correctly and then the machine wanders off and cuts somewhere where it’s not suppost to. I hough I might be getting dropped packets on te USB so I replaced the cable with a quality shielded one but still. I’m losing faith in this system. Too much scrap. I verify every job with OpenSCAM but still. Why does it do this Any ideas? I’m ready to scrap the whole thing
What version of everything are you running? Screenshot can show all versions of everything in one shot.
440.14 for the tinyG, using Makercam, OpenScam and Chilipeppr. Thanks
You’re on an old firmware for TinyG. What other versions of EVERYTHING?
When I boot up I reload the firmware into the board. Should I be doing this?
You reload old 440.14 firmware each time? Why?
I’ll Stop. Is the firmware stored in volatile memory?
Just tried it again. The tool on Chilipeppr did not move according to the tool in real life. Something is really wrong. The Board keeps skipping steps and wandering off. Its a bit different every time
Can you please send a screenshot or, even better, a video? There’s no way to help otherwise.
It’s always the x axis if that helps…
Just noticed this
Then it’s your hardware and has nothing to do with any software. If it was software it would be all axes seeing weirdness. There was another guy having issues earlier this week on one axis and it turned out to be hardware.
I’ll look into this
Thanks
It could also be as simple as your current is set too high on that motor and its overheating and shutting down until it cools off and then turning back on.
I have something slightly similar (not using tinyG) and it’s because the driver for one axis picks up noise from another axis and thinks it’s getting movement commands. It’s much worse when the driver circuitry is hot.
@John_Bump I rather doubt that noise pickup id the issue you describe - the on-board interfaces are rather robust and the driver to motor wiring very low impedance - not subject to noise. However, because you mention hot, most drivers have on-chip temp sensors that will shut down operation randomly. Do you have fans blowing on your controller?
@Bill_Dussault You need to load FW 440.20 into tinyG, then we can dig from there. And just like John - do you have a fan or other power dissipation mitigation in place?
@cmcgrath5035 – I’m running an extremely nonstandard setup: analog power drivers that drive the steppers with sinusoids. They dissipate something like 200W each. So, yes, I have enormous fans.
@Bill_Dussault Few weeks ago I had a similar issue, it started with one axis but later it spread to all axes, the cause was noise from spindle cable to motor cables, I use 110V DC spindle.
Before I start troubleshooting, my first suspect was software or controller, but I had the same issue when I switched back to original software and controller that came with the machine.
The machine works fine when I run air jobs with spindle off, when I use 48V DC Spindle and when I separate spindle cable from motor cables.
@Bill_Dussault This sounds exactly like my issue. In my case it really is a chilipeppr problem. Even if @jlauer says it’s not.
Somehow the serial commands are beeing sent in large numbers while the cnc controller is expecting one line at a time.
Because it picks some data feom one line of gcode and some from another, the coordinates are screwed up.
@Mano_Biletsky_Open_M I am not sure what problem you are referring to, Mano, but have to attempt to correct a couple misconceptions you state here that could confuse a lot of folks
Serial Commands: tinyG (and GRBL running on UNO) have input buffers that accumulate serial character strings that become commands. The controller FW, e.g. tinyG, read and act upon commands one at a time, then move on to the next command if there is one. The input to the buffer is managed by ‘buffer fill’ flow control mechanisms. Some Gcode senders use simple hardware protocols such as RTS/CTS, others use coded flow control protocols such as Xon/Xoff.
Chillipeppr goes a step beyond and implements buffer fill control based on tinyG status reports(or GRBL status reports, etc). This provides optimal buffer fill management and control.
The Gcode machine implemented by tinyG is a state machine whose actions are controlled by numerous static and dynamic parameters. It is the responsibility of the Gcode generator, be it a program or a human doing hand coding, to set all the necessary states and parameters before a Gcode command to actually do something (.e.g. move to x,y,z) is sent.
The causes of “coordinates get screwed up” are numerous; electrical, mechanical and coding.
So you are correct, if a Gcode block (Gcode command) is decoded incorrectly, most machines will flag the error and either Halt or flag the error for the CAM controller (in this case Chilipeppr) to make a decision.
Unfortunately, the definition of the Gcode syntax and rules has evolved over time and leaves some situations open to interpretation. Some interpretation issues generate bugs and subsequent bug fixes. That is why it is important to keep the controller FW up to date. Today, for tinyG, that is $fb=440.20.