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]

From Arthur Wolf: @arthurwolf Smoothie has more advanced motion planning, we have observed with the way laserweb produces gcode, that can result in jerky movement. It's simply because Smoothie cuts less corners in it's math and really applies all the optimisations it can from the gcode, and those really don't play well with the way LW3 generates raster gcode ( which has optimisations of it's own that don't really take into account the fact that planning takes place ). Skarab has created a script that generates Gcode a different manner, that works perfectly fine with Smoothie and gives even better engraving results, but I don't think it's been integrated into anything yet.

[ghost]

@arthurwolf Can you point us to the script by Skarab?

[arthurwolf]

@lautr3k ?

[ghost]

Working on an workaround for the canvas size limitation... since we need to scale up at an insane size to match the beam diameter (ex.: 1px = 0.1mm)

[ghost]

Can you elaborate? I dont see how that would affect anything? We don't read from the threejs objects for raster at all (bitmap>paperjs>gcode)

I rather suspect Jerkyness comes from waiting for OK on send (counting bytes would be a lot more advanced queue management plan, but as per https://github.com/openhardwarecoza/LaserWeb3/issues/1 that was the recommended easiest way

@arthurwolf can you elaborate on "Smoothie has more advanced motion planning, we have observed with the way laserweb produces gcode, that can result in jerky movement."

[ghost]

@openhardwarecoza Sorry for the lack of precision and the confused response.

Smoothie has more advanced motion planning...

• What we want is the most constant speed as possible (same speed for black and white), moreover specifying a different speed for each G1 is not good for Smoothie.

We don't read from the threejs objects for raster at all (bitmap>paperjs>gcode)...

• From my point of view, paperjs is absolutely useless (even if the library is used only for that) my way is (bitmap->gcode), the problem is on some browser the canvas object has a size limitation.

Why we need to scale ? Draw a square of 100x100mm at 25.4PPI (1PPM) => Bitmap 100x100px If the beam diameter is 0.1mm (Y resolution) the resulting square size is 10mm (100x0.1) and we requested 100x100mm... If we do not want to lose the resolution, we need to scale the image to match the beam diameter : Pixel per millimeters (PPM) = 1 Scale ratio = 1 / 0.1 = 10 Scaled size = 10x100 = 1000px

Ok 1000px seems reasonable, but this is for a 10cm square (I have an working area of 1000x600mm, and it is far from being the largest). In addition I would like the library compatible with a maximum of browser (especially on tablets).

[ghost]

The use of different speeds across the range is entirely optional (if you use same value for both it does not scale speed) however, this function makes LaserWeb able to do grayscale over a variety of machines... This method was invented by MrBeam http://blog.mr-beam.org/post/129226830399/photo-engraving - without it many users would suffer image quality issues.

Paperjs has built in raster resizing (which we already do to match pixel size to spot diameter) https://plus.google.com/105080379699420524192/posts/9YRktfoQfge

So, still, i fail to see how any of these lead to jerky movements?

@darklylabs maybe a video is in order to understand better. Also take it to the g+ community where we have a much larger audience of actual users who can tell you if they see the same or not

[ghost]

@openhardwarecoza I would like to know whether this is a problem we are just experiencing or it is experienced by others. We have tested code generated by LW3 on both our PCB as well as an original Smoothieboard with exactly the same results. The left to right movement is extremely choppy and stop/start, resulting in very poor engravings. It is simple to replicate. Simply load an image, have LW3 generate the GCode and try to engrave it. We have tested this with the same values for Light and Dark feed-rates with no improvement.

Do you get this result on your Smoothieboard or is it perfectly smooth motion?

@arthurwolf If this is something we are only experiencing then perhaps there is a config setting that is causing this? We are pretty much running a default config file with respect to the motion side of things.

[ghost]

@lautr3k Can you post a sample of the modified G-Code you are generating so we can see what is different between what you have and the LW3 version with respect to engraving?

[ghost]

Default config. That's why i say, involve the community. The larger audience there will be able to tell you some numbers. I know most people drastically bump up the acceleration

[ghost]

@openhardwarecoza @arthurwolf We have run some extensive testing. During different runs we discovered that when on the 'jog' tab, movements are much 'rougher' than when on the 'gcode' tab while running a raster engraving.

This has changed our original observations. The results below are when we are not on the 'jog' tab.

Accel=3000 Dark-Light (mm/sec) 30-30 through to 30-60 Smooth motion. ok 40-60 bad

Accel 6000 Similar to accel=3000 Higher frequency jerkiness

Accel=500 20-40 ok 30-60 ok 40-60 slight jerkiness (much improved) 60-60 No jerkiness but speed variations 80-80 Speed variations and slight jerkiness

It looks to be how smoothieware handles the gcode. We are using extremely simple gcode. Testing it with an 'F' setting on each line (even if not changing) and an 'F' only on the lines where it changes makes no difference.

[ghost]

Can you elaborate? I dont see how that would affect anything? We don't read from the threejs objects for raster at all (bitmap>paperjs>gcode)

I rather suspect Jerkyness comes from waiting for OK on send.

On Oct 22, 2016 8:12 AM, "Sébastien Mischler (aka skarab)" < notifications@github.com> wrote:

Working on an workaround for the canvas size limitation... since we need to scale up at an insane size to match the beam diameter (ex.: 1px = 0.1mm)

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

[cojarbi]

Could this be similar?  https://m.facebook.com/groups/441613082637047?view=permalink&id=758533540944998

Ariel Yahni

On Sun, Oct 23, 2016 at 6:45 AM -0500, "Peter van der Walt" notifications@github.com wrote:

The use of different speeds across the range is entirely optional (if you use same value for both it does not scale speed) however, this function makes LaserWeb able to do grayscale over a variety of machines... This method was invented by MrBeam http://blog.mr-beam.org/post/129226830399/photo-engraving - without it many users would suffer image quality issues.

Paperjs has built in raster resizing (which we already do to match pixel size to spot diameter)

So, still, i fail to see how any of these lead to jerky movements?

@darklylabs maybe a video is in order to understand better. Also take it to the g+ community where we have a much larger audience of actual users who can tell you if they see the same or not

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[cojarbi]

Look at the vifdeo I posted, by what you said on the config I'm almost sure is the same. It has to do with default feed and seek rate. Also increase acceleration.

Ariel Yahni

On Sun, Oct 23, 2016 at 3:42 PM -0500, "DarklyLabs" notifications@github.com wrote:

@lautr3k Can you post a sample of the modified G-Code you are generating so we can see what is different between what you have and the LW3 version with respect to engraving?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[arthurwolf]

Very basic explanation : to get the best results when engraving with Smoothie, you want constant speed, and constant gcode size ( length of pixels ). If you don't, Smoothie is going to accelerate, decelerate, change speeds and adjust laser power, resulting in jerky motion and incorrect laser powers.

On Sun, Oct 23, 2016 at 9:15 AM, Peter van der Walt < notifications@github.com> wrote:

Can you elaborate? I dont see how that would affect anything? We don't read from the threejs objects for raster at all (bitmap>paperjs>gcode)

I rather suspect Jerkyness comes from waiting for OK on send (counting bytes would be a lot more advanced queue management plan, but as per #1 https://github.com/openhardwarecoza/LaserWeb3/issues/1 that was the recommended easiest way

@arthurwolf https://github.com/arthurwolf can you elaborate on "Smoothie has more advanced motion planning, we have observed with the way laserweb produces gcode, that can result in jerky movement."

— 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-255573501, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFTVXS0slPmnCc0jiQ8CbUw7IFekxks5q2wmagaJpZM4Kcrxj .

Courage et bonne humeur.

[ghost]

The use of different speeds across the range is entirely optional (if you use same value for both it does not scale speed) however, this function makes LaserWeb able to do grayscale over a variety of machines... This method was invented by MrBeam http://blog.mr-beam.org/post/129226830399/photo-engraving - without it many users would suffer image quality issues.

Paperjs has built in raster resizing (which we already do to match pixel size to spot diameter)

So, still, i fail to see how any of these lead to jerky movements?

@darklylabs maybe a video is in order to understand better. Also take it to the g+ community where we have a much larger audience of actual users who can tell you if they see the same or not

On Oct 23, 2016 12:04 PM, "Sébastien Mischler (aka skarab)" < notifications@github.com> wrote:

@openhardwarecoza https://github.com/openhardwarecoza Sorry for the lack of precision and the confused response.

Smoothie has more advanced motion planning...

• What we want is the most constant speed as possible (same speed for black and white), moreover specifying a different speed for each G1 is not good for Smoothie.

We don't read from the threejs objects for raster at all (bitmap>paperjs>gcode)...

• From my point of view, paperjs is absolutely useless (even if the library is used only for that) my way is (bitmap->gcode), the problem is on some browser the canvas object has a size limitation http://stackoverflow.com/questions/6081483/maximum-size-of-a-canvas-element .

Why we need to scale ? Draw a square of 100x100mm at 25.4PPI (1PPM) => Bitmap 100x100px If the beam diameter is 0.1mm (Y resolution) the resulting square size is 10mm (100x0.1) and we requested 100x100mm... If we do not want to lose the resolution, we need to scale the image to match the beam diameter : Pixel per millimeters (PPM) = 1 Scale ratio = 1 / 0.1 = 10 Scaled size = 10x100 = 1000px

Ok 1000px seems reasonable, but this is for a 10cm square (I have an working area of 1000x600mm, and it is far from being the largest). In addition I would like the library compatible with a maximum of browser (especially on tablets).

— 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-255579692, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr29gRXvm5yJIYNErdnLCo5BiuZ7afks5q2zEXgaJpZM4Kcrxj .

[arthurwolf]

Even if you don't use different speeds, using different lengths causes the motion planning to change nominal speeds when the queue is full. You want constant speeds, constant pixel width.

On Sun, Oct 23, 2016 at 1:45 PM, Peter van der Walt < notifications@github.com> wrote:

The use of different speeds across the range is entirely optional (if you use same value for both it does not scale speed) however, this function makes LaserWeb able to do grayscale over a variety of machines... This method was invented by MrBeam http://blog.mr-beam.org/post/ 129226830399/photo-engraving - without it many users would suffer image quality issues.

Paperjs has built in raster resizing (which we already do to match pixel size to spot diameter)

So, still, i fail to see how any of these lead to jerky movements?

@darklylabs https://github.com/darklylabs maybe a video is in order to understand better. Also take it to the g+ community where we have a much larger audience of actual users who can tell you if they see the same or not

— 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-255584070, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFSsSZjjD5k1ma-SaFf4UwxVFSPdlks5q20jjgaJpZM4Kcrxj .

Courage et bonne humeur.

[iceman1979]

I have seen the benefit of skipping over blank lines, constant speed engraving, and variable speed engraving too. Maybe the solution is a better serial TX manager for smoothie and GRBL so that their buffers don't get full.

[arthurwolf]

Smoothie absolutely necessitate constant speed and constant pixel width to engrave correctly. This has nothing to do with buffers, has to do with how well it does motion planning, and there is no way to work around this. Skarab wrote a script ( that did constant speed/pixel width ) in just a few hours back when we were setting up his lasers, and it gave much better results than LW did.

On Tue, Oct 25, 2016 at 9:45 PM, iceman1979 notifications@github.com wrote:

I have seen the benefit of skipping over blank lines, constant speed engraving, and variable speed engraving too. Maybe the solution is a better serial TX manager for smoothie and GRBL so that their buffers don't get 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-256154657, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFbh2Sjg5zFYDiaTn7aLSMMiO7w25ks5q3lw-gaJpZM4Kcrxj .

Courage et bonne humeur.

[iceman1979]

So is smoothie targeted more towards CO2 lasers than diode lasers?

Here is an image I have been working on for my wife and with my 2W laser I have to go slow, like 1800 or less and sweeping across the entire image adds a lot of time to the engraving.

I have been using a program called T2Laser which parses the gcode in such a way that it produces constant speed within the engraving areas but skips blank lines. Here is a quote from the author. "T2Laser will skip areas outside of engraving and lines without any engraving but internal spaces need to be traveled at the constant speed.".

So what you are saying is that smoothieware will have problems with gcode parsed this way. This also means that LW3 which is targeted for smoothieware is going to have problems with rasters. Obviously this won't affect CO2 lasers but those of us with diode lasers are going to be impacted by long engraving times.

There is a growing community of diode laser engravers and I would hope that in the future, smoothieware would better support raster laser engraving and follow some of the well documented raster engraving techniques so that programs like LW3 and others can produce stunning images with smoothieware.

[ghost]

@arthurwolf We used to send every pixel but that was way way slower. So one of the first optimisations we did was that if several consecutive pixels has the same shade, we generate a single G1 line of the total length of the same shaded pixels. I honestly dont see why that would break the planner. In 3D printing no two moves are the same length, arcs are broken up into small segments, stls are by nature vertexed (small moves of inconsistent size for every move.

Constant speed is a problem. As per the extensive testing we did in Dec 2015, without it you simply cannot get perfect grayscale with a PWM implementation. DSPs use constant speed because its a PPI implementation... Besides, if we look at @DarklyLabs testing we see that constant speed did not fix this...

@wolfmanjm hoping you can shed some, non blaming, scientific light on this. In plain terms what needs to change then.

[ghost]

@arthurwolf @wolfmanjm @openhardwarecoza The advanced work the planner is doing is fantastic but it seems to fall down with the requirements of laser diode engraving. This is a basic requirement for the smoothieboard/firmware to be able to handle. We have been doing this for many years with our GRBL systems and achieving amazing engraving results.

Are there any parameters that can be exposed or adjusted to assist it in handling this requirement? As Peter mentions, please help us understand what needs to change?

@lautr3k Can you share a snippet of the GCode created by your script so we can examine the difference between it and what we have now from LW3?

[ghost]

@DarklyLabs I'm doing a library and a repo test, it will be published in the day.

[wolfmanjm]

I see no reason smoothie would have any issues with this code, switching between G0 and G1 is fine and handled properly. Constant speed is not an issue either, and not required you can specify a different speed each segment it is just that depending on how short the segment is whether it will reach the new speed or not. The issue I see is that the planner is 32 moves long (each move will be a gcode unless segmentation is on). and once the planner is full the host cannot send any more data until there is room in the buffer. If the moves are very very short it is possible that the actual move is faster than a new move can be sent to the planner, so basically what happens is that the queue is always empty, this means that every move has to decelerate to zero. This cannot be avoided however there is some logic that requires the planer queue to fill up initially before it will start moving, but if the queue empties I am not sure that it can do more than execute one gcode at a time as it receives them. I am not sure this is the issue you are running into though.

[ghost]

@wolfmanjm thank you! Thats what I thought all along.

This explains why once feedrate goes over 40mm/sec the issues start appearing (moves execute so quick, serial can't keep up (which is why I kept saying serial is more likely the cause than the actual gcode)

Which takes me back to the testing I asked for in https://plus.google.com/u/0/117537980354391774283/posts/j711CAv2tN4

• Uploading to SD first should help prevent under running, correct @wolfmanjm ?

[ghost]

So why do I have the same problem as I only work with SD card ?

[wolfmanjm]

Ok so this may improve things a bit (or make it worse) there is an undocumented config option queue_delay_time_ms whose default is 100ms. Everytime the planner queue is empty it will wait for either 100ms or for the queue to fill up before it will process any moves. Setting it to 0 will disable this and force it to execute whatever moves are in the queue. for extremely short segments it may be better to set this to 0 but it will need some testing as I am not sure what is better. Running from sdcard is not a whole lot faster than streaming over USBserial so they both will suffer the same issue. SDcard is very slightly better but not by much. if you cannot keep the planner queue full then every move will decelerate to zero which would be jerky. AFAIK there really is nothing you can do to fix this other than to slow the moves down so the planner queue can be kept full.

[ghost]

@DarklyLabs can you give queue_delay_time_ms a quick test?

[wolfmanjm]

Maybe it is time to reconsider a special LW3 only command that sends a raster line at a time? This will require some thought and planning, we can't send binary data so it may need to be uuencoded or maybe a run length encoding that is ascii only. Not quite sure what we would do on the smoothie side but it should keep the queue full I would think. It will be a little like the way we handle segmented arcs and segmentation on deltas I think. Worth thinking about.

[ghost]

That would be a really cool and beneficial implementation!

Marlin uses a Base64 implementation: https://github.com/TurnkeyTyranny/buildlog-lasercutter-marlin/blob/master/Marlin/Marlin_main.cpp#L1070

Lasersaur's protocol is documented here https://github.com/nortd/driveboardapp/blob/6409230a68bb653ea43a197ce9c091c9fef01188/docs/protocol.md#raster-data-mode

[wolfmanjm]

As with all things Marlin I wouldn't touch it with a barge pole ;) (even if I had any idea what they were doing). The other protocol is also something I would't use. You want to be able to set the speed different on every pixel or run of pixels right? so neither of those allow that . Also I do not want to parse a raster in smoothie either.

I was thinking more of a way to specify the same kind of gcode you currently send but in a more compact way so more lines get sent over the serial (or read from sdcard) at a time. then smoothie simply unpacks the commands and expands them into regular planner lines. So LW3 does all the work, and smoothie just unpacks them and handles them like it would regular gcode. Does that make any sense?

[ghost]

@wolfmanjm Great info. Thank you! Does the buffer empty theory also explain why lowering the acceleration as we tested (500) improves the movement at higher feed-rates?

@openhardwarecoza I will try the queue_delay_time_ms when I'm back in the Lab and report back.

[wolfmanjm]

The lines need to not exceed the USB serial buffer size, but should contain the same info that a sequence of gcode would so the start position, the laser power for each sequence and the feedrate for each sequence. something along those lines.

[wolfmanjm]

@DarklyLabs yes reducing acceleration will make each planner queue block take longer to actually execute. Same as reducing feedrate.

[ghost]

Hahaha! I agree. I only shared it as examples of what the opposition does (;

Keeping to a more standard gcode style makes my CAM side code easier too, so no objections

[ghost]

@DarklyLabs I'm not seeing your replies. Github seems to be broken with email replies the last couple days...

[ghost]

@wolfmanjm If the Smoothie known the width and height of the bitmap at startup, it can easily determine the x / y position. I would see a code like this :

raster 50 50 ; send bitmap width and height
pixel 0.8 ; send pixel intensity
pixel 0.7 1500 ; optionaly set the feedrate
pixel 0.6 ; next pixel
pixel 0.8 ; next pixel
pixel 0.9 ; next pixel

Or by line :

raster 50 ; send bitmap height
line 0.8 0.7/1500 0.6 0.8 .09

[arthurwolf]

@DarklyLabs : I don't understand why you think there would be a difference between co2 lasers and diode lasers. It makes no difference to Smoothie. All I'm saying is that to engrave properly, Smoothie requires a constant speed, and a constant pixel width. This just means that some optimisations people have added do not play nice with the motion planner, that's all. Removing the optimisations solves the issue, as we saw with @lautr3k when he wrote his test script. Again : we had a script that did raster much better than lw does, simply because it didn't have the optimisations lw has. Those are not necessary, and are incompatible with the motion planner, I don't see why they can't simply be removed when using Smoothie ...

On Wed, Oct 26, 2016 at 8:23 AM, Sébastien Mischler (aka skarab) < notifications@github.com> wrote:

@wolfmanjm https://github.com/wolfmanjm If the Smoothie known the width and height of the bitmap at startup, it can easily determine the x / y position. I would see a code like this :

raster 50 50 ; send bitmap width and height pixel 0.8 ; send pixel intensity pixel 0.7 1500 ; optionaly set the feedrate pixel 0.6 ; next pixel pixel 0.8 ; next pixel pixel 0.9 ; next pixel

Or by line :

raster 50 ; send bitmap height line 0.8 0.7/1500 0.6 0.8 .09

— 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-256259828, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFaSpM8jtJVSK2cvPBpUJ0rJgZeRfks5q3vHdgaJpZM4Kcrxj .

Courage et bonne humeur.

[ghost]

I have no problem making optimisation configurable... The problem is we havent verified that thats the case. @wolfmanjm doesnt agree. See above. Also, You havent been able to give @DarklyLabs one of these test files to compare (or for me to see what you consider ideal gcode so I can change to match)

[ghost]

@openhardwarecoza @DarklyLabs Please try this... https://lautr3k.github.io/rasterizer.js/ https://github.com/lautr3k/rasterizer.js

EDIT: I have not tested enough, please load the GCode into LW for a preview before starting the job !

[ghost]

@lautr3k thank goodness its compatible with my viewer still (;

\ Sample output from Rasterizer.js**

; Generated by Rasterizer.js (alpha)
; Size       : 57.30 x 47.60 mm
; Resolution : 0.1 PPM - 254 PPI
; Beam size  : 0.1 mm
; Beam power : 0% to 100%
; Feed rate  : 1500 mm/min

G0 F1500
G1 F1500

G0 X29.35 Y0.05
G1 X29.35 S0.1242
G1 X29.45 S0.5190
G1 X29.55 S0.6340
G1 X29.65 S0.8261
G1 X29.75 S0.9137
G1 X29.85 S0.8902
G1 X29.95 S0.8549
G1 X30.05 S0.8261
G1 X30.15 S0.7752
G1 X30.25 S0.7490
G1 X30.35 S0.6941
G1 X30.45 S0.6667
G1 X30.55 S0.5490
G1 X30.65 S0.4889

So the most major difference is setting F before the job (Which would work on some lasers, but NB NB NOT ON ALL: Please read the detailed entry by MrBeam here http://blog.mr-beam.org/post/129226830399/photo-engraving for understanding as to why)

The other difference is that theres 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?

I do sort of agree that an F on every line may cause issues (but again, @wolfmanjm , confirm or deny?)

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)

Sample output from LaserWeb:

G0 F4200
G0 Y125.942
G0 X60.000 S0
G1 X60.200 S0.08 F1200
G1 X60.400 S0.16 F1200
G1 X60.600 S0.25 F1200
G1 X60.800 S0.43 F1200
G1 X61.000 S0.56 F1200
G1 X61.200 S0.61 F1200
G1 X61.400 S0.59 F1200
G1 X61.600 S0.47 F1200
G1 X61.800 S0.34 F1200
G1 X62.000 S0.21 F1200
G1 X62.200 S0.10 F1200
G1 X62.400 S0.01 F1200
G0 Y125.742
G0 X62.600 S0
G1 X62.400 S0.01 F1200
G1 X62.200 S0.02 F1200
G1 X62.000 S0.14 F1200
G1 X61.800 S0.33 F1200
G1 X61.600 S0.51 F1200
G1 X61.400 S0.62 F1200
G1 X61.200 S0.71 F1200
G1 X61.000 S0.73 F1200
G1 X60.800 S0.69 F1200
G1 X60.600 S0.59 F1200
G1 X60.400 S0.47 F1200
G1 X60.200 S0.28 F1200

[ghost]

@pflugj - just tagging you too, I know you did some extensive testing with how best to structure the gcode line structures here https://github.com/openhardwarecoza/LaserWeb3/issues/71#issuecomment-237503203 for Grbl specifically

[ghost]

@DarklyLabs - sitting here holding thumbs to hear from your results on a rasterizer.js test

[iceman1979]

According to the documentation for GRBL 1.1 the ok is sent once the move is executed, where smoothie returns the ok once the move has been stored in the buffer. Once the buffer is full in smoothie, both GRBL and smoothie are operating similarly in that it will result in one line being sent and waiting for an ok. For GRBL, this means that each line needs to be as short as possible or you risk moving faster than the data can be sent over USB. It also sounds like smoothie would benefit from more frequent but smaller lines being sent as well (ie one line per pixel). However, I don't believe every pixel needs to be sent either and one optimization that I believe could be applied successfully is to continue to travel to the first and last non-white pixel for each line of the image but also not skip over white pixels in-between.

To help reduce the size of each line, exclude consecutive G1 commands and only include the F & S commands when they change. For cases where the black and white feed rates are the same, set the feed rate at the beginning and exclude the feed rate command from each line.

I have a test file at home that I can post that works well in LW3. It follows the approach I mentioned. I would be curious how it worked with smoothie. If your interested I can post here for someone to try and see.

EDIT: I updated my comments to more accurately reflect what I was trying to say and to not spread misinformation. my apologies.

[ghost]

@iceman1979 - I have told you this on G+ twice now, and again a 3rd time here (: please listen this time as I am getting a little irate about the small detail. WE DO NOT TRAVEL THE FULL WIDTH! WE SKIP WHITESPACE

Note the green moves in this preview! Thats the only non burn moves. If we were going all the way to the bounds there would be green G0 move lines all the way to the edge

heres a VERY OLD example from April 2016 BEFORE WE ADDED WHITESPACE Skipping... Note the different User Interface - that was in LaserWeb1 days! (I hope you are on Laserweb3 and not on 1....)

Now, please stop spreading this false information in several threads (:

[cojarbi]

I cannot get a preview nor the gcode on LW, but if i hit play it moves very slowly X+ then X- and thats it This is the file from restarizer. I did the exact same settings on LW with success OpenbuildsBlackbox.gcode.txt

[ghost]

To help reduce the size of each line, exclude consecutive G1 commands and only include the F & S commands when they change. For cases where the black and white feed rates are the same, set the feed rate at the beginning and exclude the feed rate command from each line.

I have a test file at home that I can post that works well in LW3. It follows the approach I mentioned. I would be curious how it worked with smoothie. If your interested I can post here for someone to try and see.

Please do post it. Any more tests are helpful

FYI LaserWeb Only sends new S and F when it changes in a raster.... But the way we optimise, each line WILL HAVE a different F and S value (unless you set black and white speed the same, which almost no machine will be able to give perfect grayscale on) - becuase consecutive same F, Same S pixels are not sent as pixels, but as a line

[ghost]

@cojarbi - i see a Resolution entry in the comments that its 0.042333' (is that a 0.04mm spot size? that would be very slow)

[ghost]

PS: Another NB entry from MRBeam is this one: https://wiki.mr-beam.org/doku.php?id=photo_tutorial&s[]=photo

[chamnit]

@iceman1979 : To add upon preventing the spread of false information. You are incorrect on how Grbl streaming works. Grbl sends an 'ok' response after it has parsed and interpreted the g-code line, not executing a motion. If it's a motion command, it's placed into the planner queue, which can be anywhere from 14 to 18 total queued motions. If this wasn't true, then Grbl would stutter like crazy and be unusable. The basis of how Grbl works is the same on Smoothie and Marlin, as they are both direct cousins of Grbl.

@openhardwarecoza : Thanks for the v1.1 report! I'm happy to hear that users are liking it. I also plan on adding constant power/rate to account for acceleration phases into corners and such.

As for having anF command on every line, Grbl can handle it fine, but it does create a lot of unnecessary serial comm. With laser cutting and anything that has short line segments and fast tool paths, you want to reduce the serial stream as much as possible. This reduces latency and improves the high-end performance of the machine. Meaning that Grbl will move smoothly through the fast tool paths and not stutter when its motion buffers are starved from the lack of throughput.

I know that UGS, one of the highest performing Grbl senders, applies a filter to gets rid of spaces, capitalizes all letters, and removes comments automatically before sending to Grbl. This helps with removing unnecessary characters being sent to Grbl.