Add support for G7 raster engraving from Turnkeytyranny's marlin

[MetalMusings]

It would be great if raster engravings could be output in G7 format as done by Turnkeytyranny. The advantage over a number of G1 commands are first of all faster engravings due to different internal handling. A proper implementation in the laser controller will also make sure that intensity stays correct even when accelerating motor or if motor should stutter.

I dont think this is a big effort, laserraster.js need some additions. The syntax is rather easy

• position head lower left of image with G1
• set raster and laser options: intensity and pixel size with M649
• every bitmap line is split into 51 pixel chunks, which is output in the G7 command in base64 format, in javascript btoa() does that. The data is the pixel grayscale intensity in the range 0-255.
• add $1 or $0 to change line and tell to move right or left.

[ghost]

Firstly: marlin sucks (super slow) Secondly: g7 is proprietary to marlin whereas the g approach works on everything (which is why we can support so many boards) Thirdly: the serial is NOT the bottleneck. We have proven this countless times, even slow old grbl, lasersaur and all the way up to smoothie and tinyg, we run rasters over 115200 serial using g0/g1 all day long. No issue. Just crappy Marlin that cant keep up since the codebase is an amateur mess of code. Fourthly: marlin is dead. Long live smoothie.

In a public service - i'll suppport least viable solutions for marlin, etc. But only solutions that are cross platform.

Best way to play the firmware vendors hand

Peter On 7 May 2016 02:25, "HakanBastedt" notifications@github.com wrote:

It would be great if raster engravings could be output in G7 format as done by Turnkeytyranny. The advantage over a number of G1 commands are first of all faster engravings due to different internal handling. A proper implementation in the laser controller will also make sure that intensity stays correct even when accelerating motor or if motor should stutter.

I dont think this is a big effort, laserraster.js need some additions. The syntax is rather easy

• position head lower left of image with G1
• set raster and laser options: intensity and pixel size with M649
• every bitmap line is split into 51 pixel chunks, which is output in the G7 command in base64 format, in javascript btoa() does that. The data is the pixel grayscale intensity in the range 0-255.
• add $1 or $0 to change line and tell to move right or left.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44

[emartinez167]

Which version of Marlin are you using? The development team has done lots of improvements lately. Try using RCBugfix RC6 On Sat, 7 May 2016 at 12:11, Peter van der Walt notifications@github.com wrote:

Firstly: marlin sucks (super slow) Secondly: g7 is proprietary to marlin whereas the g approach works on everything (which is why we can support so many boards) Thirdly: the serial is NOT the bottleneck. We have proven this countless times, even slow old grbl, lasersaur and all the way up to smoothie and tinyg, we run rasters over 115200 serial using g0/g1 all day long. No issue. Just crappy Marlin that cant keep up since the codebase is an amateur mess of code. Fourthly: marlin is dead. Long live smoothie.

In a public service - i'll suppport least viable solutions for marlin, etc. But only solutions that are cross platform.

Best way to play the firmware vendors hand

Peter On 7 May 2016 02:25, "HakanBastedt" notifications@github.com wrote:

It would be great if raster engravings could be output in G7 format as done by Turnkeytyranny. The advantage over a number of G1 commands are first of all faster engravings due to different internal handling. A proper implementation in the laser controller will also make sure that intensity stays correct even when accelerating motor or if motor should stutter.

I dont think this is a big effort, laserraster.js need some additions. The syntax is rather easy

• position head lower left of image with G1
• set raster and laser options: intensity and pixel size with M649
• every bitmap line is split into 51 pixel chunks, which is output in the G7 command in base64 format, in javascript btoa() does that. The data is the pixel grayscale intensity in the range 0-255.
• add $1 or $0 to change line and tell to move right or left.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217605343

[ghost]

TurnkeyTyranny's is still on the old v1. 0 codebase. On 7 May 2016 07:10, "emartinez167" notifications@github.com wrote:

Which version of Marlin are you using? The development team has done lots of improvements lately. Try using RCBugfix RC6 On Sat, 7 May 2016 at 12:11, Peter van der Walt notifications@github.com wrote:

Firstly: marlin sucks (super slow) Secondly: g7 is proprietary to marlin whereas the g approach works on everything (which is why we can support so many boards) Thirdly: the serial is NOT the bottleneck. We have proven this countless times, even slow old grbl, lasersaur and all the way up to smoothie and tinyg, we run rasters over 115200 serial using g0/g1 all day long. No issue. Just crappy Marlin that cant keep up since the codebase is an amateur mess of code. Fourthly: marlin is dead. Long live smoothie.

In a public service - i'll suppport least viable solutions for marlin, etc. But only solutions that are cross platform.

Best way to play the firmware vendors hand

Peter On 7 May 2016 02:25, "HakanBastedt" notifications@github.com wrote:

It would be great if raster engravings could be output in G7 format as done by Turnkeytyranny. The advantage over a number of G1 commands are first of all faster engravings due to different internal handling. A proper implementation in the laser controller will also make sure that intensity stays correct even when accelerating motor or if motor should stutter.

I dont think this is a big effort, laserraster.js need some additions. The syntax is rather easy

• position head lower left of image with G1
• set raster and laser options: intensity and pixel size with M649
• every bitmap line is split into 51 pixel chunks, which is output in the G7 command in base64 format, in javascript btoa() does that. The data is the pixel grayscale intensity in the range 0-255.
• add $1 or $0 to change line and tell to move right or left.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub < https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217605343

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217608293

[ghost]

I'm open to a pull request - if you are also willing to maintain it...

[emartinez167]

We are trying to get to gold on this release, ds any new features will have to wait until after that (couple of weeks I reckon). Feel free to raise it in Github. We also have a Google hangout, so if you want, send me your email and I can ask for you to be added! On Sat, 7 May 2016 at 13:45, Peter van der Walt notifications@github.com wrote:

I'm open to a pull request - if you are also willing to maintain it...

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217609690

[ghost]

I'm not going to involve myself in any marlin development (; - cant afford distraction from this project: this is LaserWeb - if you want Marlin to continue to have support here I'm always happy to give you push rights. I just dont want to be saddled with a non-crossplatform function that i have to maintain for a very very small subsection of users (for an issue thats not really an issue - go check on google plus - couple of marlin users engraving away happily with g0/g1)

[emartinez167]

No worries! On Sat, 7 May 2016 at 13:54, Peter van der Walt notifications@github.com wrote:

I'm not going to involve myself in any marlin development (; - cant afford distraction from this project: this is LaserWeb - if you want Marlin to continue to have support here I'm always happy to give you push rights. I just dont want to be saddled with a non-crossplatform function that i have to maintain for a very very small subsection of users (for an issue thats not really an issue - go check on google plus - couple of marlin users engraving away happily with g0/g1)

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217609953

[MetalMusings]

Oh sorry, didn't realize it was such a sensitive thing. It wasn't meant as criticism to the g0/g1 method. I have used that too. Agree that speed bottleneck is not in serial, it is mostly in planner. Every g1 motion gets its own block, including acceleration calculations, and this eats a lot of the scarce processing cycles of the Mega2560. Therefor what TT did was to make one motion block for 51 pixels, and treat the laser pulses as a separate movement axis, so the laser fires at the right spot. What he didn't do so well was to extinguish the laser pulse at the right time and this can show up at the edges where there might be blacker spots/lines. It is correct in distance, but the pulse length need to be correct in time. Also the g0/g1 method has this effect, but worse. At least something has to be done to not have the laser on all the time during a g1 move at the ends, where the head is moving slower and the laser spend more time at a certain position. So I made some changes to TT's method to make sure the laser pulse for every pixel never is longer (or shorter) than intended. The result is very good, all timing related lines etc are gone. it is fully compatible with original TT G-code.

With this modification it is possible to engrave at 8500 mm/min with 0.1mm pixels and motors at 200 steps/mm. And then it is actually useful also for a Co2 laser. I'll try to push this to Marlin. And on the Due 40000 mm/min was possible with 100 steps/mm on the motors. It is at least useful.

I am secretly hoping that other firmware developers should adopt TT's G7 method, it is open and readily available, Enough of that now.

@emartinez167 My Javascript coding skills are not that great. I can of course try to do the G7 code generation for myself.

[ghost]

Its not a sensitive issue. As i said, i just dont want to maintain something if it doesn't serve the entire community. If you want to maintain it, i'll gladly accept a pull On 7 May 2016 12:48, "HakanBastedt" notifications@github.com wrote:

Oh sorry, didn't realize it was such a sensitive thing. It wasn't meant as criticism to the g0/g1 method. I have used that too. Agree that speed bottleneck is not in serial, it is mostly in planner. Every g1 motion gets its own block, including acceleration calculations, and this eats a lot of the scarce processing cycles of the Mega2560. Therefor what TT did was to make one motion block for 51 pixels, and treat the laser pulses as a separate movement axis, so the laser fires at the right spot. What he didn't do so well was to extinguish the laser pulse at the right time and this can show up at the edges where there might be blacker spots/lines. It is correct in distance, but the pulse length need to be correct in time. Also the g0/g1 method has this effect, but worse. At least something has to be done to not have the laser on all the time during a g1 move at the ends, where the head is moving slower and the laser spend more time at a certain position. So I made some changes to TT's method to make sure the laser pulse for every pixel never is longer (or shorter) than intended. The result is very good, all timing related lines etc are gone. it is fully compatible with original TT G-code.

With this modification it is possible to engrave at 8500 mm/min with 0.1mm pixels and motors at 200 steps/mm. And then it is actually useful also for a Co2 laser. I'll try to push this to Marlin. And on the Due 40000 mm/min was possible with 100 steps/mm on the motors. It is at least useful.

I am secretly hoping that other firmware developers should adopt TT's G7 method, it is open and readily available, Enough of that now.

@emartinez167 https://github.com/emartinez167 My Javascript coding skills are not that great. I can of course try to do the G7 code generation for myself.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217628338

[emartinez167]

I see you have posted it on MarlinDev. Please be aware we are closing that branch (too much melodrama to be told here ) so please post it on the main branch. Hopefully we can keep it alive once we release a stable 1.1 version. On Sat, 7 May 2016 at 19:37, Peter van der Walt notifications@github.com wrote:

Closed #44 https://github.com/openhardwarecoza/LaserWeb2/issues/44.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#event-653419099

[mkeyno]

hi @HakanBastedt , if what Peter says is true , why you haven't try on smoothie? maybe it is more easy to add THC feature on smoothie when timing source not held in plannar block . @openhardwarecoza is there smoothie shield on Due?

[Gustavvr]

Oh well, Throwing out myTurnkey Ramps board. Smoothie ordered.

[ghost]

You guys are confusing this tread now. Thc? Plasma... Thats got nothing to do with raster... We definitely arent going to be rastering with plasma.

So, to iterate.

8 bit is dead.

I welcome maintainers who want to add specific features.

I welcome me adding and maintaining features that are cross platform to support older firmwares.

I welcome standardised approaches above all else (so if you really want g7, leave this thread and go fight with smoothie and grbl and lasaur until they all support it, then i'll make it my baby)

Thc/plasma : we are working on the thc support in smoothie but this thread is not the place to discuss this. Dont crosspost! Last warning before i start banning (; @mkeyno we had this talk before. Dont tag me into irrelevant posts on other repos, and when you want to discuss things here you are welcome but open a detailed seperate thread

On 7 May 2016 19:25, "mehrdad" notifications@github.com wrote:

hi @HakanBastedt https://github.com/HakanBastedt , if what Peter says is true , why you haven't try on smoothie? maybe it is more easy to add THC feature on smoothie when timing source not held in plannar block @openhardwarecoza https://github.com/openhardwarecoza can made smoothie shield on Due?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/openhardwarecoza/LaserWeb2/issues/44#issuecomment-217653407