Gcode: stop current move with deceleration (no emergency)

[timothyz]

@avdoverflow I think the proper solution is to make a change to the interface to allow the commands to be buffered such that any commands in the buffer that are non motion commands could be executed on the fly/mid move? dc42 will need to confirm the possibility of this. I am very excited to see move segmentation added, does this mean that it will be possible to track the distance to go until the end of a move in DWC? If so that makes it one of the last fundamental features of a fully formed cnc controller.

[dc42]

@timothyz said in Gcode: stop current move with deceleration (no emergency):

does this mean that it will be possible to track the distance to go until the end of a move in DWC?

In RRF 3.5beta1 and beta2 the machine coordinates are updated during the move, whether or not you enable segmentation.

GCode is essentially a serial protocol, so it's not possible to distinguish between commands that need to be buffered and those that don't. There would always be the possibility of a pending movement command blocking a status-requesting command. The correct way to resolve this is to use two separate command channels, which is in effect how DWC gets status updated even when it is waiting for a command to complete.

I am fairly sure you will find that M114 in Marlin blocks if the input buffer is full. If the movement queue has commands in it (and perhaps is full) but the input buffer is not full, then both RRF and Marlin will respond to M114.

[avdoverflow]

@dc42
Is there is guide or tutorial on how to create "two separate command channels?"

Getting status updates while waiting for commands to complete is what I am looking for. Thanks in advance.

[dc42]

@avdoverflow on what device are you looking to get status updates while commands initiated by that device are in progress, and how will that device be connected to the Duet?

The usual way to implement jogging in a CNC pendant (such as the one described at https://docs.duet3d.com/en/User_manual/Connecting_hardware/IO_CNC_Pendant) is to send a small movement command each time the jogging wheel is moved. If you want to use a button instead of a wheel and move the axis while the button is held down, you could do a similar thing i.e. send small movement commands at intervals while the button is held down. Either way, if you avoid sending movement commands too fast to be executed in real time, movement will stop when pendant stops sending movement commands.

[Dep]

@dc42 Is there any progress on this issue?

There is another idea - you can write a macro in which the submission of a micro movement command will be looped. In this cycle we can check the state of the pin and exit by pressing a button.

I need this to connect a weight sensor in a photopolymer printer.

[Dep]

@dc42 Any news on this issue? I decided not to make a new topic so as not to create duplicates.

[dc42]

@Dep right now our focus is on getting RRF 3.5 released. RC4 is almost ready and if no serious issues are found it it we expect to release 3.5.0 stable 1 to 2 weeks later.

[Dep]

@dc42 Thank you! We are really looking forward to this feature.

[Dep]

@dc42 What if the solution is to my question?

[droftarts]

@Dep There is a feature enhancement request for this already, along with various side issues, see:
https://github.com/Duet3D/RepRapFirmware/issues/745
https://github.com/Duet3D/RepRapFirmware/issues/746

Ian

T3P3 created this issue in Duet3D/RepRapFirmware

open Feed hold #745

T3P3 created this issue in Duet3D/RepRapFirmware

open Controlled deceleration when a homing switch is triggered #746