Corrupted firmware/groundcontrol using different versions weird G2/G3 cuts

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?

I must be misunderstanding, I think the G3 code is supposed to cut counterclockwise. Are you saying that the firmware cuts clockwise for this line?

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.

3 Likes

@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?

1 Like

We’re on a monthly update cycle, so the next official release will be December 1. Until then, here is a zip file containing a corrected version of Firmware-v1.24:
Firmware-v1.24-Issue-476-G2-gcode-error-corrected.zip (84.9 KB)

1 Like

Great thx @blurfl. WIll test this out this week.

1 Like

Please do, and let us know if it works - we can do an early release if it’s good.

1 Like

I just want to bump this. Any progress?

Yes, there was a report of a successful test, so I think we should be good to
merge this.

David Lang

1 Like

It was confirmed by @strebor here, so it seems good to go. :+1:t2:

1 Like

Sorry for lack of reply. Was all set to do a test cut but ran out of time as I needed to get a project done.

Made up gcode to test all iterations of clockwise and counter clockwise cuts:

(TEST-G2-G3)
(T1  D=0.25 CR=0 - ZMIN=-0.2 - FLAT END MILL)
G0 G40 G90
G20

(CLOCKWISE)
T1 M6
M3 S10000
G0 X-0.3 Y0.025
G0 Z0.25
G0 Z0.125
G1 Z-0.175 F13.
G1 X-0.3003 Z-0.1789
G1 X-0.3012 Z-0.1827
G1 X-0.3027 Z-0.1863
G1 X-0.3048 Z-0.1897
G1 X-0.3073 Z-0.1927
G1 X-0.3103 Z-0.1952
G1 X-0.3137 Z-0.1973
G1 X-0.3173 Z-0.1988
G1 X-0.3211 Z-0.1997
G1 X-0.325 Z-0.2
G1 X-0.35 F20.
G3 X-0.375 Y0 I0 J-0.025
G1 Y-0.5 F30.
G2 X-1 Y-1.125 I-0.625 J0
G1 X-2
G2 X-2.625 Y-0.5 I0 J0.625
G1 Y0.5
G2 X-2 Y1.125 I0.625 J0
G1 X-1
G2 X-0.375 Y0.5 I0 J-0.625
G1 Y0
G3 X-0.35 Y-0.025 I0.025 J0 F20.
G1 X-0.325
G1 X-0.3211 Z-0.1997
G1 X-0.3173 Z-0.1988
G1 X-0.3137 Z-0.1973
G1 X-0.3103 Z-0.1952
G1 X-0.3073 Z-0.1927
G1 X-0.3048 Z-0.1897
G1 X-0.3027 Z-0.1863
G1 X-0.3012 Z-0.1827
G1 X-0.3003 Z-0.1789
G1 X-0.3 Z-0.175
G0 Z0.25

(COUNTERCLOCKWISE)
G0 X0.3 Y0.025
G0 Z0.25
G0 Z0.125
G1 Z-0.175 F13.
G1 X0.3003 Z-0.1789
G1 X0.3012 Z-0.1827
G1 X0.3027 Z-0.1863
G1 X0.3048 Z-0.1897
G1 X0.3073 Z-0.1927
G1 X0.3103 Z-0.1952
G1 X0.3137 Z-0.1973
G1 X0.3173 Z-0.1988
G1 X0.3211 Z-0.1997
G1 X0.325 Z-0.2
G1 X0.35 F20.
G2 X0.375 Y0 I0 J-0.025
G1 Y-0.5 F30.
G3 X1 Y-1.125 I0.625 J0
G1 X2
G3 X2.625 Y-0.5 I0 J0.625
G1 Y0.5
G3 X2 Y1.125 I-0.625 J0
G1 X1
G3 X0.375 Y0.5 I0 J-0.625
G1 Y0
G2 X0.35 Y-0.025 I-0.025 J0 F20.
G1 X0.325
G1 X0.3211 Z-0.1997
G1 X0.3173 Z-0.1988
G1 X0.3137 Z-0.1973
G1 X0.3103 Z-0.1952
G1 X0.3073 Z-0.1927
G1 X0.3048 Z-0.1897
G1 X0.3027 Z-0.1863
G1 X0.3012 Z-0.1827
G1 X0.3003 Z-0.1789
G1 X0.3 Z-0.175
G0 Z0.25

G0 Z0.25
M5
M30

Will test this weekend to confirm @strebor’s results.

2 Likes

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.

I tried the wipe, but am still getting L&R motor fails on direction 1. Moving on to updating the FW to the on @blurfl posted above…

The FW-v1.24-Issue 476 zip file that @blurfl posted above seems to be missing libraries (like servo.h) - is it safe to assume that if I hunt them down from previous builds, they will be fine?

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.

That’s what I did too.

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.

Not sure where that is, but moving files isn’t necessary with the Arduino version of the firmware. As you’ve found, it prevents the files from compiling.

FWW - The last test I ran was on FW 1.23 with GC 1.22. I saw no issues. Has anyone tried going back to GC /FW 1.22?

Thank you

OK, The issue is fixed for me. Uploaded the firmware provided by @blurfl in this post and ran my test gcode. Everything came out as expected.


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.

2 Likes

Thanks for testing the fix. I think it’s ready for a release.

2 Likes