Jerky motion during raster engraving

[ghost]

Raster g-code generated through Laserweb3 results in jerky motion when run on the Smoothieboard.

We are testing this via USB and have tried streaming the same G-Code via LW3 and Pronterface with the same results on the smoothie. We have also used our PCB and an original Smoothie PCB with the same results.

We are currently running the latest smoothie master firmware and the latest LW3 master.

[ghost]

Thanks for the quick reply @chamnit ! (:

The idea to cut unnecessary chars is actually a good one... I'll definately consider that

To me the bigger thing here is, F on every line should cause 5 extra bytes of serial overhead... yes, but not 'break' the planner as claimed above?

[cojarbi]

@openhardwarecoza that is the DPI or PPI, i had only 180mm/min when it was supose to be 1800. Still laserweb only moves the head up/down and finishes

[iceman1979]

@openhardwarecoza Sorry about that, I have edited the post. Not sure what I was thinking there as I know it doesn't. As far as my other post on G+, I should have been more specific since that was only referring to the white pixels in between non white pixels. Correct me if I'm wrong, LW skips over ALL white pixels, even the ones in between non-white pixels, right?

The other difference is that thers a move for EVERY 0.1mm pixel. Which as we mentioned above, I can turn off, but as @wolfmanjm also agrees, we cannot see how that would make any difference. Longer moves should be less likely to starve the buffer than small moves right?

As long as the next line is short, I don't think GRBL would have a problem with the current optimization either.

Also, since we'd like to keep cross platform happy, @chamnit @grbl - we already added support Grbl 1.1 and have a couple users reporting back they are very happy. Will having an F on every line trip up Grbls planner? (We currently do, and no user complaints. But if its not advisable I can take it off)

I don't think it does but I will confirm.

[ghost]

@iceman1979 no hard feelings (:

Look at the function in https://github.com/openhardwarecoza/LaserWeb3/blob/master/public/js/laserraster.js#L229-L317

Summarised: If the pixel is a new S value (compared to previous pixel), and its intensity > 0, then we generate gcode to draw it. If it does not match, then we do https://github.com/openhardwarecoza/LaserWeb3/blob/master/public/js/laserraster.js#L301 (skip)

Edit: Forgot to add, but look at the sample image above, there are a few visible green moves inside the image too... Those would be proper white...

[ghost]

As long as the next line is short, I don't think GRBL would have a problem with the current optimization either.

• so you think (@wolfmanjm @chamnit, feel free to confirm or deny) that a 0.2mm move, followed by a 10mm move, followed by a 2mm move would break the planner? its understandable that different feedrates would cause velocity changes, but isnt that the purpose of the planner, to plan smooth transitions between those... as long as we can keep the planner full

[iceman1979]

@chamnit Maybe I called it the wrong thing by saying motion?

here is what I was referring to. https://github.com/gnea/grbl/blob/edge/doc/markdown/interface.md

Just about every user interaction with Grbl is performed by sending it a string of characters, followed by a carriage return. Grbl will then process the string, execute it accordingly, and then reply back with a response message to tell you how it went.

Maybe I'm misreading it.

[arthurwolf]

feel free to confirm or deny) that a 0.2mm move, followed by a 10mm move, followed by a 2mm move would break the planner?

It doesn't "break" the planner, but the planner will produce constant speed if the moves are of fixed length, and can produce variable speeds if the moves are of variable lengths ... that's just due on the assumptions Smoothie has to do about the speeds in the future when the queue is full. For the third time : we tried variable and fixed lengths, variable length caused changes of speed, fixed length caused fixed speed, this is both something that is to be expected from the code, and something that was experimentally verified.

On Wed, Oct 26, 2016 at 9:14 PM, Peter van der Walt < notifications@github.com> wrote:

As long as the next line is short, I don't think GRBL would have a problem with the current optimization either.```

• so you think (@wolfmanjm @chamnit, feel free to confirm or deny) that a 0.2mm move, followed by a 10mm move, followed by a 2mm move would break the planner? its understandable that different feedrates would cause velocity changes, but isnt that the purpose of the planner, to plan smooth transitions between those... as long as we can keep the planner full

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/165#issuecomment-256448794, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFZoxdloNaTy_xSyEXmAvmtilMtIsks5q36akgaJpZM4Kcrxj .

Courage et bonne humeur.

[iceman1979]

@openhardwarecoza Sorry, short as in number of bytes being sent, not move length.

[iceman1979]

@openhardwarecoza cool, last thing I want to be is a stumbling block for others and I definitely don't want to be a source of frustration to you.

Here are some things I have tried in my quest to get rid of the jitters in LW.

1. use 1 decimal place instead of 3 when the last two are decimal places are always 0. ie X1.100 The improvement was barely noticeable.
2. remove all but the first F commands when I set the black and white speed to be the same. Also, barely noticeable.
3. On subsequent moves after an initial G1 command, remove the extra G1 and only provide the new coordinates. (this was only tested where all pixels had a line of gcode, obviously not generated in LW but it did run ok in it).

hopefully that all makes sense.

[ghost]

All cool (: I only had a problem with that one repeated wrong statement. Other than that, testing is always a welcome. We cant improve if we dont know what we are doing wrong.

I am busy adding the config to disable the "optimisation" se we can see how that goes (@arthurwolf - i feel more convinced now... the issue isnt the planner breaking but the inconsistent length/curve of the ramp sections of the accelerated moves... @iceman1979's wording triggered me into understanding what you are trying to say)

[iceman1979]

@openhardwarecoza Are the green lines G0 or G1 commands?

[ghost]

Green = G0

[chamnit]

@iceman1979 : Thanks for pointing out that document. That section was intended to outline the basic communication operation for GUIs at its most fundamental level. I looks like it was a little too simplified. "Execute it accordingly" has a lot of meanings inside Grbl. I'll edit that section to make more clear how motion differ from other commands.

@openhardwarecoza : Having the 'F' words in each line will not break the planner. It will only slightly effect throughput and latency. If Grbl is running smoothly, then no problem. If Grbl is stuttering in certain areas, it's most likely caused by planner buffer starvation. Removing the 'F' words then would help a little, but you'll get the most gains by compiling Grbl to 230400 or 250000 baud.

Having small motions next large ones, or any combination thereof, will not break the planner. Grbl's v0.9+ planner is 100% deterministic when properly implemented and very robust. If this wasn't the case, then 3d profiling tool paths would constantly fail, because they have sets of motions like that all of the time with programs often exceeding 1 million lines or so.

As for decimal places, I would be careful about rounding. G2/3 arcs are extremely sensitive to position error. It's inherent to how arcs are formulated in gcode. If you round too much, an arc can become an invalid command, cause Grbl to error out, and ruin your job. I would limit any precision adjustments to 0.0001" and 0.005mm.

[iceman1979]

Ok, thanks.

So yeah, that definitely causes problems for GRBL too. I got around that by setting my machine max feed rate to match my black/white feed rate (for example all 3 were F1200) and reduced the contrast so that there were no white pixels inside my image, except for the background. So, for the House Elves image I posted on G+, I selected all the white pixels around the elf and the lettering and removed them. Then I adjusted the contrast so that there were no white pixels (but light enough not to engrave). Then I added a white background back in. I have not had a chance to test it yet but that was my way of forcing a line for every pixel inside the elf.

[iceman1979]

@chamnit Thanks, I was trying to find out how GRBL handled that before I posted and that was all I could find on the subject short of diving through the code to figure it out. Thanks for keeping me straight.

Funny thing is when I read that section, I kept scratching my head thinking.. really GRBL only does one line at a time, whats the point of the buffer then? LOL!

Thanks for the heads up on the decimal places.

[ghost]

@iceman1979 - off topic, but I got to say, the way you handle critique (and yes, sorry, I may have sounded like I was in attack mode) is most awesome! You totally earned my respect tonight. Big up for taking corrections like a man! We need more people like you. Thats something even I dont do so well!

[iceman1979]

@openhardwarecoza thanks for the kind words. I didn't always take criticism so well, but then I didn't seem to make much progress with stuff either LOL!

Here's the way I look at it. If I'm frustrating someone while I'm trying to be helpful, then I'm obviously doing something wrong and now I am the problem. :)

[iceman1979]

Plus, I know articulation is NOT my strong suit lol. What's in my head has a hard time finding its way to my mouth and my fingers.

[ghost]

Quarter to midnight, calling it a night for now. Will posts update tomorrow

[ghost]

Ok, I made the optimisation a configurable value:

@DarklyLabs do a git pull, go to settings, GCode, disable the concatenation, and save. Refresh the page to be sure (not really needed) and then generate a raster... test and let me know

Also, for @iceman1979 I upped the check for whitespace from >0 to >0.05 - that little extra makes it visibly more "skippy" of whitespace, and thus visibly you can immediately now see where we "skip" = green, and where we burn = red

[ghost]

@openhardwarecoza Wow, coming back after a day and I'm blown away by the activity overnight. I just started running some tests with raster.js but it is still not smooth. Admittedly, we have only tried one image and had to edit the gcode because of some 'SNaN' entries. More experimentation is needed. I guess I'll skip right to the bottom of the thread and try your new version. Will let you know the results.

[ghost]

@openhardwarecoza Did a pull on master but this feature not showing up. Should it be a different branch?

[ghost]

Ahh yes, this is on Master, not on the Emblaser branch... yet

[ghost]

@openhardwarecoza Did that. What am I missing?

[ghost]

refresh the browser , might be caching the old page?

[ghost]

@openhardwarecoza Did a clear cache. All good now. Thx.

[ghost]

(: anxiously waiting for testing news now (I havent tested this yet)

[ghost]

OK got to the office... (Where my laser is) It does sound a little smoother indeed. But then again even at 100mm/s I never had massive vibrations (OpenBuilds V Slot and its zero backlash makes me forget about issues like that)

[ghost]

@openhardwarecoza Ok, test results so far: Accel 3000 20-20 (optimise on) = good 40-40 (optimise on) = rough 40-40 (optimise off) = rough (too similar to pick a difference between on/off)

[ghost]

Can you please give me a video... it would help sooo much. especially try to catch the sound

[ghost]

Video on its way.

@wolfmanjm Setting queue_delay_time_ms to 0 causes smoothieboard not to boot properly.

[ghost]

@DarklyLabs I just found an old bug in regards to feedrate that I also just fixed, do a git pull and then another quick test at fast speeds

[ghost]

I also changed it so it only adds F when it changes

G1 X13.000 S1.00
G1 X13.200 S1.00
G1 X13.400 S1.00
G1 X13.600 S1.00
G1 X13.800 S1.00
G1 X14.000 S1.00
G1 X14.200 S1.00 F3000
G1 X14.400 S0.50 F4494
G0 X24.200 S0
G1 X24.400 S0.31 F5058
G1 X24.600 S1.00
G1 X24.800 S1.00
G1 X25.000 S1.00
G1 X25.200 S1.00
G1 X25.400 S1.00
G1 X25.600 S1.00
G1 X25.800 S1.00
G1 X26.000 S1.00
G1 X26.200 S1.00
G1 X26.400 S1.00 F3000
G0 Y26.258
G0 X26.400 S0
G1 X26.200 S1.00
G1 X26.000 S1.00
G1 X25.800 S1.00
G1 X25.600 S1.00
G1 X25.400 S1.00
G1 X25.200 S1.00
G1 X25.000 S1.00
G1 X24.800 S1.00
G1 X24.600 S1.00
G1 X24.400 S1.00 F3000
G1 X24.200 S0.31 F5058
G0 X14.400 S0
G1 X14.200 S0.50 F4494
G1 X14.000 S1.00
G1 X13.800 S1.00
G1 X13.600 S1.00
G1 X13.400 S1.00

[ghost]

Accel 3000 Optimise off 40-40 engrave jpg image

See attached screen grab & video

https://cp.sync.com/dl/1904416a0#tabu5y28-6qj32xps-eaj8utdz-dpsc3aeu

[ghost]

OK, i finally managed to replicate the same symptom (looking at the video)... Now i can really dig in and find why

[ghost]

Ok, just pulled and tested the recent version. Although the movement is still jittery, it is consistently jittery. By this I mean the stop-starting you can see in the video is significantly improved. Its a constant jittery movement.

Heading in the right direction Pete!

We will run some tests at varying accelerations now and test raster.js more.

[ghost]

@DarklyLabs

Admittedly, we have only tried one image and had to edit the gcode because of some 'SNaN' entries. More experimentation is needed.

Fixed this morning (due to pixel subdivision)

[ghost]

@lautr3k Excellent. We will retest. By the way, nice work on this. Very simple and straight forward to use.

[ghost]

@DarklyLabs quick observation: If I export the gcode, and run it from pronterface, it feels smoother to me (Still trying to determine if its a serial comms issue as I suspected initially, or still a gcode best practise, seeing as we now have gcode thats to spec)

Can you also confirm if its smoother via Pronterface?

[ghost]

@openhardwarecoza LW send commands to Smoothie durring the job ? if yes how many time by minute ?

[ghost]

@lautr3k once every 100ms

[ghost]

haaaaaaa stop this!!!

[ghost]

@lautr3k for what its worth, with that function commented, it doesnt improve much

[ghost]

@lautr3k @openhardwarecoza Just ran some tests with Sebastien's raster.js. Same image and setting as we have been testing with LW3. It looks like the movement with this latest version is indistinguishable from the latest version of LW3 Peter just released.

Both tests were run through pronterface. See video of raster.js code running. Difficult to show vibrations via video, but you can see the hi-tech indicator straw! Plus, look closely at that unusual move towards the end. We have seen this happen with both LW3 and raster.js at higher speeds.

https://cp.sync.com/dl/5fa20e130#y2neww9x-knfiytid-e6pikrmu-gpgxgpym

[ghost]

@DarklyLabs i love the straw-vibratormeter instrument!

Yeah we are pretty much the same now.

I've got to get to work, @lautr3k dont you want to take a nack at it and see if you can make it any smoother (seeing as my gcode is now how guys wanted it)

[ghost]

@openhardwarecoza Apart from the fact that Rasterizer.js is 10x faster and does not block the parser when another tab is opened (WebWorker) ;)

[ghost]

I also think that the change of line is also more fluid in my implementation.

LaserWeb

Rasterizer.js

[ghost]

@DarklyLabs

Both tests were run through pronterface.

Please test both files from the SD card.

[iceman1979]

I played around with the code in laserraster.js last night and was able to get some interesting results. I have not tried the latest changes yet but I wanted to post what I found.

Here is the gcode that I ran both in LW3 and UGS. Only the background white was removed and the white in the image is 254,254,254 so it did not skip those pixels. I can make the whites inside the image areas to be above the 0.05 threshold so that it generates gcode for them so that's not a big deal. Beam width: .1 Black/White speed: 1800 mm/min MarioYoshi.txt

Here is the result from LW3. Notice the little black dots? These are from slight pauses which (for GRBL), I believe is related to the status requests while running gcode. After a while it started to clear up but you can see some black dots here and there throughout the rest of the image.

I ran the same code through UGS and this was the result. You can see one or two dots but for the most part it was a lot smoother running.

I think with the latest version, I believe it will produce similar gcode (setting both black and white spped the same) and the occasional feedrates when black and white speeds are different shouldn't be a problem but I'll test to be sure.

[iceman1979]

Oh, and here is the image I used.