First day testing Snapmaker and I had already run into a conundrum. Everything seemed to be correct, but the machine was sometimes reporting completely wrong project sizes. It took me some time to figure out what the problem is, and I think I managed to nail it down to incorrect boundary calculations during import where the gcode includes relative coordinates.
Project: 40x10mm square, positioned at [0,0], with 0.5mm fill interval. The generated gcode uses G91 (relative movements) with X-40/X40 and Y0.5.
Import: when the file is loaded, the machine reports a size of ā80.0 x 0.5 mmā. That is, it seems to only look at the numbers in the file, ignoring the fact that it is relative coordinates. So, the minimum coordinate detected is X-40, maximum X40 (making a diff of exactly 80.0), and Y only has 0.5.
Run: Boundary check goes indeed to negative X-40, but once it starts, the laser seems to positions itself correctly and move correctly during the run.
Is this just a bug in the FW (1.10.1) or is there something I am missing?
Lightburn uses relative moves in some modes, and Iāve never been able to run boundary in the touchscreen either. Not a huge loss since I can move the origin and just measure carefully,.
Apropos origin - when I open a file from USB, the origin is always reset to somewhere in the middle - is there any way to make it remember for the next time? I plan on making a contraption to make sure I always know where it is when I place materials, because Iām mostly going to be printing on pre-cut stuff and precision is of utmost importance. Any other suggestions to achieve the latter are welcome.
You could embed the necessary gcode in the file. Start with a g92 and set your own offset.
Lightburn allows generating gcode that starts at the current location, wherever that is. Could make use of that after issuing a g0 move to known coordinates in native space
The touchscreen will reset the work origin each time though. Letting it go to center is fine if the file moves the origin shortly after
Do you print directly from LIghtBurn via USB? And it then moves exactly where it should on the canvas when you start the job? I guess that makes things easier with regards to exact placement.
No, you actually canāt do that either. Light burn is written for standard Marlin, which can accept a 254 character serial buffer. But thatās not what happens with this STM32 clone chip. It only supports four lines in the buffer. So what will happen is when the planner queue fills up and then no more commands get processed and then the serial queue fills up, The main controller will stop accepting new commands but light burn will continue sending them anyways because itās expecting 254 characters.
Long story short it will break and probably in the form of motion will stop with the laser on in a single spot.
I suspect it would be easy to raise the serial queue length to fix that issue since this chip is not being taxed. But thatās just one of the things I havenāt been able to try yet.
I misremembered the length, itās 127, but close enough.
I havenāt tried it with the absolutely latest release, there have been some snapmaker specific changes related to M9 with the generated gcode. Iām not aware of a change relating to the serial buffer for sending it, but itās possible.
So, I finally got to try this option, and it was much better. Imported into Luban, it was placed on the exact spot where it should have been and Luban calculated correctly the boundaries and everything (except for the preview). Even the fill was printed correctly.
One thing I noticed though is that the speed when executing a drawing from Lightburn is much higher than the when creating it within Luban. Are their scales different? Couldnāt find any discussion about that. Even when I put the speed to 10% in Lightburn, it seem to go much faster for instance around a circle (although, the latter might be due to different sampling rate of the arc).