I’ve just started using my new OMTECH 50w CO2 laser, and it seems to work as expected. I’ve been using an Ortur IM2 Pro for the last year and have started to transition most of my engraving over to the CO2 laser. Today, when engraving a coaster, I tried experimenting with some different power and speed settings. I went from 250mm/s at 40% pwr (13.5 min. start to finish) to 350mm/s at 45% pwr and the same image took 5 minutes longer to engrave. There is something going on here that I’m just not getting. The other issue was the estimated time in the preview window said 6.5 minutes, but in reality, it was 13.5. The estimated time on my diode laser has always been pretty close, but the CO2 laser is almost double. I do have a good idea as to what’s causing it though. I haven’t gone into Device Settings > Additional Setting and read the Simulation Settings from the controller yet. I’m hoping that will clear up the second issue. I still don’t understand why a faster speed setting would add an additional 5 minutes to a job. Any ideas?
Do you have overscan on? If so, it could be increasing the distance travelled which could eat up any savings from speed. Also, it’s possible that you’re spending a lot of time accelerating and decelerating rather than engraving.
Here is a Russ Sadler video where he speeds up his Red Sail machine.
If you skip to 38:40 area you can see how the overscan and increase of speed can add time to the overall project.
Good luck
Jack, correct me if I’m wrong, isn’t overscan kind of baked into the cake so to speak, with a Ruida controller? I have the RDC6442G controller on my 50w OMTECH, and as I understand it, overscan is always on (or something to that effect). This is what I was engraving on a 100X100mm Acacia coaster. Being new to CO2 lasers, I didn’t expect it to take as long as it did. Thanks for the link.
Overscan is computed by the software on your pc for grbl type processors on dsp types, it’s done in the hardware, they claim.
The Ruida and most dsp or these types have the complete ‘job’ loaded into memory. The general idea is for something like a scan or image where the head repeatably moves back and forth on one axes and the other axes is stepped by the lpi (dpi).
In this type of scan, the head must get ‘up to’ speed before the laser can start firing. On the other side of the ‘image’, the laser is turned off then it slows, changes direction and speeds back up only then enabling the laser to fire. This is overscan. If the overscan is equal to the ‘image’ then >50% of your time is not doing the job, it’s slowing down, changing directions and speeding back up.
Vector cuts leave the laser ‘on’ and as the head slows to make a turn the controller adjusts power.
The settings of min/max power in the layer and the ‘start speed’ in the controller are used to compute this.
In both of these the hardware computes the overscan and/or controls the power on speed changes for a vector. It must know some details. If the head has the mass of a brick, it will take longer to get to speed than something much ‘lighter’ like a feather.
The Ruida computes this based on the ‘acceleration’ rate of the axes. This is in mm/S^2. So how all this happens and what makes the change is the mass of what you are moving or basic physics.
If you want to think of it as always on, I guess that’s ok, however I feel it’s simply protection for the machine, much like the maximum speeds on the axes. There is no reason, but ‘self’ protection to have these values in the controller. It prevents out of range requests from being attempted. You can ask for 4,000mm/s, unlikely your machine can do it…
Hope I didn’t confuse you…
The Ruida also handles how it controls the laser different than most grbl machines and the basic K40 types. The Ruida sends the pwm for that layer continuously as soon as you press ‘start’ and turns the laser on and off via the L or H input of the lps.
You might take you artwork and try different setting. I don’t know how the original artwork is done. It might be faster to outline and and use a fill option. How it’s optimized can also affect job time.
Some of this is learning how the machine does things.
If you don’t mind posting it, drop the .lbrn2 file on the reply window or use the upload icon 
on the toolbar.
There are plenty of smart people here that will probably give you tips on how to make the job faster… Best way to learn…
Before submitting the job, always take the time to view it i the ‘preview’ of lightburn. You can see how it will do it and estimate of how long it will take.
Good luck, have fun with your new toy…
Thank you Jack, as always, your posts are on point and very informative. The preview is the next thing I need to get squared away, preview showed 6.5 minutes, but it took 13.5. I think I know how to fix that though.
Generally Lightburn reads the configuration from the controller and uses that to estimate the job time.
That’s sounds pretty awful for an estimate. Might go to “Edit → Device Settings → Additional Settings” and click the “Read From Controller” button. It will update the gui if different.
Mines usually within a minute or so for a 30 minute job.
Same here, with my OLM2 Pro diode laser, the 50w CO2 laser is way off though. I’ll do what you suggested next time I’m in front of the machine.
Check the ‘additional settings’ and see if the read give you different numbers and times. Can’t suggest much else.
Good luck
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.