Hey all,
besides too little RAM which causes swapping, as explained above, the bottleneck could be the serial connection between the Raspberry Pi and the AVR mainboard with the stepper drivers, through which all the commands are sent.
Hey all,
besides too little RAM which causes swapping, as explained above, the bottleneck could be the serial connection between the Raspberry Pi and the AVR mainboard with the stepper drivers, through which all the commands are sent.
What matters here, are the g-code motion commands in your toolpath. Thatās what is used and transmitted and finally translated into stepper movements. If you have a command that says straight move from x1,y1 to x2,y2, that is very few data to transmit, in comparison to say, move a million times one thousands inch at every step, because your entire file is converted from pixels of a photo. That is very much more data to be transmitted in a certain time, and could hit a transmission bottleneck depending on how the interface capacity is dimensionated.
You should be able to see the difference by simply looking at the size of the g-code file. A file that consists of a photo converted into g-code movements is usually many, many times bigger and full of extremely short movement commands.
I am having the same problem running Lightburn code it will migrate and stutter, please help⦠or how do I return to 1.0.9
Have you found the solution? I have wasted many hours trying to burn on canvas, I do not like vcarve as a solution Lightburn is looks better, I believe it is the algorithms, I have used gimp then bring into Lightburn, if I do not use Pass thru it give a warning that due to over scan settings cut may be out of bounds, the g-code for those are like 10,000,000 lines and plus but for the pass thru and no warning they are under 3,000,000
I am interested for a better solutionā¦
I never figured it out and 1F didnāt have any suggestions other than going back to 1.09. I did go back to 1.09 and that fixed another problem I was having with the laser so I am hopeful. I just finished a big project so I am about to get back to this. I have burned numerous svg projects since that happened and havenāt had any issues. My working theory is that there was something with how the pictures were set up in lightburn (my stuttering file was all pictures). Iāve also heard that having too many files in the controllers memory messes things up so Iāve deleted all but two. Iām going to try again this weekend and see what happens.
Even if it works, itās still frustrating. Iād like to update the firmware to the latest version so that my spindle will work automatically (it doesnāt do that now with 1.09 even though Iām told it is supposed to) but Iām afraid of things messing up again if I update.
Btw, I get the out of bounds warning on everything I make in Lightburn and it is never a problem with anything else.
Iāll be reflashing my controller back to the earlier firmware however keeping an eye to see if the next firmware will catch this glitch if you spot it or if I do letās keep each other informed thank you
I had this problem a while back Loosing X home position X50 Journeyman turned out to be the format of the picture file itself. When I got the same picture in its original format, I did not have the problem. If I printed the picture and scanned it back to a high resolution file I did not have the problem. The pictures I had the most problems with were one that had been sent by SMS text some time before I received them. SMS compresses the image file. Hope this helps.
Not sure all pictures I burned I had manipulated in photoshop and gimp before importing into lightburn
I too have issues when using lightburn. When burning an image file the machine stutters and loses all xyz coordinates and moves very erratically, enough so that when it lost the z it moved and broke the mount for the laser. This particular file I was able to do a trace around and turn it into a vector which the machine would run perfectly. When loading the image file it takes several minutes to load before i can even run the program. When I contacted onefinity they said :I need to modify the image file so its not so large. The only way I can think of to do that is to change the DPI, but if I do that wont I lose some definition. So basically I am thinking that onefinity is incompatible with burning a lightburn image file and have to change to a different laser program if I cant modify it. Does anyone have a work around? I have the x50 woodworker running 1.2.1 software.
Hello im having same issue. Did anyone figure it out
How do you fix it?
I went months without an issue and am now having it again. What should be a couple of very simple svg outline files (from Etsy) but they are causing the stutter again. I am using Vectric this time. Two files are about 1.4 MB and the other is 2.2 MB.
When I look at the vectors of the lines there are a ridiculous amount. Seems like overkill. I donāt know how to fix that other than retracing the line but man that is tedious work.
Sounds to me like you need to convert the nodes to smooth curves or lines.
Thereās an IDC video on the subject.
I didnāt do that! It really sucks. But I did find a solution.
I suspect the first thing had the most to do with it, but either way, I was able to do three successful test runs (one on each file) and re-did the final burns on the wood. They all came out great with no issues! Now it makes me wonder if the BB controller can upgrade RAM or is it my computerās RAM. My computer has 16GB of RAM, that should be enough, right?
For the future, I will be taking a look at the final g-code files and trying to keep them under 1 MB. My last resort would be retracing but I hope to not have to do that again. I have done it many times and I hate it.
DXF is a ālowest common denominatorā file interchange format. It does not support bezier curves and approximates them using lots & lots of tiny line segments that are close to the curve but not quite. (Thereās a whole bunch of calculus that explains this but you donāt need to know why, just that itās the way it is.)
DXF made sense back in the early days of CAD/CAM when Autodesk was trying to become the predominant player. It allowed people with different software to share files. SVGs came later and weāre designed to be both portable and more robust because compute power was greater & cheaper than when DXF was created.
BTW, Vectric has a smoothing function (fit curves to vector) so you donāt necessarily have to retrace designs with tons of nodes.
Ive never used the smoothing function. Iāll have to find a video on it.
Check this out
Secret to Fixing DXF Files for CNC Projects