I have a problem when engraving images with my speed. I use the Grayscale setting, but no matter what speed I set in the parameters my machine slows to the same speed when passing over the image and takes the same amount of time. I tried using 20000 mm/min and 40000 mm/min to compare and got the exact same result. When I use the fill option when engraving vector images I can adjust the speed just fine.
I could lower the laser power to mitigate this problem, but I’d like to get my engravings done quicker and this way I wouldn’t be using the full potential of my laser.
Any idea why this is happening?
Hi Karlo
Not sure if you are trying to go that fast when FILL engraving, but You might have the GBRL settings set lower than the speeds you are trying to run at. Speed will be limited to the values set for $110 X speed, and $111 Y speed. Not sure what your controller is but an Arduino type is limited to a rate of about 30Khz so with a resolution of 80 steps/mm you would be limited to 22,500 steps/min anyway. If you are micro stepping to 1/16 it would be half that. Check your resolution $100, $101 to make the calculation
From the console in LB type $$ to get the numbers and check what they are, but I wouldn’t set them any higher than the max rate.
Cheers
David
I don’t go that fast when using Fill, but I just put it out there as an example that it can go faster in other modes, but it’s speed doesn’t change in Image mode.
If it would move at the same rate in both modes I’d be perfectly happy.
Speed and accelerationt settings in grbl are set appropriately, so that shouldn’t be the problem.
Edit: Just to test if it will work I squished the image 50% in x direction and doubled the steps per mm, it proved both that it can go that fast and turned out perfect. For some reason when the gcode is generated it’s like it is capped at a certain speed.
Hmm not sure then. I have complete control over the speed with an image. Is it a continuous image with large fill areas or is more of an illustration? Just thinking about if there are many small moves it could be the acceleration that is limiting it and not the top speed. Do you get the same problem with all images?
What is your controller by the way? it may be useful for Oz and the guys to know.
I have tested it on multiple images and it’s all the same. They are shaded images, illustrations.
I tried adjusting the acceleration to see if that would change anything, but it doesn’t do much and my acceleration was already at 1500. It looks like the engraving speed is just way lower than the move/travel speed.
I’m using an Arduino Uno and grbl, probably should have mentioned that sooner, sorry.
I did some more testing it it looks like the actually speed doesn’t go above 2500 mm/min. Everything I set above that is just slowed to around there. And as I’ve said, I have no problem with adjusting in in other modes like Fill.
Is the simulator giving you the actual times you are getting or is the machine going slower than the simulator thinks? This may give a clue as to whether it’s a LB setting or something with the controller
I have similar problem, I have a boss laser 1420, Rundia controller.
I think it must be a setting or something. the image files I send to the laser are not changing the speed, I go into the manual setting on the controller and have to change it, setting on the printer always is at 320. for images even when in FB i set it for 100, I manually have to change it a lot lower. i have not checked text or any other objects.
Estimated time is half of what it actually takes, so my machine takes a lot longer to complete the task. It didn’t cross my mind before, but is it possible that it’s the limitation of how fast my control board, Arduino in this case, can transmit information? It seems like a reasonable explanation, but I’m not sure what I should upgrade to in that case…
I also have a nano based system, and I don’t have this problem BUT I am only running at max 10K to 12K mm/min. So you might be on to something there. You could see if you have full speed control at the lower end. I.E it does change between 5000 mm/min and say 10,000 mm/min
Just saw this in another post. might be heading in the right direction although the example of running out at 100mm/sec 6000mm/min seems unlikely??
"In short, you are hitting the processing limits of the hardware you have.
Unfortunately the speed does matter - If you’re using an 8-bit GRBL controller to process GCode, they have a limit of about 400 instructions per second or a bit less. A C3D controller running stock Smoothieware can handle about 800 per second, and running the new cluster firmware (or GRBL-LPC) pushes that up to about 2500 or so.
An image at 254 dpi means 0.1mm dots, or 10 dots per mm. If you run 100 mm/sec, that’s 1000 dots per second, and each dot takes a gcode instruction to produce.
Stock Smoothieware hits 800 instructions/second, or 80mm/sec with 254dpi.
8-bit GRBL is about 400, or 40mm/sec with 254 dpi
If you’re running GRBL-LPC or the new cluster Smoothieware (available on C3D’s forum) you can hit about 250mm/sec at 254 dpi.
Yes, after my last comment I searched around a bit and stumbled upon the same post.
If that’s the issue and it seems more likely that it is by the second, the new problem I have is what would the best upgrade be without breaking the bank.
Generally people speak highly of the CD3 controller from Cohesion 3D. I think it’s about $200
I’ve heard it mentioned a lot, but it’s a bit pricey for me as that’s as much as my whole setup now. I hear that.
I read that Panucatt Re-ARM with RAMPS is also 32-bit and supports grbl-lpc. It’s much cheaper so I think I’m going to go with that one for now.
I’ll be interested to hear your results as I might go the same way eventually.
Alright then, thanks for the help! I’ll be sure to report back when I install and test the new board.
C3D released a firmware update that solves the speed issue a little while ago.
This is the cluster firmware that the last sentence David quoted refers to.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.