I decided to start this thread as I first posted in the firmware update. This is not, as far as I can tell related to the firmware update at all.
To recap; when using Lightburn with Jarvis, stucki, or ditther options the machine “stutters” (the best description I can think of) as though something is binding up.
I have changed scan angle from X axis and ran it in the Y axis, but had the same problem, just now it was on the Y axis. I have tried several different photos, and settings in DPI as well and even trying to scan at a 45 degree. I took the same photo and through it at Vetric as I have their laser module and set to ditther with the same line spacing and ran that file with zero problems.
I have reverted to the previous firmware, then back to the newest firmware as that was not the problem.
I have at this point proven (to myself at least) that the problem is not the machine, or the photos. I sent an email out today to Lightburn support with a copy of the gcode file that Lightburn made that was giving problems. Now to wait for a reply.
You might want to check out this video posted by the 1F team.
I remember reading a post on this forum with a similar issue as to
what you are having. I believe there was a problem with too slow
of a speed setting or mm to inches mixed up.
I hope this video helps you out.
Didn’t know about the updated video. Thanks!
I gave it a watch, but doesn’t help.
I had been running at 35 and 40 inches per minute with out issue, now there is issue. I have been burning tiles. Even switching to metric to try and make sure there was no conversion issue did not help. I went back out this evening and tried at 70 IPM, but had the same problem.
Using the Vetric Laser module set for ditthering at 40 IPM for speed I have zero issues. I reduced the speed in Vetric down to 30IPM and it ran with no problems. It seems there is something here that I am missing, but for the life of me I just cant figure it out. I’d be happy to try and send one or two of the files I am using to see if anyone out there can figure it out, or see if it is just me missing something.
I am having the same issue, the only way I can get mine to work is by making the file smaller. By changing the DPI. However, that’s not the way I’m wanting it to look, if you find anything out, please let me know.
I think I might have an answer. I think it might be a RAM (memory) issue with the laptop being used. Mostly not enough RAM. I have a little stand alone laser, the D1 from Xtool that I also use. Using Lightburn I noticed that I was getting stuttering with it as well on some files, but if I lowered the DPI it would stop stuttering and run properly. My leading theory right now is the higher the DPI, larger the file, the laptop is running out of RAM and struggling to keep up. I am going to try this out with an older laptop but with more RAM to test it out sometime in the near future.
Keep in mind, I may be completely wrong about this. lol. This is just my theory.
I am now having this same issue with trying to burn with Lightburn. It was doing it a month ago then stopped without me changing anything. About 2 weeks ago I did change my jerk settings to Mitz’s recommendation of 15,000. Now it did it again while doing a test burn. I wouldn’t mind it so much except each time it does it, it loses/changes the X and Y home. I decides to let it run and it did it again about 10 minutes later.
It only happens with my machine when using the laser, everything else works without jerking or losing it zero. So, my thinking it has to be something between the laser and the controller.
Agreed, I’ve never had this happen when using the router. I’m wondering if it would still happen if I changed the controller to router (I move it over to laser for laser operations) and run the same file.
Re-ran same lightburn file - stutter
Same file but switched Tool to Router- Stutter
Same file but created in VCarve - no stutter
Ran new lightburn file - no stutter
So given that, I have no idea what caused it or how to avoid it in the future. I don’t know enough about gcode to know if the program created something the machine didn’t like.
One thing I found interesting, that file in Lightburn took the computer about 12 minutes to process before it would let me hit start. The same file created in VCarve took about 20 secs to process.
So I did a whole bunch of laser work this weekend after re-downloading the Laser Configuration to Lightburn and changing S-Max to 1000. I ran about 35 small jobs of svg files, all went great. I did a couple of image burns and I still haven’t figured out what the right settings should be so they looked terrible but there was no stuttering during those.
I then re-ran the Trial file without changing anything. It started stuttering again at the same spot, which is about 30 seconds into the third picture.
So, it would seem that there is something wrong with that file though I have no idea what it could be. I made it the same as other trial files I’ve made which is to copy/paste the first image a few times then select each one and change the speed/power settings to see which one looks best.
I’m giving up on burning images for now but I will come back to it in a week or two, once the frustration goes away.
BTW, after I ran everything I realized that I still had the tool setting on Router, rather than laser. Everything still ran great other than that one file so I wonder if it even makes a difference.
This issue was never fixed. Unfortunately, 1F support didn’t really offer anything to help either. I was able to run 30-40 different laser jobs without an issue so it had to be something with that file in particular. I still have no idea what. I’ve deleted it and will try again another time.
Now that I’ve gone back and thought about it, each time it happened was when I was trying to laser engrave a picture file. Maybe the way the file is processed? Though I’ve used multiple for,acts to try to get it to work (VCarve, lightburn, ImagR, etc). Hopefully it works at some point because that is something that I would like to be able to do. Svg files work great though!
Aiph5u
(Aiph5u (not affiliated with Onefinity))
16
Hey Dave,
I just read this thread and there were some suggestions towards RAM (random access memory) limitation. As you maybe know, RAM is the only memory that a CPU can access directly, the CPU computes and changes the contents of the RAM directly. So when you load a file, usually it’s good when the RAM on your computer is large enough to hold the file entirely. If it can’t, it will try to swap out parts of its memory into a swap file or a swap partition. This is called memory paging. On the Onefinity Controller that contains a Raspberry Pi 3B, which is a single-board microcomputer mainly for embedded or experimental purposes, the RAM is not extremely big (1 GB) and there is a swap file on the operating system’s SD card of 1 GB too. The problem is, when the swap file is on the SD card, and the RAM is full, it starts to swap out memory contents to the SD card and that is rather slow. That are permanent storage I/O operations. The CPU may then encounter “Wait for I/O” states. Swapping always strongly reduces the speed of operation of a computer, and here it is even slower since on Raspberry Pis <=3, the mass storage device is no fast hard disk or SSD attached to PCIe, but a SD card, which is a flash memory that is attached to an Arasan External Mass Media Controller.
I don’t know if this is the case with your file that it is too big to prevent swapping, but how big is your laser toolpath file before you upload it to the controller, when you try to laser a picture file (which one can expect to be big, MUCH bigger than a vector graphics file) and/or increase the dpi – I mean a file where the “stuttering” issue appears?
By the way on the Onefinity Controller, you can show memory and swap usage with the commands ‘free’ or ‘htop’ (shown below) on the command line interface (e.g. via ssh login). You could load a file and see if memory gets rather full and swap usage starts to grow when opening the file and while it is processed.
I tried to read all the answers but I am not sure if anyone mentioned this:
Your file is full of nodes regardless of file type. A straight line should be two nodes BUT sometimes it looks straight and when you look at the nodes there is 50 nodes on the line! Even vector files can have too many nodes. This is especially evident when you import an NON-vector image into your project. I will explain below.
Stuttering - MAYBE you graphic (picture, stl, png, jpg, svg. or whatever) is giving the machine fits. I have found the main reason for stuttering is the 1F attempting to do what it is told and take whatever is on your screen and translate that to your material. A machine is just that and does what we tell it to do or what it is programmed to do. You can have perfect settings and still the machine goes wacky. Router , Laser, Drag Bit, all the same in the end.
Foe example: You start with a blank canvas and draw a line. It should have 2 nodes. The machine will move from a to b in a straight line regardless of the direction. Now if you found a jpg of a beautiful straight line and imported as a bmp and then traced so you ended up with a line it looks great! Nice and straight. Switch to node edit and take a look. What should have been a- b is now a-b-c-d-…z-aa…zz etc. If you told the 1F to engrave the line it would and it would look straight on the material but the machine is zig-zagging all the way down from node to node. Even svgs can be full of unnecessary nodes. I make and I buy files. I always check both to ensure there are as few nodes as possible. You can edit out the nodes. It is time consuming but necessary.
This really became apparent to me when I was attempting to do a simple set of deer antlers. I found a great picture of some antlers and brought them into Vectric. Good contrast so my image looked really good on the screen. Did not pay attention to the cut time. Loaded and ran the file and my 1F went crazy zigzagging around the whole thing until I stopped it. It looked like a good curve but when you felt the edge it was very rippled. I went back to the file and into node editing. There were about 30 nodes per inch of path. I started deleting and matching the curves. Next run, perfect.
Sometimes it makes no difference but I always check.
It creates too many nodes even when I do import a vector file into V-Carve pro. I tried to import my clean vector files from Rhino the other day and V-Carve “Interpreted” the data instead of using the vector files as is.
