Raster Gcode

dc42

We run GRBL-LPC currently and this completes in approximately 4 minutes.

I can only conclude that either GRBL is not honouring acceleration and jerk (or junction deviation) limits, or you have them set very much higher in your GRBL configuration than in RRF.

The best case is not 21 minutes, that is merely an illustration of the reduction that I was able to achieve by increasing the limits somewhat. The best case time will be somewhat greater than the simulation time i.e. 1min 36 sec.

The problem is not with RRF, it is with the limits you have set.

PS - setting acceleration and jerk even higher, the simulated time comes down to 9 minutes. I could set them higher still.

dc42

@infamous_panda, ~~here's another reason why 4 minutes is impossible:~~

~~The A axis moves from A1 to A74880. That's 74879 units of motion.~~
~~Your config.g file sets the maximum A speed to 4000 units/min in the M201 command.~~
~~Divide 4000 into 74879 and you get 18.72~~

So even if there were no X moves at all the file cannot execute in less than 18.72 minutes. This explains why increasing acceleration and jerk alone only got me down to 21 minutes. I have now got it down lower by increasing maximum speeds too.

~~Please don't handicap RRF in your tests by using incorrect settings.~~

infamous_panda

@dc42 I am sure you are right and I am failing to communicate some of these technical items to get the proper solution.

The config.g settings I provided are equivalent to our GRBL settings with exception to jerk which I am not sure there is a parameter for that, so I made it the same as acceleration. I actually do not understand the difference between the two.

This file produces real world physical parts in 4 minutes. Not simulation. Why it's different from other controllers/firmware I am trying my best to understand and get it faster.

infamous_panda

@dc42 said in Raster Gcode:

I can only conclude that either GRBL is not honouring acceleration and jerk (or junction deviation) limits

This may be it. I'll do some digging

infamous_panda

@dc42 said in Raster Gcode:

Your config.g file sets the maximum A speed to 4000 units/min in the M201 command

I thought M203 was max speed. Which we set at 80,000. I'll try setting M201 much higher tonight and test it again

dc42

I thought M203 was max speed. Which we set at 80,000. I'll try setting M201 much higher tonight and test it again

You are correct, M203 is max speed. I'm sorry, I was reading the X value instead of the A value.

I will continue looking into this, because the simulation time is still greater than I expect. I suspect that jerk policy 1 is not being applied between some moves.

dc42

I found the main cause of the problem. The movement queue has limited length (39 moves on the Duet WiFi). When assembling moves, RRF needs to know that if moves suddenly stop being fed to it, it can decelerate to standstill without violating acceleration and jerk limits. When you have a lot of small moves, this has the effect of limiting the top speed. In your example, taking the first 39 moves in the file, they total about 22 units for the A axis. So the maximum speed the machine can reach (in units/min) is 60 * sqrt(2 * A * 22) + J, where A is acceleration, and J is allowed A jerk. That works out as 8735 mm/min which is well below the 80000mm/min maximum speed that you set.

By increasing the A acceleration to 400000, I was able to get the simulated time down to 4 minutes. Increasing it further to 100000 bright the simulated time down to 3 minutes. I didn't change the X parameters, or the A jerk limit.

If GRBL has a similar mechanism to protect against uncontrolled deceleration, then I guess that you have configured it for a much higher acceleration limit. Perhaps it has a longer move queue as well, however as top speed only increases as the square root of the length of the queue, I don't think that can be the whole story.

Even with such a high acceleration, the top speed doesn't reach the A speed limit, and it occasionally drops right down. I suspect that this is because the files contains a few moves in which X moves but A either doesn't move or moves hardly at all, although I didn't spot any in the parts of the file that I looked at.

HTH David

infamous_panda

@dc42 said in Raster Gcode:

The movement queue has limited length (39 moves on the Duet WiFi)

Is there a useful improvement to this on the Duet 3? Or a way to change this limit?

I am wary of increasing the global acceleration and jerk to get the raster time down. We have other non raster operations and even just jogging which I think can be catastrophic if we tried to accelerate 30kg at the values you tested.

infamous_panda

I received a Teensy 4.1 yesterday and using "stock" grbl-HAL was able to achieve a 9:21 time for our test file. I tweaked one setting in the firmware called BLOCK_BUFFER=250 in the planner.h file by increasing the value to 1024 and was able to achieve a stable 50,000 mm/minute etch resulting in a 1:20 time. I left my standard acceleration settings at 400 for both X and A axis.

I am not technical enough to state how this information can apply but it seems that Duet should be capable of this kind of performance. I much prefer working RRF and DWC over grbl but for now I think I have to just reserve it for 3D printing.

Just wanted to provide an update in case this helps in future RRF/Duet development for high speed laser engraving.

dc42

Looks like BLOCK_BUFFER set the maximum number of queued moves in grbl. So 250 is already much more than standard RRF.

I have it on my work list to allow the number of DDAs and DMs per DDA to be configured in config.g. That would allow you to increase the length of the movement queue without needing to recompile the firmware.

infamous_panda

@dc42

Awesome I have laser at home which I would love give Duet another go in the future.

dc42

@infamous_panda, we've just released RRF 3.2RC1. In this release you can increase the length of the movement queue without recompiling the firmware, using the new M595 command. Using this command, you may be able to overcome the difficulty you had in achieving the required movement speed.

infamous_panda

@dc42 Thanks, I will have to give this another review