Non-smooth motion while engraving

[pimsierhuis]

Hi there,

I'm trying to convert our laser cutter to grblhal with a pi pico in the picocnc board. I have it running, but still seem to have a problem. The problem is, that when I send a job containing very many small G1-codes (engraving as generated by Visicut), the movement isn't steady. Even if the speed is the same for all G1's per "line" (y-position), you can see it decelerating and accelerating (in the middle of the line, where there are more "dots" (G1's)), so seemingly it is a result of the many g-codes. Also, the machine sometimes "clunks" during these moves. The problem doesn't seem to be the speed, as we run it at speeds that should be possible looking at other lasercutters.

I use firmware as generated by the web builder (just tried new version)

Could this be buffer related or something? Any ideas?

Regards,

Pim

[terjeio]

Which sender?
Does it use "agressive buffering" (character counting mode)?
What are your settings ($$ output)?

[pimsierhuis]

The primary use case is uploading via HTTP and then streaming from SD with $F=filename. To test if there was a problem with SD, I tried Universl Gcode Sender over USB. Both with exactly the same results.

My settings are:

$0=10.0
$1=25
$2=0
$3=0
$4=7
$5=0
$9=1
$10=511
$11=0.010
$12=0.002
$13=0
$14=70
$15=0
$16=4
$17=0
$18=0
$20=1
$21=0
$22=5
$23=0
$24=1500.0
$25=3000.0
$26=250
$27=10.000
$28=0.100
$29=0.0
$30=100.000
$31=0.000
$32=1
$33=5000.0
$34=0.0
$35=5.0
$36=80.0
$37=0
$39=1
$40=1
$41=0
$42=2
$43=1
$44=3
$45=0
$46=0
$50=100.0
$51=600.0
$52=3000.0
$53=0.250
$54=10.0
$55=10.0
$56=5.0
$57=100.0
$58=-5.0
$59=500.0
$60=0
$61=0
$62=0
$63=3
$64=0
$70=7
$100=89.69800
$101=89.00400
$102=6462.76611
$110=30000.000
$111=30000.000
$112=250.000
$120=2000.000
$121=2000.000
$122=10.000
$130=880.000
$131=580.000
$132=200.000
$300=grblHAL
$301=1
$302=192.168.5.1
$303=192.168.5.1
$304=255.255.255.0
$305=23
$306=80
$307=81
$341=0
$342=30.0
$343=25.0
$344=200.0
$345=200.0
$346=1
$370=0
$372=0
$384=1
$392=4.0
$393=1.0
$396=30
$397=0
$398=100
$481=0
$484=1
$486=0
$490=
$491=
$492=
$493=$F=/visicut.gcode
$535=00:08:dc:00:00:10
$650=0

[terjeio]

I see that you have a rather high max feedrate, which feedrate is set in the file you are trying to run?
The Pi Pico does not have a FPU and may struggle with high feedrates, even more so with a largish planner buffer. The planner buffer size can be changed with $398, experiment with changing this and the feedrate to determine what is the max rate achievable.

FYI the new Pi Pico 2 is very likely able to handle higher feedrates since it has a FPU, speeding up floating point calculations significantly. According to the specs it can replace the Pi Pico since it pin compatible. I will add support for it when I get may hands on one.

[pimsierhuis]

The feedrate I try is even higher (Visicut was still configured for 48000), I assumed grblhal will cut if off to 30000. The file has +/- 500 G1's per line of 15cm. That means 1600 gcode-commands per second. Does that sound close to or over the limit?

I already worried about maybe getting to the limits of the pico. Thanks for the hint of the $398, will experiment with that tuesday. By the way, where could I have found this setting? It isn't in the wiki's settings page.

Support for the Pico 2 would be great. I just ordered some to experiment with. I can send you one if you want?

[terjeio]

assumed grblhal will cut if off to 30000.

It will.

That means 1600 gcode-commands per second. Does that sound close to or over the limit?

I'll have to run tests to find out. For that I need a file generated by your software.
Note that some softwares generates gcode with lots of superfluous commands, increasing the overhead.
Also the mode of transfer to the controller affects the max. feed rate, which sender are you using?

By the way, where could I have found this setting? It isn't in the wiki's settings page.

I (or someone else) need to revise that page, and write a lot more supporting documentation...

Support for the Pico 2 would be great. I just ordered some to experiment with. I can send you one if you want?

Thanks, I would have ordered some myself already if it were not for soon going abroad for a while. Will do so when I arrive and they become available there.

BTW the iMRX1062 (Teensy 4.x) driver is in a class of its own when it come to engraving speed, it is/has a 600MHz MCU with a FPU. I have managed to achieve feedrates > 50000mm/min and transfer of ~400Kbytes/s over USB with it.

[pimsierhuis]

I tried tonight with 10000 mm/min, also with double and half the $398. Then the slowing down didn't occur, but it still "clunks" sometimes. This doesn't happen with simple, large, linear moves (so therefore I wouldn't expect it to be a hardware-problem).

The primary use case is uploading via HTTP and then streaming from SD with $F=filename. To test if there was a problem with SD, I tried Univeral Gcode Sender over USB. Both with exactly the same results.

I attached a sample file. I think it's quite clean, only containing G1's and G0's. By the way, I set the power to 0 in visicut, so therefore there aren't any lines with power. Normally the G1's alternate with 0 and high power.

reproduceren_engrave_probleem.gcode.txt

What should be done to compile for Pico 2? Maybe I can try myself :)

[pimsierhuis]

Sorry, I wasn't accurate in my previous comment. I did try Universal Gcode Sender and got the symptom of slowing down during "lines" of engraving. In my head, that had a 1 to 1 relation with the clunking. I just retried and it didn't! So the problem is with reading from SD.

[pimsierhuis]

And btw, I disconnected the ethernet cable and then the clunking seems even not to happen when streaming from SD.

[terjeio]

And btw, I disconnected the ethernet cable and then the clunking seems even not to happen when streaming from SD.

Are you using a dedicated ethernet port on your PC for the board or do you connect to a switch or router? If the latter it could be due to general network traffic generating a lot of interrupts?

[pimsierhuis]

It's connected to a switch, as we want to be able to upload jobs from visitors own laptops. So I came to the same hypothesis. Do you think the Pico 2 will help here too?

[terjeio]

Do you think the Pico 2 will help here too?

Maybe, has to be tested. Another option could be to move the SD card and ethernet code to the second core (both since the SPI bus is shared). I have no idea how much work that would be - I have not done any multi-core programming before.

The iMRXT1062 (Teensy 4.1) or STM32H7xx/STM32F7xx drivers are likely better options since they have on-chip ethernet controllers.

[pimsierhuis]

I'd still like to test with a pico 2. What should be done to compile for pico 2? Building in an other board is quite some work, so a pico 2 as drop-in replacement would be a nice option for us :)