Add support for G7 raster engraving from Turnkeytyranny's marlin about deprecated-laserweb2 HOT 13 CLOSED

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" [email protected] 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
#44

from deprecated-laserweb2.

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 [email protected]
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" [email protected] 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
#44

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#44 (comment)

from deprecated-laserweb2.

TurnkeyTyranny's is still on the old v1. 0 codebase.
On 7 May 2016 07:10, "emartinez167" [email protected] 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 [email protected]
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" [email protected] 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
#44

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
<
#44 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#44 (comment)

from deprecated-laserweb2.

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

from deprecated-laserweb2.

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 [email protected]
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
#44 (comment)

from deprecated-laserweb2.

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)

from deprecated-laserweb2.

No worries!
On Sat, 7 May 2016 at 13:54, Peter van der Walt [email protected]
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
#44 (comment)

from deprecated-laserweb2.

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.

from deprecated-laserweb2.

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" [email protected] 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
#44 (comment)

from deprecated-laserweb2.

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 [email protected]
wrote:

Closed #44 #44.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#44 (comment)

from deprecated-laserweb2.

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?

from deprecated-laserweb2.

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

from deprecated-laserweb2.

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" [email protected] 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
#44 (comment)

from deprecated-laserweb2.