Raster Engraving

[FabCreator]

Hi All,

Its been a while since we have discussed raster engraving. Currently using smoothieware we can raster engrave around 40mm/s without jittering. This speed is far too slow to make nice raster engraves with a CO2 Laser let along the time it takes to complete a small engrave.

Now I am not a coder so all of this is above my head. But hey, im going to through out an idea of how i kinda imagine it could work.

From what i understood the issue of rastering at speed is to do with with computing power and the nature of rastering with standard Gcode, the constant planning and calculating acceleration etc is too much processing to do at higher speeds and thus jittering occurs.

Therefore what if we break it in two components?

The machine is instructed to move from A-B with a dedicated area/distance to accelerate and decelerate.

Over the engrave area the head is now moving at a constant speed. we set the spot size say 0.1mm. 10 pluses per mm. Now we transmit the PWM level per pulse at a rate set by the mm/s the laser is moving at.

Raster module raster alpha acceleration 5000 #mm/s2 acceleration used when rastering raster speed 500 #Feedrate used when rastering acceleration zone 50 #mm distance used to get up to speed before rastering PPM 10 #How many pules/dots the laser can make per mm.

Does this make sense in principle?

Bonne

[cprezzi]

Your theorie is correct, that's how professional machines work, but the firmwares we use do not support such mode.

[tbfleming]

This is one of the major ideas that was involved in the big blowup in #99. Some points from that thread: GRBL can handle much higher pixel rates than the others using just gcode; from its perspective a protocol change is unnecessary. There seems to be a disagreement about where the true bottleneck is in Smoothie; it may help or it may not depending on who's right. Regardless, no one has stepped forward to complete the work that already started in smoothieware and we're reluctant to support it on our end because it will end up being Smoothie only. GRBL doesn't need it. TinyG, if it goes down that path will use an entirely different data format based on json.

[FabCreator]

Do we know how fast GRBL and Tiny G can go currently rough mm/s?

Reading through the last thread again i would say the issue comes from the acceleration generation

We do a lot more processing than GRBL does so I am not surprised that grbl may be faster in this respect. Since we added the new motion control that does acceleration per tick the calcs are more intensive for every gcode received as we need to fully pre calculate the step timing data so we can get the 100,000 steps/sec max rate.

If i think back to our first laser cutter prototypes using laserweb original and laserweb2 we were rastering faster than today. this was also before the new motion control system.

Just been reading into tiny G it appears they are doing somthing similar in regards to motion control?

If Tiny G currently rasters at a similar speed as smoothie then the problem lies with the fact we are essentially sending vector paths of 0.1mm in length and its simply too much for the controller to handle.

Ill try and flash and old version of smoothie ware and see if its faster than the current version.

[tbfleming]

Here are the two major speed factors:

• stepper interrupts/s
• blocks/s

The higher you go on one, the lower you have to go on the other or you'll get stuttering. mm/s and pixel resolution are indirect measures of firmware performance, which is unfortunate since those are what users really care about.

grbl-328: stepper interrupts/s is variable; there are either 2 or 3 interrupts (1 long, others short) for each step of the fastest-spinning motor. The 2 or 3 factor depends on configuration.

grbl-lpc: stepper interrupts/s is variable; there's 1 interrupt for each step of the fastest-spinning motor. grbl-lpc's max step rate is 200 kHz.

smoothie: I don't know if the stepper interrupt rate is fixed (like LinuxCNC) or variable (like grbl). smoothie's max step rate is 100 kHz.

Tiny G: last I heard they were still working on laser support. I don't know if they have it yet.

For laser rastering using plain gcode over USB, grbl-lpc currently holds the record at 79,000 steps/s, 1666 blocks/s: https://plus.google.com/101442607030198502072/posts/G9q5ois38RF

[ghost]

@FabCreator can you do a side by side test for us, same settings, but use firmware.bin latest, vs an older build from when it felt faster (everything else the same)

Older builds on https://github.com/Smoothieware/Smoothieware/commits/edge/FirmwareBin/firmware.bin

I am bettting we can zoom in on an exact build where it was fast before...

On Apr 4, 2017 6:03 PM, "Todd Fleming" notifications@github.com wrote:

Here are the two major speed factors:

• stepper interrupts/s
• blocks/s

The higher you go on one, the lower you have to go on the other or you'll get stuttering. mm/s and pixel resolution are indirect measures of firmware performance, which is unfortunate since those are what users really care about.

grbl-328: stepper interrupts/s is variable; there are either 2 or 3 interrupts (1 long, others short) for each step of the fastest-spinning motor. The 2 or 3 factor depends on configuration.

grbl-lpc: stepper interrupts/s is variable; there's 1 interrupt for each step of the fastest-spinning motor. grbl-lpc's max step rate is 200 kHz.

smoothie: I don't know if the stepper interrupt rate is fixed (like LinuxCNC) or variable (like grbl). smoothie's max step rate is 100 kHz.

Tiny G: last I heard they were still working on laser support. I don't know if they have it yet.

For laser rastering using plain gcode over USB, grbl-lpc currently holds the record at 79,000 steps/s, 1666 blocks/s: https://plus.google.com/ 101442607030198502072/posts/G9q5ois38RF

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/244#issuecomment-291547807, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-juBvGfaOrAyEr_pY4w7S7xllSXks5rsmnAgaJpZM4MysyW .

[arthurwolf]

There has been a lot of research and debugging on this subject by the Smoothie project, in particular in the following issue : https://github.com/Smoothieware/Smoothieware/issues/1096 I really strongly recommend carefully reading this thread for anyone interested in understanding issues related to engraving speeds. If something isn't clear don't hesitate to contact me or ask in the issue.

The experimentation gave very strong evidence that this is a problem with drivers and methods of sending data :

• For drivers, testing showed dramatical differences in speeds between the different OSes, because they have different driver implementations
• For the method used to send the Gcode, testing showed that different methods attain dramatically different speeds

This would also explain differences between boards/firmwares since they don't use the same drivers ( technically : don't cause the host OS to use the same drivers )

Because of these results, in light of previously obtained data, we now estimate that this is the primary cause of slowness when engraving. Other problems such as acceleration, step generation, resolution, compression, as discussed in other issues, have been shown to be much less impactful in comparison, which is demonstrated by the fact that using the right driver+sending method combo allows reaching speeds adequate for engraving ( if the problem was elsewhere, this wouldn't be the result we would find ).

On Tue, Apr 4, 2017 at 7:23 PM, Peter van der Walt <notifications@github.com

wrote:

@FabCreator can you do a side by side test for us, same settings, but use firmware.bin latest, vs an older build from when it felt faster (everything else the same)

Older builds on https://github.com/Smoothieware/Smoothieware/commits/edge/FirmwareBin/ firmware.bin

I am bettting we can zoom in on an exact build where it was fast before...

On Apr 4, 2017 6:03 PM, "Todd Fleming" notifications@github.com wrote:

Here are the two major speed factors:

• stepper interrupts/s
• blocks/s

The higher you go on one, the lower you have to go on the other or you'll get stuttering. mm/s and pixel resolution are indirect measures of firmware performance, which is unfortunate since those are what users really care about.

grbl-328: stepper interrupts/s is variable; there are either 2 or 3 interrupts (1 long, others short) for each step of the fastest-spinning motor. The 2 or 3 factor depends on configuration.

grbl-lpc: stepper interrupts/s is variable; there's 1 interrupt for each step of the fastest-spinning motor. grbl-lpc's max step rate is 200 kHz.

smoothie: I don't know if the stepper interrupt rate is fixed (like LinuxCNC) or variable (like grbl). smoothie's max step rate is 100 kHz.

Tiny G: last I heard they were still working on laser support. I don't know if they have it yet.

For laser rastering using plain gcode over USB, grbl-lpc currently holds the record at 79,000 steps/s, 1666 blocks/s: https://plus.google.com/ 101442607030198502072/posts/G9q5ois38RF

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/LaserWeb/LaserWeb4/issues/244#issuecomment-291547807 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-juBvGfaOrAyEr_ pY4w7S7xllSXks5rsmnAgaJpZM4MysyW .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/244#issuecomment-291571546, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFZqLc6M6NB_Kz_mYO6PP-Tmk745Aks5rsnyXgaJpZM4MysyW .

-- Courage et bonne humeur.

[FabCreator]

https://www.youtube.com/watch?v=TopGs-yLI_E almost a year ago! time flies when your building laser cutter and having fun ;)

But look at the start and 14 seconds both those rasters are alot faster than what we can do now. So that would have been the firmware around May/june driving with a pi 3 on laserweb 2 or over windows and a USB not sure cant remember now. I will make some films tomorrow with the same g code and different firmwares, ill also load up a pi, will LW4 work on a pi? If its drivers on the OS then we should see an improvement? @arthurwolf do what version the motion controller change?

[arthurwolf]

@FabCreator The motion control has changed over several months with one big refactor initially but many other changes after that as it was further worked on. There has been a lot of speculation on these issues, and they are very confused by the fact that it seems people tend to at first think they have found the culprit, and hold on to that, and then have problems seeing some new evidence that comes after that.

What we have done in the Smoothie issue I linked to was to take a very scientific, evidence-based approach to try to carefully test only one thing at a time ( very important ) to slowly eliminate possible causes until we got to the truth.

It's imaginable that in your case, you never had problems with drivers, and so the differences in speeds you have seen would be linked to some other factor. However seeing how strong the evidence we found for driver/host issues is, I really think it should be the first suspect in your search. If you can eliminate it as a cause, that's great, you then know more, and can work on the next suspect.

To determine if you have a host driver related issue, please perform the following experiment as strictly as you can : 

• Do a cut on a specific OS
• Then do a cut using the exact same machine, computer, gcode, host program, firmware etc but using another OS ( only change the OS, nothing else changes, allowing you to be sure this is the culprit if you see a difference ) If you aren't able to run two OSes on the same computer, you can try using different computers, but then your experiment isn't as good and you haven't really pinpointed the problem, no matter the result.

To determine if your problem is a problem with the host program ( the Gcode sender ), please perform the following experience :

• Do a cut using your usual host program
• Then do a cut using the exact same machine, computer, gcode, OS, etc but using Jim's script to send the Gcode. Jim's script and it's instructions can be found at https://github.com/Smoothieware/Smoothieware/issues/1096#issuecomment-274310386 Again, please try to make the experiment as strict as possible, only changing the gcode sender, and nothing else.

[tbfleming]

For driver comparison: like Smoothie, grbl-lpc presents itself as a USB CDC device, but unlike Smoothie it's not a USB MSD.

[cprezzi]

@arthurwolf I have another test for you:

• Do a cut using your usual host program with smoothieware on the board
• Then do a cut using the exact same machine, computer, gcode, OS, etc but with grbl-lpc on the board

This will show the evidence if smoothieware is performing better or inferior than grbl-lpc.

[arthurwolf]

@cprezzi There's not even a need to do such a test, it's obvious grbl being much more efficient ( it doesn't have all the fancy features and modularity of Smoothie to compute ), it'll be faster than Smoothie. That's not the point though.

Smoothie has been known, with the right combinations of driver and gcode sender, to be fast enough to do raster engraving correctly. The fact that grbl-lpc can do it even faster isn't the subject here.

The subject is that for some users Smoothie doesn't work adequately, while for other users it does, and that difference has been pinpointed to a difference in drivers and gcode sending methods.

This isn't a conversation about the differences between "does great engraving" and "does even better engraving", it's about users for which engraving doesn't work well enough to be practical, and our research showed clearly what was the cause of that.

[cprezzi]

@arthurwolf The speed limitation that @FabCreator is talking about is not depending on his machine, we all can reproduce that limitation.

You claimed that the bottleneck is the OS driver and host software, but if grbl-lpc is faster with the same pc, os, driver and software, then the bottleneck must be smoothieware.

I don't say this is fact, but I will test that.

[jorgerobles]

@cprezzi maybe drivers @arthurwolf refer are not host drivers, but LPC implementation of composite USB.

[arthurwolf]

@cprezzi It was depending on the OS for @DarklyLabs, and that was demonstated through carefull experimentation. Also, you say it's not depending on the machine/OS/driver for @FabCreator but I don't see where that has been experimentally demonstrated.

About your claim that Smoothie is the bottleneck because it's faster with grbl-lpc, you are falling in the same trap that keeps derailing these conversations : ignoring the fact that multiple factors can contribute to a problem, and trying to find a single thing to blame. Let me say again : Yes, grlb-lpc is going to be faster than Smoothie. This doesn't mean you found the problem, as we said before Smoothie has been shown many times to be fast enough using the right driver/sending system. Not as fast as grbl-lpc, but that's not the complaint here. This conversation isn't about who's faster, it's about users not even being able to engrave at any practical speed.

And so far the only demonstrable cause of this, has been shown ( with a lot of careful experimentation/deduction ) to be related to gcode sending methods and drivers.

You need to put yourself in the shoes of @FabCreator, they don't care who can beat the world record for engraving speed, they care that right now they can't engrave at all. This has been pinpointed to the issues I keep mentionning, it doesn't matter who is faster once that issue isn't the concern.

[FabCreator]

Sadly I don't have a dual boot device or another OS other than pi,

@arthurwolf if its a driver issue then it should be fixable and then we have speeds similar to GRBL? I see in the smoothieware#1096 the final speed was only 80-100mm/s?

80-100mm/s is far from a "does great engraving". perhaps for a laser diode machine but for a CO2 laser we are aiming for 500-1000mm/s

If the best case scenario for raster engraving currently is max 100mm/s then fixing the driver is not really a solution and we should focus on a completely different solution for high speed rastering.

[arthurwolf]

@FabCreator grbl-lpc is likely going to be faster once all other problems are corrected, it has less overhead. But there is an identified bottleneck related to drivers and gcode sending methods, and that needs to be fixed whatever happens, even if we decide to go with a more compact data sending method it'll still be a problem.

[FabCreator]

I appreciate the differences in the way GRBL and smoothie work, from config files to acceleration profiles modulation etc its great. Why we have the smoothie board in the machine :)

But while we are not looking to over take trotec engraving speed, being able to engrave as fast as a DSP controller is essential.

The driver maybe an issue and needs to be fixed either way, but even if it was working optimally rastering is still far off a reasonable speed.

[arthurwolf]

@FabCreator We agree on that, even if we solve the drive/gcode sending bottleneck ( which I think should happen first ), we still want to improve speeds. It's actually not that unreasonable to expect Trotec-like speeds, and there are ways to get there, but it requires using something else than Gcode for transfer, and using something else that the current Gcode interpreters for step generation. We have a pretty good idea of what needs to happen to get that done, but no volunteer ready to do the work at this point.

[cprezzi]

@arthurwolf I did not say that performance on other os isn't faster, but do you realy want to say your customer to change the os to get better speeds? That's not an option.

And please read carefully. I did not claim that grbl-lpc is faster, I just said if this is the case then..

[arthurwolf]

@cprezzi I don't want to tell anyone to change OSes, but to move forward, if OS drivers are part of the problem, we need to acknowledge that ( for example in documentation so users are aware of the issue. Changing OSes is an option for some users and they won't do it if they don't know it can help ) and consider whatever we can do to work around it, if anything.

Additionally, it's not just OS drivers, experimentation has shown it's also related to the way the Gcode is sent, for example, on the exact same setup, @DarklyLabs saw dramatical changes in engraving speeds when comparing laserweb's gcode sender to the script Jim has written. This is a very important data point and it mustn't be ignored, it suggests that user experience could be significantly improved if laserweb started using this new method to send gcode. This isn't only something that experimentation has shown, it's also something that is completely understood and explained process-wise. As in : we know there is room for improvement, and we know how to do the improvement.

About you claiming grbl-lpc is faster, I don't care if you did or not : it's irrelevant, I say myself that it's likely it would be ( assuming all other factors are removed ), so there is nothing to disagree on here.

[cprezzi]

@arthurwolf You realy make me angry. Jim's script is NO intelligent new method, it's just a simple "pushing the whole file to the driver and forget the rest"! There is no "realtime" feedback or commands, nothing! That's just taking everything out of the equation that could slow down the process, which is far away from your "correct testing method".

You just try to put the blame on everything else than you! That's very unprofessional...

[arthurwolf]

On Wed, Apr 5, 2017 at 2:58 PM, Claudio Prezzi notifications@github.com wrote:

@arthurwolf https://github.com/arthurwolf You realy make me angry.

This keeps happening and I have no idea why, I'm only exposing facts and explaining what conclusions we have gotten though using experimentation. You guys keep getting upset for no good reason I can see, and it has now gotten so bad that friends of mine, contributors of the Smoothie project, have gotten banned and censored from laserweb communication channels. This really has to stop, there is no reason to get upset here, we all want the same thing : better machines ...

Jim's script is NO intelligent new method, it's just a simple "pushing the whole file to the driver and forget the rest"! There is no "realtime" feedback or commands, nothing! That's just taking everything out of the equation that could slow down the process,

So ?

which is far away from your "correct testing method".

You'll have to explain to me why ...

You just try to put the blame on everything else than you! That's very unprofessional...

That's what the data shows, I have no idea why you think that is unprofessional, if you disagree, explain why instead of making accusations ...

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

-- Courage et bonne humeur.

[cprezzi]

If you don't want us to get upset, stop talking to us like a teacher! I have often explained why your data is not relevant for a real solution, but you don't seem to understand. So I don't care anymore....

[jorgerobles]

Sorry to intervene here. Calm down. @arthurwolf, @cprezzi

About being upset, and so on. I think there's a difference if you have put your own bacon making the tests or not.

About friends and so, as I'm the new guy here, have no knowledge of that history. But that mentions are closer to High School ones than otherwise.

This has a clear solution. Prove it

And with proving it, I mean @arthurwolf to please send us that so thoroughly data and documentation of your tests. Then, as far as we can will replicate and compare. And thats all.

By example You have to determine if the glitches ocurrs by buffer underrun (LW cannot send fast enough) or data overflow (Smoothieware cannot swallow fast enough)

Who is this Jim, sorry if I don't know him. Please share his code. And so, please test with third party software (like UGS) so you can be fair enough with full blown software instead a bitbang script.

If not in the mood of sharing o doing this tests, this discussion will be over.

[ghost]

I'm closing this before we all get in a fist fight. We'll do some more testing to prove our views. @arthurwolf can I ask that you refrain from joining the conversations around this in OUR issues

We cannot productively continue actual work when it keeps escalating into an emotional thing. I suspect if you refrain from following/commenting on this discussion, maybe this team, can argue with ourselves, then bring Valid data over to Smoothieware's issues. Even if during the process someone hates on Smoothie, let it go. Dont mingle. Its part of the process of arriving where we need to be.

Dont forget months ago we did the same to Grbl before it got Laser mode

And most importantly: Jim's script is not a host application. Dumping everything into the OS buffer looses all control over the stream!

[ghost]

@LaserWeb/devteam - close any new issues re Smoothie/Raster-performance right away and lock. We can't deal with these right now