So in wondering if this is still an issue with windows as the discussion is 2 years old now. https://github.com/Smoothieware/Smoothieware/issues/1096
If so, is a linux box still the best solution for fast rasters with a laser?
I haven’t heard about this in a long while. My understanding is this was a limitation in how LW4 ( specifically ) interfaced their coms, which other hosts ( Octoprint, Pronterface etc ) doesn’t have. Don’t know if LW4 made a fix there ( I think it was quite a bit of work for them to change the way they do things ), maybe ask them too ?
@Arthur_Wolf I’m not so sure this is host specific to lw. But I’m no expert and am still figuring stuff out. I notice in lightburn that i have raster speed limitations and read a post that smoothie was somehow limited to 80-100mm/sec when I came to rastering. Which is what led me to the discussion I referenced.
@Chuck_Comito Smoothe definitely has limitations, actual speed also depends on the image resolution/density. But this specific issue was about communication between LW and Smoothie, which isn’t ( or at least wasn’t at the time ) happening at the best possible speed, and was the bottleneck in that situation.
Smoothieware has a speed limit of about 800 to 1000 GCodes per second. Faster than that and it starts to miss steps and skew. You can reduce the GCode per second count by lowering the speed, reducing the DPI, or using the Newsprint dither mode in LightBurn, which clusters the commands together, allowing Smoothie to go faster.
The 80/100 mm/sec limit come from the default DPI setting. If you use an interval of 0.1mm (254 DPI) you get a maximum of 10 dots per MM, each of which creates a GCode command. At 80 mm/sec, that’s 800 commands per second. This is what is meant by “GCode density”.
Faster than that and it starts to miss steps and skew.
That’s not what’s reported by users, and it makes no sense this would happen ( at least as a general rule ) considering how the software is made.
Going too fast for Smoothie’s gcode parsing rate would result in loosing speeds, possibly in a relatively untidy manner, but always staying within the defined ( configuration ) parameters for acceleration and junction deviation ( meaning if they are set right and the machine is well built, no missed steps ). You should see rattling and erratic speeds, but you shouldn’t see missed steps are skew.
If you do see these, then this is likely machine related. As in : maybe your acceleration setting, or machine structure, or stepper driver configuration etc, is such that your machine can’t handle the stress caused by this erratic behavior ( which for any given setup would likely be amongst the worse possible cases ). My point being here, you can’t really answer “what happens when it goes too fast” with “missed steps” as a general answer. Though it’s possible it’s true on a given machine, it’s likely not going to be the most useful answer to a user you don’t know anything about.
It’s not what I’ve observed. On machines set with very conservative acceleration, if I try to exceed the GCode limit, it looks like instructions get dropped occasionally.
That’s not something I’ve seen reported so far, we take this sort of thing very seriously. Would you mind trying to find some reliable way to reproduce the problem, and open an issue on Smoothie’s github reposiory please ?
I’m doing something similar to “Fast-Stream.py” in LightBurn, but also tracking the Smoothie RX buffer size, and making sure that I never send more than the RX buffer can hold, but not using (to my knowledge) hardware handshaking. I can double check to be sure, as I had enabled that as well at some point but found it made no difference. I should be able to reproduce easily.
+LightBurn Software - given that smoothie does not have an rx buffer as such it would be hard to track it. That was a grbl hack, and is not relevant to smoothie. This is true over USB serial and uart serial. USB serial has its own flow control that the USB drivers handle which is why fast-stream even works.
Well, if characters or packets were being dropped I’d expect Smoothie to complain about invalid or partial commands, yet that has never happened. That implies it’s not a data loss issue between LightBurn and Smoo. LightBurn sends no more than X characters ahead of what’s been ack’d so far, and X is set based on the firmware I’m talking to. For Smoothie, it’s 248 chars.
248 is totally arbitrary and somewhat irrelevant. you can just stream at full speed, the USB flow control takes care of the rest. There can be no data loss as USB also does retry and checksumming (similar to TCP/IP). You do have to make sure you read the return data though as if that backs up it will cause deadlock in the host o/s driver system.
For anything other than streaming raster though it is safer to use good old ping pong protocol.
I do read all return data, there is no backlog, and the exact same streaming code works perfectly with GRBL-LPC, GRBL, and Marlin. So, if there can be no data loss, why does it skew if I push too hard?
Like Arthur I have never heard of that happening, I use it all the time and push hard and never had that happen, the worst that can happen with high dpi is the planning buffer dries up so it can’t plan ahead so it cannot reach full speed, and gets a little jerky starting and stopping as it waits for more data.
Is there a benchmark to what we all feel is fast or slow as far as performance of the machine is? I don’t have any reference. I only know Smoothie for laser. My cnc mill and 3d printer run it also but they are very slow by comparison.
I’m not even sure what speed I top out on my machine. I can only say that the print speed doesn’t seem to change after about 60-80mm/sec.
Hello, I can confirm that using the firmware smoothie engraving images in either newspaper mode, dither or jarvis you always have consecutive blocks going over 80 / 100mms (254 dpi).
With lpc you can push up to a maximum of 230mms, and then have the same problem of slowing down.
Slowing down of the movement and not to be confused with loss of steps.
I’m using lightburn.
It’s a pity because I much prefer the original smoothie.
@Chuck_Comito my delta/smoothie can move at 500mm/sec, however the maximum one can actually print at is around 100mm/sec due to extruder limitations etc. My Laser (K40) maxes out moves at 100mm/sec anything over that it will skip and the motors stall. So as 100mm/s is the maximum it can reliably move and I can stream 0.1mm dots at 100mm/sec it has never been an issue for me. The only real smoothie limitation is the 100KHz maximum step rate, so long as you don’t max that out it will issue steps reliably. The actual feedrate depends on your steps/mm, Smoothie won’t let you set a feedrate that would exceed the 100KHz step rate.
@Wolfmanjm I also use it with the k40, I chose the moothie just to solve the problem of speed (jerky movements) that wax on marlin or mk4duo.
The steps set are 160, the problem is that to make a 240 dpi 240x320 mm raster takes about 80 minutes (210mms).
Having taken a smoothie to use grbl lpc saddens me a lot, when you could save money using other cards.
@Wolfmanjm , not that I know anything about this sort of thing but when rastering, does the controller try to fire the laser to a “single” dot, move to the next “single” dot and fire again? In other words, Smoothie is not trying to accelerate and decelerate after every command during the raster process is it? I would think this would be ignored is some way unless coming to the end of it’s row (so to speak). So about my terminology. LOL