Cancel Print/Job not immediate.

[Valveman]

If some reason, I choose to cancel a Job that is running, cancel only takes affect after the current motion has completed. Is that normal, as I'm new to all of this? Is an update to DWC or the 6XD a solution?

[jay_s_uk]

@Valveman that's normal.
If you turn on segmentation, something like M669 T1 S1 that should cancel quicker

[Valveman]

@jay_s_uk said in Cancel Print/Job not immediate.:

M669 T1 S1

Thanks for the suggestion, but I'm not very keen on how to implement what you're talking about.

[jay_s_uk]

@Valveman add it to your config.g

[droftarts]

@Valveman If you're not sure what segmentation is, I wrote this a while ago, need to put it in the documentation somewhere:

Notes on segmentation

Segmentation is splitting longer moves into a series of shorter moves. While a move is taking place, it can't be interrupted by pausing. With segmentation, you will get a faster response to a pause command.

The main use case for segmentation is in CNC applications where there may be a need to perform a pause during a long move, without waiting for the move to complete. But it can also be useful in machines that have fast-moving axes.
M699 S and T parameters define the minimum segments per second and/or minimum segement length. A move that is shorter than these minimums doesn't get segmented, but will still be processed. A move has to be twice as long as these minimums to be split into segments. When segementation occurs, it is split up into the minimum number of segments defined by either the S or T parameters.
To calculate the number of segments in a move, the calculation is:
number_of_segments = min(moveLength/T_parameter, moveDuration/S_parameter)
This is rounded to the nearest integer and with a minimum of 1. Note that:

• At slow speeds the segment lengths will be approximately the value of the T parameter
• But at high speeds where this would cause the S parameter to be exceeded, the S parameter will be the limiting factor and the segments will be longer.
• A move the needs segmentation (i.e. number_of_segments > 1) will be divided into equal size segments.
• Each segment is a separate move in the movement queue, so if especially fine segmentation is specified with high speed, it is possible to encounter movement queue starvation.
• Mesh bed compensation may also cause moves to be segmented

Ian

[Valveman]

@droftarts Well, that's a lot of information for me to digest! Lol. Might I see an example of code where M669 has been implemented?

[droftarts]

@Valveman See @jay_s_uk's post earlier. That's all you need. I was just explaining what it actually does.

Ian