Solved M204 commands - are they queued like movement commands?
-
I'm trying to determine if M204 commands are being handled by the duet RRF2 (or RRF3) firmware before G1 movements that occur AFTER the M204 commands.
As a completely fictional example, consider the following:
M204 P1000 ; fast accel
...
... ; 100 or so movements with extrusions
...
M204 P300 ; slow down printing accel
G1 X0 Y10 E1 ; what accel is this running at?What acceleration is used for the last G1 command? 1000mm/sec/sec or 300mm/sec/sec?
The reason I'm asking is that I've playing with cura's acceleration control options, and I'd send M204 commands (with no parameters) via the console while watching a print. From that, it appears that the G1 movements/extrusions are queued, but that the M204 commands somehow skip the queue and take effect immediately. The end result is that embedding M204 commands to change accel for different parts of the print is somewhat useless, as the commands take effect too early.
-
You are quite right, M204 commands are not being synchronised with movement commands. I will fix that in RRF 3.1.
-
@dc42 said in M204 commands - are they queued like movement commands?:
You are quite right, M204 commands are not being synchronised with movement commands. I will fix that in RRF 3.1.
EDIT: thinking about it, I think that answer may be wrong. The acceleration is computed when the move is put in the movement queue, which means M204 commands should take effect exactly when they should, i.e. with the next movement command in the file.
-
@dc42 said in M204 commands - are they queued like movement commands?:
The acceleration is computed when the move is put in the movement queue, which means M204 commands should take effect exactly when they should, i.e. with the next movement command in the file.
Okay, that would explain why M204 returns a "new" accel before the movement has physically occured (but is already queued.) Thank you.