Laser raster speed

[theomajigga]

(Xpost from Phil's teensy project)

Great work on this. I know very little when it comes to this type of ports, but my realization of how cheap M4 boards have become, are leading me down the path to upgrade me co2 laser to a proper (freshly written) 32-bit port of GRBL.

First: Sorry for an issue report, I know this isn't the proper route.

Second: I am currently running GRBL-LPC for my laser, I get stuttering on high dpi, fast movements (254dpi/300mm/s). I am hoping to get some increased speeds out of my machine, as it is capable of 500mm/s (with out imploding :) )

Per Oz of the project Lightburn:

An image at 254 dpi means 0.1mm dots, or 10 dots per mm. If you run 100 mm/sec, that’s 1000 dots per second, and each dot takes a gcode instruction to produce.

Stock Smoothieware hits 800 instructions/second, or 80mm/sec with 254dpi. 8-bit GRBL is about 400, or 40mm/sec with 254 dpi

If you’re running GRBL-LPC or the new cluster Smoothieware (available on C3D’s forum) you can hit about 250mm/sec at 254 dpi.

After doing extensive research, it led me to your project, and some of the work you did with the gnea fork.

I guess, my question is, would upgrading to the teensy 4.x and the board you have produced on tindie, get me the speeds I am looking for?

Thank you!

[terjeio]

I guess, my question is, would upgrading to the teensy 4.x and the board you have produced on tindie, get me the speeds I am looking for?

Possibly, but not without tuning. What is needed is at least a substantially larger planner buffer as grbl always plan to a full stop. Sender/controller interaction may also play into this - as senders waiting for a ok before sending the next line is not likely to keep the input buffer from emptying and thus the controller waiting.

[theomajigga]

I believe that lightburn does buffering, and not sync, so that shouldn't be an issue?

[terjeio]

Check this blog post - and others by the same author.

Tuning is trivial, no coding required - only one or a few #defines to change.

Do you have a test file that is representative of what you want to achieve? If so can you post it here?

[infamous-panda]

Same boat as the OP. I have been able to achieve 3-5x the speed of lpc with grbl-HAL on teensy 4.1 by increasing the buffer to 1024. There is some other stuff going on that phil and I are still trying to sort out but I can confirm it works with a physical test

[theomajigga]

There is some other stuff going on

What is this other stuff, just out of curiosity.

[infamous-panda]

There is some other stuff going on

What is this other stuff, just out of curiosity.

Phil build with the increased buffer does not seem to run any faster than LPC. I built grbl-HAL from the files in the release not master and it runs much faster. I do not know what the difference that matter are.

[terjeio]

@infamous-panda Can you give the test branch a try? And if possible upload your test g-code for me to try with?

[infamous-panda]

@infamous-panda Can you give the test branch a try? And if possible upload your test g-code for me to try with?

Can you point me specifically to which files are the test branch? I am not very familiar with compiling firmware so it's a bit of struggle to get it all prepared just right. I compiled my version using the files in Build 20200503 release with Arduino IDE, and when trying to compile the more current "master" files so that I could enable ethernet support I got stuck and asked Phil to do it for me. The firmware he sent ran quite a bit slower as noted even though he changed the planner to 1024. There must be other differences with some other settings

Test file below.

https://drive.google.com/file/d/1D5yneFmeh0anS1S_EWtQJQ13Kyi44FTT/view?usp=sharing

[terjeio]

@infamous-panda What max feed rates did you achieve with the master and Phil's version?

When I am testing with the test branch feed rate tops out around 30000mm/min (500mm/sec) with S commands removed, around 25000mm/min with S commands present.

S commands are not needed in laser mode (unless gray scale engraving) as G1/G0 switches the laser on/off automatically when M4 is used.

Edit: Streaming via USB does not manage to keep the planner buffer filled, via Ethernet (Telnet connection) I get around 65000mm/min and the planner buffer is kept full (1000mm/sec^2 accel). This when I switch to the Console or 3D View tab in ioSender, when in the Program tab feed rate drops significantly to around 40000mm/min. This means that keeping the program listing up to date is a limiting factor as well.

[infamous-panda]

I get around 50,000 mm/m. Phil's around 17,000 mm/m

Sample code is worse case. We do sometimes vary the laser power between dots.

Are you using a teensy 4.1?

On Tue, Jan 5, 2021, 3:00 AM Terje Io notifications@github.com wrote:

@infamous-panda https://github.com/infamous-panda What max feed rates did you achieve with the master and Phil's version?

When I am testing with the test branch feed rate tops out around 30000mm/min (500mm/sec) with S commands removed, around 25000mm/min with S commands present.

S commands are not needed in laser mode (unless gray scale engraving) as G1/G0 switches the laser on/off automatically when M4 is used.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/142#issuecomment-754472974, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7D7UDGFYGOV5VSJLXKJOLSYLBLVANCNFSM4U6GLAFA .

[terjeio]

Are you using a teensy 4.1?

Yes.

We do sometimes vary the laser power between dots.

Is it possible to only add S commands when power is changing?

Have you seen the edit I made to the previous comment?

[terjeio]

A bit more testing. Other senders I have tested performs badly. The best I have seen so far achieves just over 17000mm/min (LaserGrbl). So feeding the controller with data rapidly enough is part of the problem.

I increased the planner buffer to 1400 and tried with ioSender again (with the Console tab open) and got this:

Time to completion was 0:58.

If I run the program with the Program or 3D View tab open the sender goes crazy as it cannot keep the UI up to date. It eventually hangs.

So at these insane feedrates the sender is the main limiting factor...

[infamous-panda]

terjeio,

Would you be able to send me a copy of your firmware files with Ethernet enabled? I would love to get some testing done on it since the one Phil provided capped out at about 17000.

I have two PCs I am testing with. The one I would like to attach to the laser is an older surface with an Atom processor. At 50,000 mm/m it is at 100% cpu usage per the task manager and it seems to stutter a couple times through this code. My workstation handles it easily. I too find there is a difference depending on which window view is open in gcode sender.

A stable 50,0000 using ethernet would be ideal for me since this is about the limit of my laser being able to turn off and on with usable power. However I am sure there are other laser's out there which can take advantage of this. It would be nice to have a gcode compatible system that can provide as much speed as DSP machines.

[terjeio]

@infamous-panda I have uploaded a hex file and the edge version of ioSender here.

The sender has new settings that may be useful. If you enable Filter "ok" response then you can enable Verbose mode in the console without the sender kneeling over. I do this to check free space in the planner buffer - the first value in the Bf: element in the real-time report.

[infamous-panda]

@infamous-panda I have uploaded a hex file and the edge version of ioSender here.

Thank you! I will give it a try this morning.

Quick question. For the Settings:GRBL, I am unsure how the Save Reload and Backup buttons work. I assume this is to save parameters likes steps/deg on the controller which would be great, however there is no prompt or anything when those buttons are pressed.

[terjeio]

I am unsure how the Save Reload and Backup buttons work

• Save - for writing settings to the controller.
• Reload - for reloading settings from the controller.
• Backup - saves settings to the file settings.txt in the sender folder. This can be used for a restore later. I should add a Restore button for that...

[infamous-panda]

• I should add a Restore button for that...

Ahh yes that would be great. I understood "Reload" was for that function but it never work as expected. Thanks

[infamous-panda]

@infamous-panda I have uploaded a hex file and the edge version of ioSender here.

I am unable to connect Gcode Sender to the board using this firmware through USB. Is it ethernet only? If so what IP settings would I use?

[terjeio]

I am unable to connect Gcode Sender to the board using this firmware through USB.

I see I have compiled with FRAM enabled. If not soldered on your board then this could cause it to hang. Too many details to keep track of sometimes...

A new hex file without FRAM/EEPROM support is just uploaded.

BTW I have changed the test branch so there is no longer a need to copy files around before building. Just import the project from the driver/IMXRT1062 folder.

Is it ethernet only? If so what IP settings would I use?

No. If the board is up and running it is likely it gets it IP-address via DHCP. This can then be found using $I from a terminal or maybe also when checking your router for connected devices. The default hostname is "GRBL".

[infamous-panda]

I increased the planner buffer to 1400

Is this the reasonable maximum?

[terjeio]

Is this the reasonable maximum?

Hard to say - I have tried increasing it more only for compilation to fail due to lack of memory. Reducing input buffer sizes may free up memory for adding more if needed. Each entry needs about 40 bytes.

And I am not sure if adding too much may slow down the troughput instead of increasing it.

[Cncninja]

Any updates I still can't even get it to compile, I'm stuck with the precompiled generic option. when I do my own compile it errors asking for ioport.h ??

[phil-barrett]

I just placed 3, 4 and 5 axis precompiled binaries with a 1024 entry planning buffer in the github repository for the board.

[terjeio]

it errors asking for ioport.h ??

Strange, it should not without a configuration change and custom code added based on the ioports template. What is the build version from grbl/grbl.h? It is found in the #define GRBL_VERSION_BUILD line.

[Cncninja]

It was the one in the Grblhal master folder, Phil uploaded a precompiled version and that worked like a charm

[infamous-panda]

Quick Question. Is there a limit to the decimal precision on the XYXA positions that GRBL / GRBL-HAL will recognize. My custom CAM software generates really small angle helixes (continuous laser engraving on rotary) that we output 4 decimal places typically. I tested a run where I rounded this to 2 decimal places to see if we can improve speed by reducing the amount of code streamed, but it ended up making the machine stutter. I think this is because when the positions in the helix were rounded the motion was no longer smooth. Makes we wonder if we could add 5 or 6 decimal places if it would be better?

[terjeio]

Internal representation is single precision floating point and input values are converted to that without any explicit rounding. The default reporting format is 3 decimal places (1 micrometer resolution) for metric and 4 (1 thou resolution) for inches mode. For most machines (all running grbl?) this is likely better than the mechanical precision available and is a waste of bandwidth to use more?