I wiped the EEPROM as suggested and then did full calibration. Tried cutting the gcode again and had same issue. Just to be safe I wiped EEPROM again, then Flashed 1.2.4 firmware, then full calibration, as still had the same problem.
Looking very closely at the movement of the sled I figured out what is happening. The G2 cuts are turning in the wrong direction. Instead of going clockwise they are going counterclockwise.
In the first image above the “G3 X-9.9375 Y-7.4219 I0.125 J0” cuts a quater turn counterclockwise. This results in the end of the cut being 0.75" to left of where it should be. This board compensates for this by doing G0 movement, to the beginning of the next cut, but because it moves so fast it ends up in a distorted cut which is why it looks sort of rounded. The same thing happens on the next G2 but to lesser extent because the arc has much smaller radius.
The Gcode is correct. The firmware is executing it wrong.
Fusion360 has an option to interpolate G2/G3 operations is the Post Processor named “Disable Arcs”. When I ran new gcode it cut perfectly. In fact it cut way better compared to when G2/G3 was working previously because it reduced the feedrate during the arc.
So I have a work around but would still like to see this fixed. Should I report this on GitHub?
Glad to hear that your workaround ( “Disable Arcs” in Fusion360 Maslow processor, right?) has you running again.
The issue appears to be in the way that the arc() function handles the G2 cut; the G3 cut is correct. I’ll open an issue to address it.
Firmware PR#477 addresses this problem. With the patch, the Offending Gcode listed above runs correctly. The comment to the PR also contains a shorter sample of gcode that demonstrates the issue and the fix.
@tinker, I’m sorry that my earlier PR introduced the error and caused you so much frustration. Thank you for your patience and the information that brought it to light and helped to correct it.
@blurfl Yep sorry I copied the wrong line. Meant to say the it was the “G2 X-8.4375 Y8.3281 I-0.375 J0” cuts a quarter turn counterclockwise. Thanks for the quick fix. Any idea when this might get committed to Master so I can update the firmware?
Any update on this?
Sounds like the same issue I hit. Updated my GC to [EDIT] 1.25 and tried to run it with the TLE5206 & firmware 1.22 - leading to chaos.(failed motor tests, wrong rotation directions, etc)
I didn’t see this thread till today so I’ll try the wipe EEPROM, but failing that, I’m not sure what firmware I should flash, or if I should leave it at 1.22 and try to figure out how to downgrade to GC 1.21.
That’s puzzling, I just downloaded the file from this link as above and it compiles correctly. No need to move any files, just double-click on cnc_ctrl_v1.ino to open it in the Arduino IDE and as a double-check note that there are many more than one tab across the top of the IDE window.
As per a different thread, I moved the header files from \utility into the same folder as cnc_ctrl_v1.ino and changed the include statements to remove the “utilities/” before them.
That got rid of the include errors, but created a slough of “String(float, int) is ambiguous” errors - so that’s not right.
The header files are there, but for some reason the arduinoIDE doesn’t find them when it tries to compile. Perplexing.
The cut on left went clockwise and the right one went counter clockwise.
This was not an issue for me. Did not get any errors compiling or uploading the firmware.
AFAIK Firmware and GroundControl must match version numbers as various new features must be implemented simultaeously in both. My calibration settings did not transfer during initial update from 1.22 to 1.24 and I could not move sled without errors. Wiping EEPROM destroys all saved settings, so is a good fresh start, but requires recalibration and checking all Groundcontrol settings. e.g. Advanced settings -> Position Error Limit: Was not correct. This setting does not appear to be stored in the groundcontrol.ini and may be stored in EEPROM.
I could not downgrade. Arduino IDE reported sucessfully upload but the board would reboot keeping 1.24. I think this is why @blurfl suggested doing the EEPROM wipe before downgrading but I did not try this as I found a workaround in Fusion360.