Raster Gcode

infamous_panda

Just a quick question before I give up on this.

Default GRBL

Every time a spindle state M3 M4 M5 or spindle speed Sxxx is altered, Grbl would come to a stop, allow the spindle to change, and then continue.

Grbl's laser mode

Prevents unnecessary stops whenever possible
Adds a new dynamic laser power mode that automagically scales power based on current speed related to programmed rate.

In Reprap laser mode seems to apply only item #2. Which is why I and some others I have found in my search are experiencing a stutter in our movements. One example below.
https://forum.duet3d.com/topic/12785/duet-2-wifi-performance-for-laser-raster-printing/6

https://www.youtube.com/watch?v=ePAcdSWWiTc&feature=youtu.be&ab_channel=PawelSwitalski

Would it be possible or make a difference at all if I were to somehow map the laser firing to the extruder motors pins?

dc42

@infamous_panda , the code you posted earlier did not include any M3 commands, except for the one at the beginning (which RRF does not need). Why then are you saying that coming to a stop when M3 is executed is a problem?

Using the S parameter on G1 commands is the recommended way of driving a laser with RepRapFirmware. Changes in the S parameter do not cause the system to wait for movement to stop.

infamous_panda

Hi @dc42

"M3 M4 M5 or spindle speed Sxxx is altered"

My gcode changes the S parameter in this case to full on and full off at every dot. M3 turns on the laser initially. I am trying to explain sort out why the my movement is starting and stopping throughout the etch. This happens regardless even if I slow down the program so theoretically it's not the processing power that's the issue.

infamous_panda

I have also tried changing all the G0 moves to G1 with no effect.

dc42

@infamous_panda, send me a sample file and I will try it on one of my machines.

infamous_panda

@dc42 I very much appreciate this. Please see attached.

R001-00 - Copy.gcode

The code has a cut sequence at the beginning and end which seem to work fine. The high speed etching in the main body is what gives me trouble.

I left in M7 M8 M9 M3 M4 M5 commands. I know Reprap does not support all of these but they would be easy workarounds. What we would have difficulty in doing is changing the way our software generates the spiral etch.

For reference this file produces a 20mm diameter short 170mm long rod. We have files that produce 100mm diameter 2000mm long tubes.

dc42

Thanks for your file. It may be a few days before I get to try it as I have some other work to finish first.

infamous_panda

@dc42 I accept that gratefully. Thanks!

infamous_panda

@dc42

Not sure if you had a chance to run the code we provided yet but if not attached is a different file we put together to "stress test" a few other boards and platforms. If your still willing can you test this file instead so we have an apples to apples comparison.

CONTROLLER SPEED TEST.gcode

dc42

OK, will do.

dc42

In your speed test file, is A a rotary axes, and is the amount measured in degrees?

Please post your config.g file. [EDIT: I just found that in your earlier post.]

dc42

I have taken a look at your speed test file and config.g, and I can see some problems:

RRF will not recognise the F100000 line. I suggest you change it to G1 F100000 as I did for my tests.
X is alternately moving by a small amount and stationary. This means that the speed will be entirely dependent on the X axis jerk and acceleration settings. Your acceleration and jerk settings are low.
The A speed is constantly changing, because you are alternately moving just A and then X and A. So the A acceleration and jerk matter too.

My current internal build of RRF for Duet WiFi completes simulation of your file in 1 min 36 seconds, and predicts execution time of 2h 20min. This confirms that the Duet is processing the file quickly but your acceleration and jerk settings cause it to execute slowly.

A few more data points:

Changing the jerk policy from 0 to 1 reduces the predicted execution time to 1h 1m
Then increasing the allowed X and A jerk to 1000, and increasing X and A acceleration to 3000 reduces the predicted time to 21min

Your test file is not representative of the engraving you are trying to do. I suggest you generate up a test file that only moves X once per revolution of A.

infamous_panda

Thank you so much for your feedback. The new test file is a worse case high density of the engraving we do.

If I understand your comments correctly.

The Duet is imposing some mechanical limitation based on jerk and acceleration settings and the way it interpreting the motion.

The best case would be 21 minutes.

Duet 3 would not improve this.

We run GRBL-LPC currently and this completes in approximately 4 minutes. I have been testing other 32 bit GRBL builds and the result is similar. Feedback from the various developers mention that it may be a bottleneck from the pc based streamer to the controller. I will be looking at a 600mhz arm version this week in hopes that I can get this file to run under two minutes or better.

I am hesitant to increase our jerk and acceleration values since the moving mass of our sled (x axis) and tubes (a axis) can be in excess of 30 kg.

The goal is to accelerate to a constant speed through the etch like a lathe.

I guess I have to put Reprap aside for now.

dc42

@infamous_panda said in Raster Gcode:

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