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 :)

[terjeio]

Pico 2 support is coming soon.

[terjeio]

I have now updated the driver for SDK 2.0.0/RP2350 and committed the changes. The Web Builder is not yet updated, will do so a bit later.
Note that I have not tested the code on a Pico 2 yet, it seems to run fine on a Pimironi PGA board so I guess it will too on a Pico 2.

FYI I build with VSCode on a Windows machine, switching between boards seems to be a hit and miss sometimes...

[distebia]

A proposito, il driver iMRX1062 (Teensy 4.x) è in una classe a sé stante quando si tratta di velocità di incisione, è/ha una MCU da 600 MHz con una FPU. Sono riuscito a raggiungere velocità di avanzamento > 50000 mm/min e trasferimenti di ~400 Kbyte/s tramite USB con esso.

50000mm/min with teensy 4.1 refers to a raster processing speed? or are we talking about photos? what should be the optimal setup (hardware and firmware) to be able to reach the highest speed (without slowdowns) in photo engraving?

[terjeio]

Increase the planner buffer size by setting $398, the iMXRT1062 can handle up to 1000. Max speed and acceleration settings $11x and $12x must also be tuned to match what the machine is capable of.
I am not sure if running the gcode from a SD card or via ethernet will also affect the max speed, you can get a feeling of what the absolute limit is by running a test file in check mode and time that.

And do not forget to enable character-counting streaming mode (Agressive buffering in ioSender) in the sender. This can have a major inpact on how fast data is transferred to the controller.

[distebia]

I played with various settings like speed up to 30000 and acceleration up to 5000, $398=1000 but for photo engraving I could not go beyond 15000 and, in any case, I saw jerky movements for each single line, it was not a smooth linear movement from right to left and vice versa...teensy 4.1 and tb6600 at 36v, nema 17...I do not understand what to change to increase the speed

[terjeio]

Perhaps step pulse length?
Steps/mm, pulse length, pulse delay and feedrate has to be configured correctly, the default 10 microsecond step pulse limits the max. step rate to about 80 KHz - depending on the driver beeing able to handle the resulting pulse train. Reducing pulse length (plus any delay) to the minimum required by the drivers will set the limit for max feed rate for any given steps/mm setting. So what is your steps/mm setting?

BTW are your TB6600 drivers really TB6600s?

[distebia]

about the tb6600 I also have big doubts but in the end I use 16 microsteps and 36v power supply. The steps/mm are 80 for X and Y, the pulse length is 3 (the tb6600 declare 2.3 min pulse), speed 40000 on X and 20000 on Y, accelerations 2000 on X and 200 on Y (due to the appearance of oscillations on greater accelerations) and $398=100, I also tried up to 1000.
setting.txt