I wonder if anyone can help me, Im using an Opt laser on a onefinity with the light burn software, everything works perfectly with standard black an white images (ive had it running for over an hour on some laser projects without putting a foot wrong), however as soon as a try a picture (jpeg image with or without trace image), it gets around 3 minutes in an the cnc starts to judder backwards an forwards on the y axis, generally it seems like its lost its home position.
This has never happened when using the spindle and doesnât even happen with the laser software as long as i dont try to laser a photo - am i missing something, ive only just completed the trial and signed up for the software hence very new to the laser side of things
There is quite a difference in the amount of code sent by a vector compared to a âimageâ. On grbl machines this is âstreamedâ to the device as itâs running. If there are any communication errors of any kind you work is lost. Vectors are sent with a few bytes. Images need to code to turn the laser on and off and the movement instruction, so there is a continuous stream of data.
I never had the problem, but others have. Iâm not sure about where to send you too look but you might search the site for image problems with your system.
Hang in there⌠
@jkwilborn, Hi Jack, many thanks for the reply, if youve heard of it before then it suggest there may be a solution out there, i will try searching the forum for image problems, i did look for juddering but nothing specific, im hoping someone has a solution or someone from lighburn may have a fix
You havenât mentioned what speed youâre using, or what image settings. I donât know how potent the OneFinity processor is, but GCode for images is very dense, and will choke most GCode systems if you try to run it too fast.
A dithered image using the default settings in LightBurn (100mm/sec at 0.1mm interval) produces up to 1000 GCode instructions per second of engraving time. Using a higher speed or a smaller interval will increase that.
Are you scanning the image along the X axis or the Y? If youâre scanning along the X, but the shudder is along the Y, then thereâs something else going on.
@LightBurn, Hi Oz, appreciate you taking the time to reply, at this stage i have not adjusted any settings (ref below)
Apologies, im not sure what you mean by scanning the image along the x or y axis (i am working through your training videos online but have not come across this terminology yet)
Not sure if it makes any difference, but i am saving the G code to a dongle and loading it onto the onefinity processor, would it be preferable to run the code direct from the laptop?
You have the scan angle set to 0, so itâs moving horizontally (X axis).
What speed are you running? LightBurn doesnât talk directly to the OneFinity controller yet, but that shouldnât honestly make a difference - the controller is going to have some maximum throughput that it can handle, and if youâre exceeding that it could be causing the shake.
Ive just checked an it seems to import images at 160mm/s, power 7.5%, also the judder does seem to be more on the x axis, what would you recommend lowering the speed to?
160mm/sec is likely much too fast for a diode laser. Typical speeds are 50mm/sec to 100mm/sec. I do not know how fast the OneFinity controller can process GCode instructions - that would be a question for them.
Ok, something doesnât make sense, lightburn has had 2 updates in the last few days to 1.0.04, i have changed the units/grids to better for diode mm/min and ran the same picture at 100mm/min, it literally stayed stationary and burned into the wood, i changed it to 6000 an it completed the picture in under 3 minutes - perfect, i increased the size of the picture which took it over 3 minutes an now it starts juddering again, what does the mm/min refer to, its clearly not covering 6 meters?
The speed is mm/minute. 6000mm/min would be 6 meters per minute, or 100 mm/second, and thatâs the target speed - depending on your machine, it might never actually reach that speed. If itâs shuddering, chances are good the speed it much lower than that.
If Iâm not mistaken, the OneFinity is using ball screws, so the acceleration is likely low. Iâve read that the maximum rapid rate is 500 inches/minute, which would be 12,500 mm/min, but thatâs just to move - it doesnât mention the amount of GCode they can process.
Have to say m struggling to believe that some cheap chinese import can handle images but the onefinity with its dedicated processor cant and its fine for the first 3 minutes now that ive changed some settings, there must be something else that im missing?
Have you reached out to OneFinity to ask them what the GCode throughput of their processor is? âBeliefâ isnât important here - factual information is.
Iâm not sure what âcheap Chinese importâ youâre referring to, but an 8 bit Arduino, for example, only handles about 200 GCode instructions per second and shudders like crazy. An LPC-1768 can handle about 2500, and a Ruida, using a custom-coded Altera FPGA chip handles around 350,000 or so. The OneFinity processor isnât custom - itâs a Raspberry Pi, coded primarily as a CNC processor, which would not need to handle even remotely close the kind of code density of a typical CO2 laser processing image data, but itâs worth just asking them to see if they know.
1 Like
Thankyou. i will ask the question an let you know the response, im slowly working my way though all your online videos which have been of great help an im sure there was a reference to a method of reducing the number of i believe ânodesâ that reduced the file size from aprox from 1M to 250K etc, if i can find the specific info again would this be worth trying assuming its relevant to image processing
It is not relevant to image processing - they are handled completely differently.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.