M4, laser inline commands have poor performance. #977

If I run from the microSD,
“[MSG:WARN: Low memory: 12884 bytes]
[MSG:INFO: Channel auto report interval set to 50 ms]”

Shows up in the terminal, I suspect that is normal.

Changing the mapping back to 1000 per discord user suggestion.

First of all, let’s setup some procedures to make debugging possible. The “nogit” in the version message suggests that the source code was downloaded as a zip ( I wish github could be configured to turn off that feature). It is much better to fork the repository and make your own working branch. Every time that you report a result, make sure that any code changes are committed and pushed to the fork branch. Then the version number will reflect the source code via the commit hash, and you can point to your fork so we can see your actual code. If we can’t see your code, every hypothesis has to be sandwiched with “I wonder if …. but there is no quick way to find out”, which is inefficient to the point of being intolerable.

Also let’s keep this entirely on GitHub. Having to consult two different channels is similarly inefficient.

Okay, understood. Let me get a few orders out and then I can spend some more time and focus again this afternoon.

” It is much better to fork the repository and make your own working branch.”

I am not really understanding what it takes to make this happen. I am not understanding everything that needs to be modified in the workflow file. Other than the version number, does something else change. I am pretty fluent in compiling several types of firmware and making some edit but workflows are still a bit of a magical to me.

Is there another way I can confidently compile the devt branch to prove to both of us I am using the right one?

” Every time that you report a result, make sure that any code changes are committed and pushed to the fork branch.”
At this point I have made no changes, Bart has made all the UART changes.

The first step is to create a fork with the Fork button. That will make a copy of the git repository in your github account.

The next step depends on the tools that you use. Do you use the VsCode IDE? If so you can do the next step directly from VsCode.

Assuming VsCode, do File>New Window and then under Start, hit Clone Git Repository, then Clone from GitHub, then start typing v1engineering and choose v1engineering/FluidNC when it comes up.

I use vscode, I have forked this repo. I am just not understanding how to get the workflow file to use the devt branch and spit out all the files to my fork not try to use your and barts repos.

The workflow file is irrelevant. You need to select the Devt branch in the Git extension, then use the platformio upload button to build and upload to the esp32

Or better yet, “Create new branch from …” and choose origin/Devt as the starting point. Give it a new name for your work.

The workflows are for creating release bundles. You don’t need to do that at all.

Instead of just downloading, and compiling it? Okay that will have to wait for tomorrow I guess. I am not at that computer that is near the connected board.
I just downloaded and compiled then I tried pio direct to the board, fluidterm ctrl-u, then ctrl-r, and the update from esp3dui. If you think it will make a difference, I will do it that way. Learning something new is always good.

I am confident I did compile and flash the right branch, but I understand wanting to see the correct numbers for troubleshooting’s sake.

I am just concerned the new UART controls are causing some issues, since no one seems to be having issues with M4 other than me.

Sorry I just turned off AP STA. I will try again.

The machine was running smooth at about 70mm/s (as compared to grbl-hal hits 80 at the same settings on a different board). The freeze happened all the way down to 20mm/s it would just say busy after a a few mm worth of burn. It does seem like a memory thing but what do I really know. Testing again with AP/STA off from the lightburn panel.

Is WebUI running at the same time as lightburn? If so, is auto-reporting enabled? Auto-reporting at high refresh rates can use up a lot of I/O bandwidth. It is okay for milling but not for lasering.

Are you using lightburn over USB or TCP? TCP sucks compared to USB because of packet latency.

TCP has good bandwidth for large packets, but rather high latency. For small packets the bandwidth drops off severely. The GRBL protocol was heavily tuned toward the characteristics of serial ports – very small packet sizes due to limitations in AVR serial receive buffers, coupled with low and predictable latency for single characters.

USB.

So it looks like I can run about 35-38mm/s with smooth running no signs of stuttering at power changes with STA off. (same .19line interval 134dpi). Marlin hits 22 at best with 8 bit and 26mm/s with a 32 bit chip. That is great.
I can try turning AP back on with auto reporting off…just need to figure out how to enable it again.

What else might affect the speed? I have 8th microstepping, figured less pulses was better, what about”pwm_hz: 5000″ try dropping to 2000?

Just looking to see an ultimate max here before I set up a normal parameters for users.

38 mm/sec is 26 ms/mm or 5 ms/ .19 mm . 5 ms is 57 characters at 11500 baud (87 us/char). So, unless there is some inefficiency in the way that lightburn manages buffers, the UART bandwidth is probably not the limiting factors. You could test that by shortening the GCode lines. After one G1 line, the next line need not say G1, so

G1 X0.19S108.2
G1 X9.098S80
G1 X4.5S0
G1 Y0.189S0
G1 X-4.5S0
G1 X-9.098S80
G1 X-0.19S820
G1 X-0.189S192.8
G1 X-0.19S80
G1 X-0.19S830.5
G1 X-0.189S80

could be shortened to:

G1
X0.19S108.2
X9.098S80
X4.5S0
Y0.189S0
X-4.5S0
X-9.098S80
X-0.19S820
X-0.189S192.8
X-0.19S80
X-0.19S830.5
X-0.189S80

In hand-coded GCode, it is not unusual to first say

G1 F1000

to establish the mode and feedrate, then on following lines you just mention the x and y coordinates.

Another trick is to ensure that lines end with only linefeed, not CR-LF, thus saving one character per line.

Yet another trick is to set the maximum S value to a small integer like 9, using the speed map to associate that with the desired pwm values. Then instead of saying S80, S192.8, S830.5, etc, you can say S1, S2, S9

A final trick would be to cheat on the steps_per_mm so that instead of saying “X-.189”, you could say “X-1”. With all those tricks you could reduce the typical line length from 16 characters to 6 – e.g. “X-1S5”

But even without doing all the tricks, you can find out if line bandwidth is a limiting factor. Just do the easy tricks like omitting the “G1 ” and see if you can go a little faster.

Another thing to try is increasing planner_blocks http://wiki.fluidnc.com/en/config/top_level_config_items

Direct from the MicroSD in STA mode should be the fastest then? Skip the whole USB thing and no AP mode Memory bottleneck?

In principle, yes. Give it a try.

If I enable STA mode, still running off USB, It will eventually freeze. Depending on speed in can take 30 seconds or less. I don’t think I can test it from the Micro SD.

I am going to turn up the buffer size, 32, maybe 48. Not sure what else to try if that doesn’t help.

Doubling the planner got me above 100mm/s, not bad at 120mm/s, before stuttering with the wifi still off.

Well Mitch I have done a ton of learning today. Thanks for being so patient with me.

How about some great news….in AP mode I am still getting very little hesitation with M4 from the Micro SD. So from lightburn wired wifi off and AP mode direct from MicroSD is the same.

The only issues are M4 with wifi on while directly connected to lightburn (a common use as it has all the laser calibrations built in). Maybe add the command to temporarily turn it off to the wiki $WiFi/Mode=off? I might be totally wrong.

When I disconnected from the AP is hesitated for a long while then resumed. I am guessing STA mode fixes that? Last thing for me to test as I get a poor signal by my CNC.

Should I close this issue?

I guess I need to retest to see how much added planner/memory helps, but it definitely does with M4. If there is not a huge downside, I will leave the public config set to 32 for my users.