@Chuck_Comito Raster engraving is straight moves at constant speeds, there is no reason to decelerate/accelerate ( except of course beginning/end of lines )
unless the comms can’t keep up, in which case the planning buffer dries up and it will be jerky.
I haven’t had any issues with it being jerky at all. Just the occasional skew like missed steps on the x axis (the entire image will shift). I don’t believe the skew is hardware related as I’ve changed it out a few times over and it’s only when attempting to run fast. This might be what @LightBurn_Software was referring to.
@Arthur_Wolf , this is what I suspected. I couldn’t imagine that not being the case… And this article explains it nicely: http://smoothieware.org/queue-refactor.
http://smoothieware.org/queue-refactor
@Chuck_Comito I have no idea why you mention the queue refactor stuff, I can’t see how it could relate in any way to this, it’s just about freeing up a bit of RAM ( that’s getting sparse on v1 ).
“It’s only when attempting to run fast” sounds a lot like it’s hardware related.
Also, " I don’t believe it’s hardware related " is something I hear very often, and " Well actually it was hardware related " is something I hear nearly as often. People tend to underestimate how likely it is to be hardware related. It’s not always, but thinking it’s not when it is, is very very common. What you’ve described so far sounds all the way around like other cases where it was.
Technically, if there was a problem with how @LightBurn_Software sends the Gcode ( which reading here it sounds like this might be the case ), it could cause performance issues, which in turn could cause :
- Coms errors ( which I think @LightBurn_Software says they suspect is happening but have not properly tested for it ), which I don’t think would result in skew, just weird anomalies in the engraving/cut ( going where it’s not supposed to )
- Underperforming coms speeds, which could cause miniature jerks, which in turn combined with a hardware issue could cause skew. I think this is the most likely explanation for what’s going on here : lightburn isn’t sending the code in a way as optimized as Octoprint or Pronterface does, this causes weird issues with the buffer which in turn cause micro pauses/slow-downs, which in turn cause speed curves that don’t look like the typical use you know your machine to be able to handle, in turn resulting in skew.
“LightBurn isn’t sending as fast as…” It should be - I do not wait for OK’s from the controller - not directly. I have a “push-ahead” count that is how many bytes I’m allowed to send the controller before I start worrying about OK’s. For Smoothie, it’s 248. So your RX buffer should always have commands in it. I experimented with a number of different methods and this was both the fastest and most reliable. It meets or beats the speed of fast-stream.py on Windows.
Having said that, I should just run a couple jobs, one from Fast-Stream and one from LightBurn, to see if they both exhibit the same behavior.
@LightBurn_Software as
said before there is NO RX buffer in smoothie. you should eliminate the 248 character count as it is bogus. and just consume oks as they come in.
skew or what I presume is missed steps is nearly always a h/w issue. especially on k40 where the motors are very weak and will skip steps at the slightest opportunity. i don’t see anything in the smoothie code that could cause missed steps unless you are running up against the 100khz steprate limit, which is unlikely
@Arthur_Wolf , the only reason I mentioned that is because I thought it might be what was mentioned earlier in this discussion (as I’ve said before, this is not my area of expertise). Anyway, I understand the “hardware related” argument and agree that it can go both ways. My reason of saying that is because I’ve had numerous hardware setups that behave the same way at higher speeds. @Wolfmanjm , I would totally agree with you with the exception that although I call my machine a K40, it is the farthest from a stock situation. As a matter of fact there isn’t a single K40 part left on my setup. @LightBurn_Software , if there is any way I can help with testing I would be happy to do so and for that matter if any of you need any testing help I would be happy to help. I’d like to see Smoothie (V1) be as good as possible.
@Wolfmanjm I heard you, but Smoothie doesn’t stop until all the buffers are empty, so I want to limit how far ahead I get. I’m actually planning to vary that number based on the length of the G moves being submitted. Implement instant stop and I’ll take it out. 
@LightBurn_Software This is true there is a trade off between faster comms and less control over pause. Unfortunately instant pause turned out to not be easy at all, and I have no idea when/if I will be able to implement it.