search

LaserWeb / LaserWeb4

Collaborative effort on the next version of LaserWeb / CNCWeb
GNU Affero General Public License v3.0
704 stars 190 forks source link

Raster issues: Smoothieware Jerkyness / did we need a new protocol, proper discussion #99

Closed ghost closed 7 years ago

ghost commented 7 years ago

Paraphrasing from a discussion with @wolfmanjm in Oct:

@wolfmanjm said Maybe it is time to reconsider a special LW 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.

@openhardwarecoza said 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 said 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? 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.

So with that said, heres some basic groundwork:

cprezzi commented 7 years ago

Ok, I realized that you need a Gx in front of every single move on the line, which I had deleted. This way, S values are correctly executed, but speed improvement is only about 50%. At least better than nothing.

wolfmanjm commented 7 years ago

@cprezzi well 50% is quite good IMO. (and counter to my investigations). Can you paste an example of the output you are generating now? And yes the parser in Smoothie breaks the long lines up at a Gx or Mx boundary.

cprezzi commented 7 years ago

Here's a typical line:
G1X38.500S0.10G1X38.100S0.11G1X33.900S0.20G1X33.800S0.28
(This could be optimized even more by deleting unneeded decimals)

@wolfmanjm Why do you handle S values different than X/Y/Z?
I mean, why is G1S0.9X0.1X38.1X33.9X45 working
but G1S0.9X0.1S0.5X38.1S0.7X33.900S0.3X33.800 is not? (ignores consecutive S values)

I'm sorry for spoiling this thread again! Any further discussion about smoothie specific communication can be found here: https://github.com/LaserWeb/LaserWeb3/issues/207#issuecomment-269022044

arthurwolf commented 7 years ago

A little exploration of how to send Gcodes for raster engraving as fast as possible. This is mostly for myself, to try to wrap my mind around what can be done here, but maybe it'll be of interrest for the conversation.

Here is what basic engraving Gcode looks like :

G90 G1 X100.1 S0.90 G1 X100.2 S0.85 G1 X100.3 S0.80 G1 X100.4 S0.75 <...>

Now, G1 is modal, so we can do ( assuming the controller is not confused by S being used in modal Gcodes ) :

G90 G1 X100.1 S0.90 X100.2 S0.85 X100.3 S0.80 X100.4 S0.75 <...>

Another improvement we can do is move from absolute to relative gcode :

G91 G1 X0.1 S0.90 X0.1 S0.85 X0.1 S0.80 X0.1 S0.75 <...>

I think that's as far as you can go with the current Smoothie firmware's interpreter ( I may be wrong ), all the things bellow would demand new code : Now I don't know if the Gcode spec says we should, but we could go even a bit further by doing :

G91 G1 X.1 S.90 X.1 S.85 X.1 S.80 X.1 S.75 <...>

From there we can also remove spaces and trailing zeroes :

G91 G1X.1S.9 X.1S.85 X.1S.8 X.1S.75 <...>

Now it's pretty obvious that the X.1 here is repeated on each line so we could get rid of it. Unfortunately, while the Gcode spec allows us to get rid of G1 ( modal G1 ), I don't know of any way to get rid of X this way.

( Talking Smoothie here, other controllers would have different ways of handling this ). We could have a special Gcode that setups a new modal mode ( handled by the laser module ) :

G91 M1234 X0.1 S.9 S.85 S.8 S.75

( which internally essentially would convert these "only S" lines into "G1 X0.1 Sxx" lines )

Now that's sticking to Gcode ( and stretching it pretty far ), but we can go even further by going outside of the Gcode spec ( the way Smoothie does with http://smoothieware.org/console-commands for example ) :

laser_setup 0.1 engrave TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGldWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

Or whatever other syntax that'd make everybody happy.

Now, this base64 syntax is about two bytes per pixel, compared to about 5 per pixel for the best S syntax above. Which is 250% better.

Really, all the gcode based syntaxes here are things we can do today ( or with some minor modifications to the firmware ), but the base64 one would be a huge leap from what we do now.

Just for fun, there is a way to do this by sticking within the gcode's syntax's limits, but it's pretty dirty. Gcode doesn't have a limit on the number of decimal places ( well, some documents will say 64 or 128 but I think they talk about specific implementations )

So you could do :

M1234 X0.1 S0.1234567890123456789012345678901234567890

And then unpack that into a series of bytes to engrave, and internally convert them into "G1 X0.1 Sxx" commands. It's not as compact as base64, but it is a small improvement over the "S only" syntax, and it is dirty but valid Gcode.

On Fri, Dec 23, 2016 at 12:35 PM, Claudio Prezzi notifications@github.com wrote:

Here's a typical line: G1X38.500S0.10G1X38.100S0.11G1X33.900S0.20G1X33.800S0.28 (This could be optimized even more by deleting unneeded decimals)

Why do you handle S values different than X/Y/Z? I mean, why is G1S0.9X0.1X38.1X33.9X45 working but G1S0.9X0.1S0.5X38.1S0.7X33.900S0.3X33.800 is not?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/99#issuecomment-268977510, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFekAuoK0aU6_CYp9jKXUHc3Fjn6aks5rK7HqgaJpZM4LR0oN .

-- Courage et bonne humeur.

cprezzi commented 7 years ago

@arthurwolf Your summary is correct, as far as I can judge. But the problem is not only the length of the code, it's the transfer speed and as we learned short lines are inefficient.

I think we realy need a new method for transfering raster data.

Personally I like the canned cycle idea from Sonny, but I think your proposal is not so far away from that.

cprezzi commented 7 years ago

I am realy asking myself: Why don't we just extend the gcode "standard" (together with the gcode guys), as raster data is a big need for a lot of people and machine manufactorers. A standard that doesn't evolve will not life for very long!

ghost commented 7 years ago

@arthurwolf @chamnit I've just worked through this discussion. Lots of very interesting ideas bouncing around. Thanks for talking through your thought process. It certainly helps to see the logic behind the ideas.

Which of the two approaches could be tested to check proof of concept and results?

aldenhart commented 7 years ago

You might not know that Rob ( @giseburt ) spent the over a decade writing low-level rendering and printing code for PDF and other other production print tools. I've been working with Rob this week to flesh the ideas for a raster protocol. It starts with the Gcode canned cycle idea - attempting to take this to a minimum viable protocol (MVP) level that addresses the immediate issues, while laying an extensible framework for doing some really sophisticated stuff later.

Here's where we are so far. We'd really appreciate some review and feedback. https://github.com/synthetos/g2/wiki/Raster-Streaming-Protocol

Summary here:

G81.1 ({"horiz":3000},
       {"vert":2500},
       {"hres":11.811},
       {"vres":11.811},
       {"feed":10000},
       {"over":5.0},
       {"bits":8},
       {"comp":0},
       {"matr":[1,0,0,1,0,0],
       {"chars":254},
       })
;<~9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>Cj@.4Gp$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,
;O<DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKY
;i(DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIa
;l(DId<j@<?3r@:F%a+D58'ATD4$Bl@l3De:,-DJs`8ARoFb/0JMK@qB4^F!,R<AKZ&-DfTqBG%G
;>uD.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c~>
G80 (optional)

Parameters:

ghost commented 7 years ago

@aldenhart This looks very interesting. We will be able to run tests as you continue development and provide back detailed results.

I believe its important that there are a few people running real tests on equipment. We have found results vary quite a bit between people and setups. For instance, we have just been testing the smoothie_buffer @cprezzi is working on and cannot replicate his findings. We are also finding that in most circumstances, transmitting over WIF better than over USB.

These discrepancies leads me to believe there is something fundamentally wrong or being overlooked.

tbfleming commented 7 years ago

Maybe steps/mm affects reproduction? Could a higher step rate cause the step interrupt to starve communication and the planner of CPU time?

ghost commented 7 years ago

@tbfleming @cprezzi is running 80step/mm (x&y) We are running 200step/mm (x&y)

@wolfmanjm @arthurwolf Can this be a contributing factor to our performance issues? Are there any config parameters we can tweak?

aldenhart commented 7 years ago

@DarklyLabs - thanks for the review, and the offer to test.

arthurwolf commented 7 years ago

@Darklylabs : Should only play a very small factor.

On Fri, Dec 30, 2016 at 2:43 AM, DarklyLabs notifications@github.com wrote:

@tbfleming https://github.com/tbfleming @cprezzi https://github.com/cprezzi is running 80step/mm (x&y) We are running 200step/mm (x&y)

@wolfmanjm https://github.com/wolfmanjm @arthurwolf https://github.com/arthurwolf Can this be a contributing factor to our performance issues? Are there any config parameters we can tweak?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/99#issuecomment-269720402, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFezEjY-txYKS7x-ixLbgzphDB7O8ks5rNGHFgaJpZM4LR0oN .

-- Courage et bonne humeur.

FabCreator commented 7 years ago

https://www.youtube.com/watch?v=Te9RbgtTCaM Hey guys just made a little video of some raster engraving, im not sure what the issue is, but the speed is far higher when printing from sd, over sd card directly or the GLCD screen.

ghost commented 7 years ago

@aldenhart Can you please email me on domenic@darklylabs.com

ghost commented 7 years ago

Thread died... Closing. I think all the role players has this in the back of their minds