LOL!! Do I get a Badged for that???
Thank you for your help.
I really appreciate!!
Thanks for cooperating to identify the bug. I opened an issue in the Firmware project to capture it.
I’m not sure if I should say “you are welcome” …
I wish I knew how to program, so I could help more.
Great working isolating the issue so well! This looks like a strange one to me. Could it be something to do with a buffer overflow happening? @blurfl are we seeing any warnings when it stops or does it just stop?
No warnings, it just stops. It’s notable that the gcode parameters have 15 digits of mantissa…
With ‘Buffer Gcode’ turned on and ‘Truncate Floating Point’ turned on as well, the file runs properly.
awk '{ print length($0); }' ULTA\ CNC\ E.nc
Many lines in the file are longer than EXPGCODELINE which is defined in Config.h as 60
#define EXPGCODELINE 60 // Maximum expected Gcode line length in characters
// including line ending character(s). Assumes
// client will not send more than this. Ground
// Control is currently set to 60. NIST spec allows
// 256. This value must be <= INCBUFFERLENGTH
Looking in the log, GC is sending the full length of each line. Should GC be catching this line length issue and alerting when the file is first read? Maybe it could offer to truncate parameters to fit the limit?
Looking through the code, EXPGCODELINE is never used…
@bar The interesting thing is that if you run the entire Gcode it will stop at the E ,
if you break the gcode like i did, I was able to cut everything but the E…