I've been banging my head against the wall on this for about a week now. I just bought a Creality Laser Falcon laser engraver, and I've been trying to adapt a generic GRBL post processor to work with it. I say "adapt" because it didn't work out of the box. And I'm doing this because I haven't been able to find either enough info about the engraver to know what it's compatible with, or a direct reference to it in the list of available post processors.
Anyway.
I finally found the problem today, after comparing the rendered g-code from Fusion against that from LightBurn. The problem is...CRLF. The line endings used by Windows (\r\n, or CRLF) are different from the entire rest of the computing world, which uses LF (\n) only.
Now, I've used Notepad++ to manually convert line endings on a Fusion-generated file, and it works like a dream. BUT...I don't love the idea of complicating this process even more.
Is there a way to modify the post processor itself to output LF-terminated lines, instead of the Windows default of CRLF?
I'm attaching two sample files to show the differences (hint: you'll need to be able to see normally invisible line-ending characters).
Solved! Go to Solution.
Solved by GeorgeRoberts. Go to Solution.
So...I actually had to do some Google searching to educate myself about what you were referring to. I had no idea this was a thing..
To answer your question; no idea. I'll have to raise this with one of the post developers on Monday
Hi!
You can try to oben your generated nc Code at the end of the Postprocessor with a script that replaces LFCR to LF (Unix)
Javascript :
or here for Python:
https://www.freecodecamp.org/news/python-new-line-and-how-to-python-print-without-a-newline/
newline = ''
I have done this with other things in my nc code
Right; that's what I'm doing now. I had hoped to minimize the number of steps I need to take in transferring my model out of Fusion to the laser though, so I was hoping to modify the post processor to handle this for me. After all, the post processor is a set of callback implementations written in JavaScript...if the docs were better, I'm thinking I could override / reimplement the writeln() function to handle this.
I've also sent a message to Creality about this, since it appears they've implemented their own gcode parser for the Laser Falcon (the firmware is something they homebrewed, from what I gather on their website). G-Code really shouldn't be sensitive to different types of whitespace, especially since you can jumble the commands together with no whitespace if you so choose.
What I'm really after is a more correct, less hackish solution to this problem than I have now.
Good morning,
I believe you can just add this code to the start of the onOpen function in your post:
setEOL(LF);
There are several different options supported for end of line. Here is a snippet from our API manual:
George Roberts
Manufacturing Product managerCan't find what you're looking for? Ask the community or share your knowledge.