I have had an issue a few different times with arcs not moving correctly.
From what I can tell it seems to happen on fairly small arcs and rather than moving along the intended arc segment the machine will travel on the rest of the circle that the intended arc would be apart of. It's as if it takes the opposite of either CW or CCW arc that it should be. This has most of the time resulted in a move that goes crashing through and ruining the work piece or running into clamps.
It believe it will consistently do it if the same program is re run, but if the same geometry is used and the program regenerate with slightly different tool paths then it will sometimes not have issues in the same spot as before.
I know I can set CamBam, or other CAM software to convert arcs to line segments but this can produce very large files with many more lines than are needed, making it more difficult to load and smoothly run in ChilliPepper.
I have a Shapeoko 2 and have been using CamBam with either default or Mach3 post processor, using ChilliPepper for control, and have the latest firmware (440.14) installed.
Just wondering if there is a setting(s) that I should adjust or a different post processing format for arcs that would help to avoid this.
A settings issue does not seem likely as you describe the behavior, but anything is possible. As described, it would seem to indicate a bug or geometry induced math error.
Most efficient would be for you to post your Parameter set and a Gcode file known to have triggered this. Using dropbox or similar cloud resource is easiest to deal with. See
If you run the Gcode via the CP simulator, does the plot follow the correct path?
If you know what line number (even approximately) in the Gcode file triggers that that would speed analysis.
Small arc movements were fixed in newer firmware. Are you sure you have the latest firmware? I too have seen issues in the past with small arcs, but my understanding is those got fixed. I have not personally tested that though.
I initially had the issues a while ago and didn't connect the issues to an error with arcs, as I had been having some other problems with noise in some wiring that have since been fixed.
I am running 440.14, I believe this is the newest?
Unfortunately both previous times I had the issue I just ended up running the job again with different gcode file, and didn't save the one that didn't work.
The most recent time that this just happened I again wasn't thinking of having others debug and over wrote the file to complete the job I was working on.
I just went back to try and reproduce it and I have yet to get it to. I will keep trying to see if I can get it to show up again.
I'll try changing those parameters and see if that will solve the issue.
I initially loaded the default parameters that were included as one of the presets in tgFX. I loaded those and did a basic tuning of distance movements. I still need to do a more complete fine tuning.
I haven't changed those, at least intentionally. I did mess a little bit with the Z axis speeds and jerk as I was having some issues with it stalling only on positive moves and only during running a program but not manually. They seem to be fine where they are now, I could probably clean and re tune alignment and get more speed out of it.
When I upgraded the firmware I did a capture of all parameters, then used that to manually go back and put everything back to where I had it.
I normally work on inches as I am much more familiar with it, I used the mm output on here as that's what I have seen most others use when posting. Maybe there is some sore of rounding/converting error when manually entering between the in vs. mm that would cause the 5004 vs 5000?
Hmmm. I am a bit suspicious that your parameters were borked a while ago by tgFX.
I think I have to recommend a factory reset procedure to get a clean set of 440.14 parameters, after which you will need to reset your motor and axis parameters again.
But first - what are you using on PC to run your machine:
OS - Win__, Linux, MACOS ?
Interface SW - Chilipeppr, CoolTerm, other? You can no longer use tgFX.
Will just reloading the firmware reset everything to factory or are there additional steps that need to added?
I am running Win Vista
I have been using only Chilipeppr for a while now. I initially used tgFX, then used a mix of tgFX and Chilipeppr depending on which seemed to be working better at the time, and have since gone completely to Chilipeppr as it seems much more stable and reliable than when I first tried it.
To reset parameters, I would suggest you send a $defa=1 command from the CP Serial Port Console. This resets parameters in EEPROM to 'factory setting', a set of parameters compiled into the firmware
Reflashing the tinyG with FW 440.14 would have the same effect.
In both cases, the tinyG parameters will then need to be manually restored to match your machine. Use either the Serial Port Console command window or the configuretinyG widget.
Running Windows, your could do the same process using CoolTerm, the choice is up to you.
TinyG runs based on parameter values stored in EEPROM. The initial values in EEPROM are loaded as part of the FW install process. Subsequent changes to parameters make from the command line or by programs such as CP change values in EEPROM, not flash.
The problem of corrupt parameters we are chasing are most likely with the values in EEPROM, not flash
I highly recommend you NOT try tgFX anymore. While some basic functionality may still work properly, there are know issues between the final release of tgFX almost a year ago, and FW440.14. Work on tgFX has been terminated.
Julian
We never heard back from HCamp, so have no update on if his resetting tinyG to defaults and entering correct parameter values helped.
Note that the value of $ct in his parameter list was just an indicator of something very wrong. It might help if you added your full parameter dump to the Dropbox record.
I downloaded your Gcode file. Way to big for any manual review and detection of issues, but will be useful to debug none the less.
I first loaded your Gcode into the CAM generator/simulator I use, which is a backend to CAD program QCAD. That simulation displayed some bizarre results, including numerous large circles and small, including the one shown in your picture. Here is a screenshot :
I then loaded the Gcode into my CP (Linux, Chrome) It took quite a while for the simulation to render, but it finally did and appears to be correct, no large circles. I will note that the CP browser seems seriously loaded down by the Gcode file - any attempt to zoom or make a 3D perspective change trashed the entire browser window. That might be a 3Dviewer issue, or ??
So, nothing definitive in this so far. I could guess that tinyG is making the same error that my QCAD simulator is making, but have no idea why that would be.
But when I use Sheetcam to create my gcode, if I use outside or no contour, it works fine on the tinyg. The moment I use inside contour, it no longer follows arcs as normal and will instead use a series of very course straight lines, or skip circles all together.
I will try to refine the problem, and start a new thread with it.
djdaudio: First check will be FW version, there have been almost continuous refinements to the handling of arcs and the somewhat strange arcs that are generated by some packages. FW 440.14 is the current best choice, but there are still corner cases being worked.
These issues are often resolved by tweaking the backends of the Gcode processors, using less aggressive minimal arc lengths, etc.
This topic is from the original forum (August 2015). Your reply starts a new discussion linked to it.
