Incomplete movements at verry low speeds and long durations

jay_s_uk

@Tricep-terry from RRF 3.4, the default driver mode was switched from stealthchop to spreadcycle

Tricep terry

I've tested it on the duet 3 mini 5+ as well now, and for 1 hour it works, for 2 hours it doesn't any solution to this? I'm looking into the meta commands to see if a while loop may be useful, if so, let say, I would like to run this line 10x how, would I write this up and is it possible to send a while loop via the code input bar?

T3P3Tony

@Tricep-terry how long does each section of the experiment last?

@Tricep-terry said in Incomplete movements at verry low speeds and long durations:

is it possible to send a while loop via the code input bar

No it is not

@Tricep-terry said in Incomplete movements at verry low speeds and long durations:

I would like to run this line 10x how, would I write this up

like this:

while iterations < 10
    G91 G1 A-90.763 F61

I note that you are setting the position relative before each test. but then moving a lot further with each test. is that deliberate?

Tricep terry

@T3P3Tony I don't have the sensor with me at the moment to easily check for how long the movement precisly last. This first experiment lasts for 5 min, as it should, the second one for 15 which is also correct, the third one for for 30 minutes which also works perfectly, the last one (A3630.5 lasts for an hour which also runs fine) increasing the steps for A to 7261.04 should last for 2 hours but stops after a bit more than 1 hour. Again, I don't have the exact time after which it stops yet but will measure it shortly.

yes, it is deliberate to move them relative each time. This script was made just to check for how long a single line can run effectively, so far, 1 hour seems to be a workable limit at a feedrate of 61, I just don't understand to why it is like that, based on previous experience I did note that at higher feedrates, longer durations of a single line are possible, I might delve a little bit deeper into this.

I was already afraid that running while loops are not supported by the code input bar, I'll check if this while loop enables the experiment to last for a lot longer and think of another workaround to enable that functionality. Is the issue from the code input bar that it only allows you to send one line at a time?

T3P3Tony

@Tricep-terry yes its not suitable for input that requires multiple lines to be formatted in a specific way to work. Why do you need to run it from the condole input line by line, and not create a gcode file and run that?

dc42

@Tricep-terry moves in RRF are calculated in clock ticks to 32 bits. The clock rate is 750kHz on Duet 3 boards and a (120/128)MHz on Duet 2. The maximum duration of a move is 2^31 clock ticks, which is somewhat less than an hour. If you want a longer duration move than this, you could split it into multiple GCode commands, or enable segmentation using the M669 command to have RRF do this for you.

To use a while loop, write a macro that takes the speed and target coordinates as parameters. In the macro use a while loop to do multiple moves.

Tricep terry

@dc42 I already guessed that it had something to do with the clock ticks, thanks for confirming this. I looked into the M669 command, however, didn't grasp how this should work / how to apply it. I did some preliminary testing using the while loop and this seems to work perfectly. I do have a few small questions, however, when using the while loop, are the Gcode commands buffered as normal, or are they only send after each iteration,or works it in a way that it sorts of creates a new file based on the while loop? I'm asking this because I would like to know if the motors stop between each movement or if they smoothly continue. I notice that when I run it, and disconnect from the board the codes are still being sent, I'm not sure if this is due to the buffer or how else this works but it is the behaviour I'm looking for. These questions are just to understand the limits of the machine to program it adequately.

Many thanks for your response.

Tricep terry

@T3P3Tony I see, usually I do run it in multiple lines using a gcode file, but then, I would still like to know and understand the limits, so I know it runs fine.

But the problems seem to be fixed using the while loop as @dc42 mentioned.

dc42

@Tricep-terry when using a while loop the movement commands are queued as usual. If there are no commands given between the movement commands of a type that cause the system to wait for motion to stop, then the movement commands will be blended into each other and the motors will not stop between them.

If you only need to send a small number of movement commands, you could send them on a single line instead of using a while loop, like this:

G1 X10 F30 G1 X20 G1 X30 G1 X40

To use M669 see https://docs.duet3d.com/User_manual/Reference/Gcodes#m669-set-kinematics-type-and-kinematics-parameters. Use something like:

M669 S1 T10

This says that each move should be divided into segments that are 1 second long with the proviso that each segment should be at least 10mm long. So if you command a movement rate below 10mm/second, it will divide the moves into 10mm segments. I don't recall whether S values lower than 1 are supported.

Now that I know that someone is commanding moves with very long duration, I'll look at segmenting them automatically. https://github.com/Duet3D/RepRapFirmware/issues/904

dc42 created this issue in Duet3D/RepRapFirmware

open Long duration moves don't work #904

Tricep terry

@dc42 many thanks for the clarifications, for now i'll stick to using the while loop as it seems straightforward. I tested it last night overnight for an total run duration of 11 hours, with lines that each lasts 30 minutes and it worked like a charm. I'll await the update on the segmentations and see if I'll revert from the while loop once the segmentation is integrated.

Kind regards,

Tricep terry

@Tricep-terry

I've been playing with this while loop function and it works great, however, I do have a question,

suppose I have a one general while loop that gives the steps for the axis A, B, C, D, U, V, W and Feedrate F

if I would only like to use axis A with 500 steps, but not B, C, D, U, V, and W so I'll send 0 or -0 steps for them (my while loop always sends relative moves). This works fine, but my question is, if I would also not configure them in the config file, would this harm anything as I noted in the documentation that you should not refer to axes that are not created, however, if I would just send -0 steps would this actually ruin/harm something?

If so, I suppose I could create 128 if statements with while loops (for all possible combinations) to check if the param is equal to 0.

this just makes it marco file a bit more tedious and prone to error, and so far I've tested both ways and there seems no performance issue even if the axes are not created in the config file so that just makes me wonder why this is so clearly stated in the documentation.

I do this cause sometimes I change the setup to use the XYZ axis with different steps/mm etc

dc42

@Tricep-terry currently if a command that has axis parameters such as G1 refers to axes that don't exist, those parameters are ignored. In a future version of RRF we may generate warnings when a command has unused parameters.