Hi!
Somehthing has changed in 1.7.07 in the CGode exported files, that they no longer works in my AtomStack or is shown in LaserGBRL.
If you open the file in WorkPad, you can see the lines are not separated, but they are on a long line.
Thank you for reporting this.
Testing to attempt to reproduce this behavior now.
I’ve tested Save Gcode with both 1.7.04 and 1.7.07 on both a Mac and a Win 10 device and I can’t reproduce the behavior.
Which Version were you using before upgrading to 1.7.07?
I’m going to load the NC file into Wordpad and see if the encoding changes.
If you’re willing, please attach the GCode file in a response so I can confirm the change to the ‘end of line’ character with Notepad++
Loading the .nc file into Wordpad in Win 10 and saving it changes the end of line character from LF to LF CR.
Loading the .nc file into Wordpad looked fine.
Are you using the .txt file extension in Wordpad - I’m attempting to reproduce this so I can report the behavior.
The files are made with 1.7.06 & 1.7.07 in windows 11.
PS: I have problems uploading the files… the .txt file is really a .zip one with both files inside, renamed from .gc to .txt for your convenience.
1 Like
I’ve inspected both of these files, and I don’t see any difference in end-of-line handling. They both use LF (linefeed) the same as 1.7.04 and 1.7.07 tested here on 1.7.04 and 1.7.07. For fun, I just opened a GCode file from LightBurn 1.4.01 and the LF end of line is the same.
It looks like Wordpad was removed from Windows 11 Version 24H2.
My Windows 10 Daily-Driver is a 22H2 build so I have Wordpad.
A GCode file loads ok with the expected line breaks, but when I save it, Wordpad changes the end of line From LF to LF CR.
Notepad was adjusted in 2018 to accept either end of line:
I’ll download the zipped file to my Win 11 tablet and test line ends.
It does not yet appear that LightBurn has changed the way the GCode is saved.
Are you using Copy / Paste in Windows 11 to move the GCode from Notepad into LaserGRBL?
My fault, I’m stupid, I uploaded the same file.
GGFiles.txt (13.0 KB)
Rename the .txt to .zip and extract them.
Oh, for my X30 laser it export as .gcode (not .gc as for the X40 that does not recognice the .gcode extension), and the file .gcode is fine.
So it is only not working (as used) when exporting as .gc
I downloaded the latest version of LaserGRBL onto my Win 11 tablet.
I downloaded and installed lightburn 1.7.07 on the same device.
In LightBurn, I drew one rectangle on layer C01 (Blue tag)
I saved the lbrn2 file.
I exported the GCode From LightBurn 1.7.07
I made a duplicate copy and renamed it by adding ‘Wordpad’ to the filename.
I opened the duplicate copy in Wordpad and saved it.
I opened both files in Notepad++ and enabled ‘Show End of Line’ characters.
View - Show Symbol - Show End of Line
The renamed duplicate had CR LF line ends and the file directly from LightBurn did not.
I renamed both files by changing the suffix to .GCODE
LaserGRBL only recognized the Original file from LightBurn and loaded it successfully showing the rectangle I had drawn in LightBurn.
LaserGRBL did not recognize the file that was modified by Wordpad to have CR LF line endings. It wouldn’t even display it as an option to Open in LaserGRBL.
I will review your most recent files.
As you can see, these files are not identical.
LaserGRBL does not recognize the .gc file renamed as .gcode
And my laser does not work with the .gc file (it reads it, move a bit the laser head without turning on the laser and return).
Tested in 2 different computers. Both generate the same strange files.
Reinstalled .06 and it works as expected.
No argument here. They are different.
A Custom GCode device profile is being used. It’s still labelled ‘Experimental’ in the Custom GCode device set up process.
I have reproduced the behavior with the absent LF characters.
I’m escalating this to the dev team now.
2 Likes
I am using a custom one, because we were discusing a way to make the Atomstack X40 work (there is a thread about this somewhere). The translating movement were way slow, and a custom with some tweaks make the movement faster.
2 Likes
I have tested further and confirmed the unexpected behavior.
Someone on the Dev team has acknowledged the issue on our internal channels.
I will continue to follow and share updates as this moves forward.
Thank you again for reporting this. It’s greatly appreciated.
3 Likes
Fixed in 1.7.08
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.