Gcode: stop current move with deceleration (no emergency)

[alankilian]

@turbomax How about hooking one of the RPI's GPIO lines into an endstop input on the Duet?

Then, when you detect the image is in focus, you trigger the endstop and that motor will stop immediately.

[turbomax]

@alankilian I have also thought about something like that, but it seems a bit hacky to me.
This is not an issue I have to resolve right now, it is more of a general question. I know it's not an essential functionality for 3D printing, but it is definitely relevant for CNC.

[JuKu]

The same approach also gives clean jogging: Key down, send move command towards machine limits; key up, send stop current movement command.

[turbomax]

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

The same approach also gives clean jogging: Key down, send move command towards machine limits; key up, send stop current movement command.

what do you mean by "same approach"? the one with the endstop?

the reason why i don't really like that approach is that i would have to rely on a controller-computer that has gpio pins. i would not be able to use this with a laptop.

what kind of might work would be using a gpio on the duet board which is pulling another (endstop) pin high. still a hack though.

but at least this discussion shows that there doesn't seem to exist a command to do this...

[dc42]

@Pinninti-Ajith this feature is planned for RRF 3.5.

[avdoverflow]

@dc42 Is this feature implemented in the current Release 3.5beta1 or Release 3.5beta2? If so, what is the GCode command to stop the current movement?

[T3P3Tony]

@avdoverflow no not yet.

Btw as a work around have you tried using a high segmentation value and then pause?

[avdoverflow]

@T3P3Tony Thanks for the response.

I am testing out segmentation on Firmware 3.4.5. I am connected to my Duet 2 Wifi with both the web interface and YAT.

I am trying to implement a CNC jog feature. For the CNC jog, I want to be able to:
1.) Quickstop as mentioned in this thread, and
2.) Poll the current machine position during any movement.
I think segmentation might work, but I noticed something odd while testing.

I first set my segmentation with "M669 S600 T0.05".
Test 1:
In Duet Web Control 3.4.5, I can do a move using the button.
In YAT, I can send "M408 S3" to poll the current position anytime during the move. I immediately get a machine position response back.

Test 2:
In YAT, I send "G91 G1 X10" to move the X-axis.
In Duet Web Control 3.4.5, I can send a console command "M408 S3" to poll the current position at anytime during the move. I immediately get a machine position response back.

Test 3:
In Duet Web Control 3.4.5, I can do a move using the button.
In Duet Web Control 3.4.5, I can send a console command "M408 S3" to poll the current position. The M408 command stalls and does not respond until the move is almost complete.

Test 4:
In YAT, I send "G91 G1 X10" to move the X-axis.
In YAT, I can send "M408 S3" to poll the current position. I do not get a response back until the move is almost complete.

Is there a way to remove that delay in Test 4? I am writing a C# program that primarily communicates with Duet through serial.

[T3P3Tony]

@avdoverflow when a channel is executing a command, it wont process the next command on that channel which is why you are seeing this discrepancy in when you are getting results.

[avdoverflow]

@T3P3Tony
1.) Is there a way to create multiple channels in a single interface (only USB or only WiFi) and then specify certain commands to each channel? For example one channel will be only for movement and the second channel will be only for reading position.

2.) Or is there a way to execute a movement command without locking the channel up? For example, in Grbl I am able to use the "?" command to get a "Status report query" anytime during a movement command. In Marlin "M114" (Get Current Position) also works anytime during a movement command.

Thanks for the help.

[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