We have been experiencing 'jerky' motion with LW3 and raster engraving to a smoothieboard.

CAD & CAM Tool Chain LaserWeb/CNCWeb Suppport
21

+Peter van der Walt

I did some test last night and I got some pretty interesting results.

Test number 1
With GRBL 1.1c (legacy reporting turned on), I can confirm that changing G0 to G1 had no effect on the jitters. What I also found out is that it is related to the buffers as far as GRBL on the Nano is concerned.

Setting used for these tests were
Max feed rate set in GRBL 1200 mm/min
Black/White feedrate 1200 mm/min

Running my test image (the number section of the gray scale test image) in LW3 produced the jitters.

I loaded up the test image in another program where I can turn off skip blank lines and it ran smoothly and quietly for the entire image. I then took that GCODE and ran it in LW3 and it was smooth but the stepper motors were making a noise and if I had gone much faster I think it would have caused some stuttering.

I took the same GCODE and ran it in UGS and it ran smoothly as well.

From this I started looking at why and what were the differences in the GCODE were that could be causing this. I tried changing the G0 to G1 with no effect as well as a few other things. What I did learn is that there were apparently two different issues going on at the same time.

Issue 1 - The serial RX buffer: When running the GCODE from the other program, that ran quietly and smoothly and produced the cleanest lines, in UGS I noticed that the GCODE lines seemed to be fed more smoothly and consistently to GRBL whereas the GCODE from LW3 seem to go in spurts. What I mean is that it would send several lines and then wait, send several more lines and wait. This was not the case where the other program was sending a line for every pixel (or so it seemed). The number of lines seemed to be cause a throttling effect.

I know this is directly related to the limited memory of GRBL on the Nano, but it may also affect smoothie in that if you fill up the buffer and smoothie/GRBL waits for the buffer to get filled up again, this will create a pause. Obviously a faster baud rate will help get the data there faster. I don’t know if GRBL or Smoothie wait till the buffer is full to start but from my tests, it seems GRBL does or at least to some extent.

Issue 2 - LW3 issuing status requests while running: When I ran the GCODE that ran smoothly in UGS and my other raster engraving program, the stepper motors were smooth and quiet. But, when I run the same GCODE in LW3 I get a repeating change in sound that appears to have the same cadence as the status request being sent to GRBL.

In conclusion, the status request from LW3 to GRBL seems to affect the performance (shouldn’t be a problem for smoothie) and filling up the RX buffer seems to induce lags.

I think it is useful to be able to turn on and off skipping blank lines so I don’t think the answer is to get rid of it all together.

22

+Peter van der Walt Smoothie return ok when the command is taken (not executed) some command like M4 send the ok once the command is executed (the queue is empty)

23

+Peter van der Walt you’re welcome.

For GRBL the status check seems to only be detrimental when it’s processing GCODE. My suggestion would be to keep it while connected but pause the status checks when running.

Or

A bit more complicated approach would be to only send status checks on laser off moves.

I’ll do some more reading up on how GRBL and its buffer/planner executions. I’ll also do some more tests with different ways of feeding the buffer to see if any one approach produces smoother operations.

24

+Peter van der Walt Thanks, good to know as I’m still new around here lol

25

Well you know, when you get some spare time lol

26

+Peter van der Walt smoorhie sends ok when the command is received unless the planner queue is full in which case it has to wait for room. so the ONLY method for smoothie is send line wait for ok send line etc. this is for movement commands, switch commands will wait for the queue to empty so they are synchronized.

27

Here is a video of smooth operation (sorry not done with LW3) and where it only scans across the actual image parts.

This would be nice to have in LW3 but it sounds like it will cause problems with smoothieware.

28

Yes M3/M5 will wait for the planner queue to drain before it executes. this should be avoided.

29

Is the two pin effected the same when gcode file is ran from the sd card?

30

+Peter van der Walt​ While we are on this topic let’s tag in @Scott_Marshall ​ and @Roy_Cortes ​. I know Scott has his ACR board out there for ease of helping users get connected to smoothie… and in a recent post from Roy I caught a glimpse of a K40 Sheild for the Azteeg boards

31

Does this by any chance cause a noise similar to a mechanical drag?

I have a customer in the UK who has a motor noise that sounds just like he has a siezed roller or bad bearing. It only occurs in raster mode.

It’s coming definitely coming from the motors, especially the X axis.

He’s using the Ez~Config (it’s a simplified K40 specific file with integrated instructions) that is working fine with 20+ other users, and I haven’t any idea what to try next. The current settings are fine.
I sent him the latest Master and a fresh copy of the Ez~Config but haven’t heard back since.

Based on the video he sent me, this may be his issue. It behaves very much like a delay written in between steps, like the motor is taking a step (or short series of them) then pausing for a few milliseconds, and repeating.

32

@Scott_Marshall Could be the case. Is his X-belt tension right? I know with mine (even before Smoothie/ACR) I was having issues with too high a speed when the belt tension was off. Only really for raster too. Horrible dragging/clunking noises.

33

I’ll have to advise him. It’s a fairly new laser, so it could have been shipped tensioned wrong.

Sorry, wrong video. The one I want up is an MP4, trying to put it up, but it doesn’t look like it’s going to happen. (can’t even erase the wrong one. gotta love this forum… then, it just may be me, been up for way too long. )

34

@Scott_Marshall That music sound coming from the laser seems common for me on low amperage like his ammeter shows. If that’s the noise he’s concerned about I’d suggest upping the power a bit. Mechanically the noise seemed fine to me from his youtube vid (i.e. much better than mine when the tension was bad).

35

Agreed it sounds like the Pwm is in the audible range of human hearing

36

That’s a video of a properly operating system. (a lot of people send me videos of problems and of successful installs, and I’ve got to start an organizing system so I can find them).

The musical sound is from the motors, on .4 & .6 amps if I recall.

I did a bit of testing looking for the sweet spot, and for my K40 - the blue one - those settings seem to be best, and people aren’t loosing steps with those settings, so that’s where I ship them. The motors run cool and have a pleasant sound. So far it’s worked well for all. )

I can’t put up the video I want, It’s an MP4 file that came from a google sharing app and it’s not a copyable file (or linkable). I emailed the fellow with the belt advice and we’ll see what he says.
The sound the video shows is what the owner (correctly called a Screeching) - I say it’s half squeaking and half screeching. It’s definitely NOT right.

If I hear back from him, I’ll ask for a video link that I can post, or I’ll have him weigh in here.

Thanks guys!
Scott

Scott

37

@Domenic_Di_Giorgio ​​ could you share an image on Google drive or some other cloud hosting service? I would like to try it out on my setup see if I get the same results

38

@Domenic_Di_Giorgio ​ if you are needing some additional trouble shooting tests from someone local @Yuusuf_Sallahuddin_Y ​ is in your neck of the woods might save a bit of time zone delay in testing

39

@Alex_Krause Much appreciated Alex. We will definitely keep that in mind.

40

@Domenic_Di_Giorgio ​ what is your preprocess image regime? Is there dithering involved?