We have been experiencing ‘jerky’ motion with LW3 and raster engraving to a smoothieboard.
Even with the light and dark feed-rates set the same, the left to right movement is very rough. Lots of start stops, accel deaccel etc.
Has anyone experienced this and managed to resolve it?
Perhaps with some config parameters?
Yeah, I’ve also experienced this. The best I’ve managed is to set the “default_feed” (can’t remember exact config name) to 1/2 way between the black & white speeds I use (400, 500). So my default_feed is set to 27000. Still is a bit jerky. I think further investigation into this is in order when I have time.
edit: mine is a lot worse than that video +Peter van der Walt shared. See: https://www.youtube.com/watch?v=JcbZldELUyc
edit 2: oh, I realised I didn’t state my accel setting… I tried numerous different settings and anything above 4000 made my machine jitter a lot more. I didn’t test lower, so I’m still at 4k accel.
My latest config here I think I’m at 8000 for seek and feed rate. Acceleration to 3000 https://plus.google.com/+ArielYahni/posts/Riexg5WHVs6
It removes the jerky or stutter movement. I cannot go much higher as it will shake the whole machine
It does the same thing on my GRBL based setup. I have adjusted feed rates, acceleration, laser power, etc… to no avail yet. I currently use another program to do my raster engraving needs and use LW3 for my cutting needs. Once I get it figured out though, I will be using LW3 for the rasters too.
I had the best results when I set the min power high enough that there were no white spaces to skip over and that worked well but It also reduced the effective range (0-255) for my laser which I didn’t care much for the results.
Another thing I’m going to try is adjusting the contrast of the image just enough to get rid of the white spaces inside the image and hopefully stop the skipping.
First off let me state I have not configured my laser to run on a smoothie, but I do recognize this and think I may know the cause. The rattle is caused by the machine coming to a dead stop then having to restart motion, this will happen when the planner has executed all pending GCode blocks. In theory the smoothie should be able to process all the pixels and blend the moves together creating constant motion but as the machine approaches higher feed rates it is able to consume all pending GCode blocks in the planner faster then new ones can be added (I have observed this same situation with the grbl firmware but at much lower feed rates, i.e. Smoothie is faster). Once the planner is empty the machine comes to a stop now the planner is able to fill itself again and the machine starts again. While the stop start motion is not directly visible top the observer, the rattle is the tell tail sign that this is going on.
I have been working with this issue on the grbl controller for some time now.
Things that will help
Increase pixel spacing
Increase Acceleration
Decrease Feed rate
Increase pixel spacing
The reason this helps is because fewer blocks are processed / mm which helps prevent the buffer from ever becoming empty. The down side of this is loss of resolution.
Increase Acceleration
This helps by quickly recovering when a stops occurs, however this is going to also increase the rattle when stops do occur and will put significant stress on the motors and the machine.
Decrease Feed rate
Obviously decreasing the feed rate just makes every thing easier but you also need to decrease the power which results in slower burn times.
Ideally it would be nice if acceleration was 0 during the entire raster line and the Feedrate was constant. This has many challenges but this is the approach I am attempting to solve for the grbl firmware.
@Nick_Williams Yes, that is definitely part of the problem but there can be other factors as well which has caused this to be quite the challenge to resolve.
While I have not tried it, increasing the baud rate may help as well with this issue.
The other factor that can be at play here is the G0 commands that LW3 gives to skip over white spaces, and where the max feed rate is higher than your current feed rate. G0 will use the max feed rate and can result in the same behavior as starving the planner.
@John_Seaton How easy would be to change the GO command to G1 X?? Y?? S0, That way the feed rate would remain constant?? Also I know on grbl you can increase the feed rate by increasing the pixel spacing, does that help??
@Nick_Williams +Peter van der Walt From what Nick is mentioning about the planner queue becoming empty too quickly causing it to come to stops, maybe then we can increase the planner_queue option in the config (mine is set to 32 I think & has a comment beside saying “DO NOT CHANGE UNLESS YOU KNOW WHAT YOU’RE DOING”). Do you think it’s worth testing this out?
+Peter van der Walt Yah, that would be a lot of work but if we had an option just like we do for the Laser on and off control that was for moving over white space then let the generator do the work:-) But from what your say the planner is not being starved so that wouldn’t really make much of a difference, this is all biased to planner starvation.
@Nick_Williams Sorry, I didn’t see your response till now. It “shouldn’t” be too difficult to change the G0 to G1 with S0 and a feed rate. I was thinking of making it an option so you could turn on/off skipping blank lines.
On program I use has this option to skip blank lines or not, and I am able to run smoothly with it. However, if I increase the feedrate to 3000 I get the same jittering effect with that program as well.
Also, according to GRBL 1.1 laser mode. changing between M03 and M05 will cause pauses.
“Laser mode $ setting - When enabled, laser mode will move through consecutive G1, G2, and G3 motion commands that have different spindle speed values without stopping. A spindle speed of zero will disable the laser without stopping as well. However, when spindle states change, like M3 or M5, stops are still enforced.”
I did a small test and some video on my rig. This uses constant velocity no acceleration during raster. The system is a grbl running on a nano connected to a pi using a CNC hat.
rastering is at 200 mm/sec. You will notice nice clean moves and no jerk. the image was a surface area of about 100 H 84 W. Baud 115K.
In the video I show the amp meter notice that I am using 13 mil amps which allows me to utilize the full power of the laser.
missing/deleted image from Google+
@John_Seaton Also here is picture of the final image
@John_Seaton One other note the feadrate in this video is 12500:-) Note: I am using a custom version of grbl still working on a few issues to my knowledge this is not possible on any other Arduino based control. Unless someone else is working on constant velocity image rastering. I am planning to release it to the community but still working out a few details.
@Nick_Williams Thanks for posting that. That is how it works for me using another raster engraving program that I use. I can turn on or off skipping blank lines and it will sweep the entire image or skip over the white spaces.
The house elf in the attached image was done with constant velocity but with skip blank lines enabled so that it only went back and fourth over the elf. The white areas in the elf were darkened with negative contrast to achieve this but I could have also just turned off skip blank lines and it would have swept the entire image without hesitating or jittering.
I’m trying to get LW3 to do the same thing. Let me see if I can get a video of it in action.
@John_Seaton Hey John that looks really good is it done with a smoothie or grbl controller and at what speeds??
Looks like this thread is moving off topic.
With respect to jerky movement, we have been noticing that movement is streamed smoother when not on the ‘jog’ tab.
Some of our rough movement actually improved when we selected the ‘gcode’ tab after running the engraving job.
I suspect it could be because of the DRO updating going on?
Anyone experienced this?
+Peter van der Walt Regarding the tab-jitter issue, I wish it was imaginary! I’ll try to make a video to show you. Difficult so demonstrate by video, but perhaps the sound will make it clear.
It’s running on Win10 and the latest Chrome browser.
From the results I posted on the github issue, you can see that the problem starts to become apparent after 30mm/sec raster engravings. At 10mm/sec there are no problems. Try a test on your machine with 40-40. Even if you can’t engrave at that speed, you will be able to judge the motion.
We have tested both 115200 and 25000 speeds with no difference.
I will run these tests and report back.
@Domenic_Di_Giorgio I get the same with GRBL. Anything bellow 3000 mm/min and there is an improvement. 3000 mm/min and above and it gets pretty rough. I say this because what you are experiencing is not isolated to the smoothieware and I hope it helps with the problem solving.
@Nick_Williams That engraving was done with GRBL 1.1c but not with LW3. I’m working to replicate that in LW3 and hopefully make it better.
Edit: the speed for that wa 1800 mm/min
