Movement after M112 E-Stop!

timschneider

@hpiz
Maybe it is some kind of a bug.

can you enable event logging? Post your config.g, your movement macro and describe your setup in more detail. Do you use the Enable Pin on your servo controllers?

M929 P"0:/sys/eventlog.txt" S3

and reproduce the error.

If your movement macro looks something like

while true
  G1 X10 F20000
  G1 X600 F20000

change it to:

while true
  G1 X10 F20000
  G1 X600 F20000
  G4 P500

as the first example will cause the duet to have 100% system load and the sending of the M112 may fail or is delayed.

Maybe @dc42 can help us with that, as I don't understand the first stop and the second and final stop. What is causing the first stop? as it is not the M112.

EDIT: I thought somehow that he is in SBC mode.

gloomyandy

Are you running standalone or with an SBC? As above more details of your configuration will probably help folks investigate further.

hpiz

@timschneider and @gloomyandy Sounds like I've got some homework today, yes, I will gather all information, logs, and run the suggested tests and modifications, until then I can certainly fill in what the setup is...

Running Duet 6XD with no SBC
Utilizing enable signal on all drives, currently active disabled/low (plan to reverse in future for safety)
Utilizing error signal on all drives, currently active enabled/high (again plan to reverse for safety, especially when 3.5.1 comes out with polarity configuration per drive for error signals)

@timschneider said in Movement after M112 E-Stop!:

Maybe @dc42 can help us with that, as I don't understand the first stop and the second and final stop. What is causing the first stop? as it is not the M112.

My understanding is that M112 is executed on the first stop, the DWC even immediately shows the Estop message and darkens the webpage (message can almost be seen in https://drive.google.com/file/d/1f8hx3Qj4nXPbtJ93OoA9ezyFlq1tjeU4/view, but you can see the webpage darken on first stop)

@timschneider said in Movement after M112 E-Stop!:

Maybe you hit a case where the setup is not getting any low latency.

The first stop is always very low latency, mere milliseconds. Unless that stop is somehow unrelated to M112 then it's not taking too long to trigger for my needs.

Config.g was posted earlier and is still current
I don't intend to use loops in macros really, this is just the best movement test I could come up, I will try and get an actual job running as well and test
The movement macro loop used in the above posted videos is

G91
while {iterations<5}
   G1 Y-100 F4000
   G1 Y100 F4000

A dwell in the loop would not be representative of an actual job (even if it works, it wouldn't prove that a real job will stop) so I think I will try...

G91
G1 Y-100 F4000
G1 Y100 F4000
G1 Y-100 F4000
G1 Y100 F4000
G1 Y-100 F4000
G1 Y100 F4000
G1 Y-100 F4000
G1 Y100 F4000
G1 Y-100 F4000
G1 Y100 F4000

Macros will be used for automatic tool changing and accessories like mist coolant, touch probes, etc
I'm just a measly sys admin by day so these embedded systems are somewhat foreign to me in terms of their system architecture and data flow. But I feel like the focus on the driver error signal is not warranted. As I've shown in video, this can happen regardless of the means by which M112 is sent (I just like grabbing the drive because it's my primary objective, as I will not utilize M112 to manually stop the machine, will use button to relays for power cut).

When I have logging and more answers to my "homework questions" I'll be sure to post them.

hpiz

@timschneider Here is the latest test run configuration that started moving again after clicking the EStop button in DWC in the following macro...

Y Movement Loop

G91
G1 Y-100 F4000
G1 Y100 F4000

G1 Y-100 F4000
G1 Y100 F4000

G1 Y-100 F4000
G1 Y100 F4000

G1 Y-100 F4000
G1 Y100 F4000


G1 Y-100 F4000
G1 Y100 F4000

with the following config.g

; Configuration file for Duet 3 MB 6XD (firmware version 3.3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Wed Jul 26 2023 17:05:34 GMT-0400 (Eastern Daylight Time)

; General preferences
G90                             ; send absolute coordinates...
M550 P"JP-60120"                ; set printer name
M929 P"0:/sys/eventlog.txt" S3  ; Enable debug logging

;CNC Mode
M950 R0 C"out8+out5" Q20 L24000 ; Create spindle index 0, with PWM pin on heater 3 and 12000 RPM achieved at full PWM
M563 P1 S"Spindle 1" R0         ; Create tool 1 with spindle 0 and call it "Spindle 1"
M453                            ; Select CNC device mode
M669 K0 S2 T1


; CNC Pendant Enable
M575 P1 S1 B57600               ;Enable serial comm on io0 56700 baud rate

; Set up outputs
M950 P0 C"out4" ; Define tool loosen pin as P0 mapped to output 8
M950 P1 C"out3" ; Define chip blast pin as P1 mapped to output 7
M950 P2 C"out7" ; Define mist coolant pin as P2 mapped to output 6
M950 P3 C"out6" ; Define touch blast pin as P3 mapped to output 4

; Set up inputs
M950 J0 C"io1.in" ;Define tool probe depressed over limit from io3 to Pin 0
M950 J1 C"!io8.in.iso" ;Define VFD Fault input from io8 to Pin 1

; Network
M552 P0.0.0.0 S1                ; enable network and acquire dynamic address via DHCP
M586 P0 S1                      ; enable HTTP
M586 P1 S0                      ; disable FTP
M586 P2 S0                      ; disable Telnet

; Drives
M569 P0.4 S0 T3:3:6:0       ; physical drive 0.4 goes backwards
M569 P0.5 S0 T3:3:6:0       ; driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
M569 P0.3 S0 T3:3:6:0       ; driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
M569 P0.0 S0 R0 T5:5:9:0       ; physical drive 0.0 goes backwards
M569 P0.1 S1                    ; physical drive 0.1 goes forwards
M569 P0.2 S1                    ; physical drive 0.2 goes forwards
M584 X0.3 Y0.4:0.5 Z0.0             ; set drive mapping
M92 X160.00 Y320.00 Z640.00     ; set steps per mm
M566 X1800.00 Y180.00 Z120.00     ; set maximum instantaneous speed changes (mm/min)
M203 X15000.00 Y12000.00 Z5000.00 I5  ; set maximum speeds (mm/min)
M201 X400.00 Y200.00 Z200.00        ; set accelerations (mm/s^2)
M564 H0                         ; Allow stepper movement before homing
; Axis Limits
M208 X0 Y0 Z0 S1                ; set axis minima
M208 X600 Y1200 Z170 S0         ; set axis maxima

; Endstops
;M574 X1 S1 P"io0.in"            ; configure switch-type (e.g. microswitch) endstop for low end on X via pin io0.in
M574 Y2 S1 P"!io2.in+!io4.in"   ; configure switch-type (e.g. microswitch) endstop active low for high end on Y via pin io5.in and io2.in
M574 Z2 S1 P"!io8.in"            ; configure switch-type (e.g. microswitch) endstop for high end on Z via pin io2.in

; Z-Probe
M558 P5 C"io3.in" H5 F120 T6000 ; set Z probe type to switch and the dive height + speeds

;Triggers
M581 T2 P0 S1 ; Run trigger2.g on pin 0 active->inactive for tool probe overpress
M581 T3 P1 S1 ; Run trigger3.g (EmStop) when pin 9 goes from active to inactive indicating VFD fault


; Heaters
M140 H-1                        ; disable heated bed (overrides default heater mapping)

; Fans

; Tools
M563 P0 D0 F0                   ; define tool 0
G10 P0 X0 Y0 Z0                 ; set tool 0 axis offsets



;Machine Initialization
M18                          ; disable all steppers
M17                          ; enable z stepper so it doesn't fall

; Custom settings are not defined

and the following eventlog.txt was recorded

power up + 00:00:00 [info] Event logging started at level debug
power up + 00:00:00 [info] Running: Duet 3 MB6XD v1.01 or later: 3.4.6 (2023-07-21 14:11:58)
power up + 00:00:00 [debug] HTTP is enabled on port 80
power up + 00:00:00 [debug] FTP is disabled
power up + 00:00:00 [debug] TELNET is disabled
power up + 00:00:00 [warn] Error: Pin 'io8.in' is not free
power up + 00:00:00 [warn] Error: bad drive number
power up + 00:00:00 [warn] Error: in file macro line 74: G10: Invalid tool number
power up + 00:00:03 [debug] Done!
power up + 00:00:03 [debug] RepRapFirmware for Duet 3 MB6XD is up and running.
power up + 00:00:10 [warn] Ethernet running, IP address = 10.0.0.210
power up + 00:00:10 [warn] HTTP client 10.0.0.10 login succeeded
2023-10-29 16:08:29 [warn] Date and time set at power up + 00:00:10
2023-10-29 16:09:21 [warn] HTTP client 10.0.0.214 login succeeded
2023-10-29 16:09:21 [warn] HTTP client 10.0.0.214 login succeeded
2023-10-29 16:09:22 [warn] HTTP client 10.0.0.10 login succeeded
2023-10-29 16:09:23 [warn] HTTP client 10.0.0.221 login succeeded
2023-10-29 16:10:21 [info] Event logging stopped

Other than letting me know I have a total of 3 different computers in my house with DWC up in the browser, and confirming my theory that opto-isolated inputs are shared with direct inputs as I was feeling was the case, but is not documented clearly (note: Z axis endstop is not even wired yet), it doesn't reveal much.

I didn't record this one, because the behavior is identical to the ones I've already posted. This is feeling more and more like a very low level firmware bug.

I was out all day at a machine shop trying to mill some parts needed for my machine (replacing the plastic carriage brackets for gantry), so I didn't and probably won't have time today to test a proper G code job, but I suspect much the same, and also doesn't make it happening in a macro ok.

timschneider

thank you for the details.

@hpiz said in Movement after M112 E-Stop!:

M564 H0 ; Allow stepper movement before homing

can you try to remove this from your config and instead set a homing for Y manual via M92 Y0 and try again?

And do you use some kind of input filter on your servo drives? or are they using some sort of input filter by default?

Because the M112 command is doing different things:

it will disable all drivers (disable the enable pin)
will erase all movement commands from the output-queue (also from the input queue?)
stop generating Platform Ticks
reset gcode

hpiz

@timschneider So these are my first experience using servo motors so I'm not really well versed with them, but I believe there is no input filtering currently set on them as per the highlighted setting in the following image link...
https://drive.google.com/file/d/1f_pghiU0pyJKdWfWDeJs9BGFsF7hdGVT/view

Ok, so I've commented the M564 out so current config.g is...

; Configuration file for Duet 3 MB 6XD (firmware version 3.3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Wed Jul 26 2023 17:05:34 GMT-0400 (Eastern Daylight Time)

; General preferences
G90                             ; send absolute coordinates...
M550 P"JP-60120"                ; set printer name
M929 P"0:/sys/eventlog.txt" S3  ; Enable debug logging

;CNC Mode
M950 R0 C"out8+out5" Q20 L24000 ; Create spindle index 0, with PWM pin on heater 3 and 12000 RPM achieved at full PWM
M563 P1 S"Spindle 1" R0         ; Create tool 1 with spindle 0 and call it "Spindle 1"
M453                            ; Select CNC device mode
M669 K0 S2 T1


; CNC Pendant Enable
M575 P1 S1 B57600               ;Enable serial comm on io0 56700 baud rate

; Set up outputs
M950 P0 C"out4" ; Define tool loosen pin as P0 mapped to output 8
M950 P1 C"out3" ; Define chip blast pin as P1 mapped to output 7
M950 P2 C"out7" ; Define mist coolant pin as P2 mapped to output 6
M950 P3 C"out6" ; Define touch blast pin as P3 mapped to output 4

; Set up inputs
M950 J0 C"io1.in" ;Define tool probe depressed over limit from io3 to Pin 0
M950 J1 C"!io8.in.iso" ;Define VFD Fault input from io8 to Pin 1

; Network
M552 P0.0.0.0 S1                ; enable network and acquire dynamic address via DHCP
M586 P0 S1                      ; enable HTTP
M586 P1 S0                      ; disable FTP
M586 P2 S0                      ; disable Telnet

; Drives
M569 P0.4 S0 T3:3:6:0       ; physical drive 0.4 goes backwards
M569 P0.5 S0 T3:3:6:0       ; driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
M569 P0.3 S0 T3:3:6:0       ; driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
M569 P0.0 S0 R0 T5:5:9:0       ; physical drive 0.0 goes backwards
M569 P0.1 S1                    ; physical drive 0.1 goes forwards
M569 P0.2 S1                    ; physical drive 0.2 goes forwards
M584 X0.3 Y0.4:0.5 Z0.0             ; set drive mapping
M92 X160.00 Y320.00 Z640.00     ; set steps per mm
M566 X1800.00 Y180.00 Z120.00     ; set maximum instantaneous speed changes (mm/min)
M203 X15000.00 Y12000.00 Z5000.00 I5  ; set maximum speeds (mm/min)
M201 X400.00 Y200.00 Z200.00        ; set accelerations (mm/s^2)
;M564 H0                         ; Allow stepper movement before homing
; Axis Limits
M208 X0 Y0 Z0 S1                ; set axis minima
M208 X600 Y1200 Z170 S0         ; set axis maxima

; Endstops
;M574 X1 S1 P"io0.in"            ; configure switch-type (e.g. microswitch) endstop for low end on X via pin io0.in
M574 Y2 S1 P"!io2.in+!io4.in"   ; configure switch-type (e.g. microswitch) endstop active low for high end on Y via pin io5.in and io2.in
M574 Z2 S1 P"!io8.in"            ; configure switch-type (e.g. microswitch) endstop for high end on Z via pin io2.in

; Z-Probe
M558 P5 C"io3.in" H5 F120 T6000 ; set Z probe type to switch and the dive height + speeds

;Triggers
M581 T2 P0 S1 ; Run trigger2.g on pin 0 active->inactive for tool probe overpress
M581 T3 P1 S1 ; Run trigger3.g (EmStop) when pin 9 goes from active to inactive indicating VFD fault


; Heaters
M140 H-1                        ; disable heated bed (overrides default heater mapping)

; Fans

; Tools
M563 P0 D0 F0                   ; define tool 0
G10 P0 X0 Y0 Z0                 ; set tool 0 axis offsets



;Machine Initialization
M18                          ; disable all steppers
M17                          ; enable z stepper so it doesn't fall

; Custom settings are not defined

I also made a test job file...
1001.g

;1001
;T24  D=10 CR=0 - ZMIN=-1 - FLAT END MILL
G90
G21


G1 Y500 F4000
G1 Y600 F4000

G1 Y500 F4000
G1 Y600 F4000

G1 Y500 F4000
G1 Y600 F4000

G1 Y500 F4000
G1 Y600 F4000

G1 Y500 F4000
G1 Y600 F4000

Same behavior...

And here is the debug log

power up + 00:00:00 [info] Event logging started at level debug
power up + 00:00:00 [info] Running: Duet 3 MB6XD v1.01 or later: 3.4.6 (2023-07-21 14:11:58)
power up + 00:00:00 [debug] HTTP is enabled on port 80
power up + 00:00:00 [debug] FTP is disabled
power up + 00:00:00 [debug] TELNET is disabled
power up + 00:00:00 [warn] Error: Pin 'io8.in' is not free
power up + 00:00:00 [warn] Error: bad drive number
power up + 00:00:00 [warn] Error: in file macro line 74: G10: Invalid tool number
power up + 00:00:03 [debug] Done!
power up + 00:00:03 [debug] RepRapFirmware for Duet 3 MB6XD is up and running.
power up + 00:00:10 [warn] Ethernet running, IP address = 10.0.0.210
power up + 00:00:10 [warn] HTTP client 10.0.0.10 login succeeded
2023-10-30 17:34:44 [warn] Date and time set at power up + 00:00:10
2023-10-30 17:34:44 [warn] HTTP client 10.0.0.221 login succeeded
2023-10-30 17:34:44 [warn] HTTP client 10.0.0.221 login succeeded
2023-10-30 17:34:44 [warn] HTTP client 10.0.0.214 login succeeded
2023-10-30 17:34:44 [warn] HTTP client 10.0.0.214 login succeeded
2023-10-30 17:34:44 [warn] HTTP client 10.0.0.10 login succeeded
2023-10-30 17:36:23 [warn] Error: G0/G1: insufficient axes homed
2023-10-30 17:36:34 [warn] Started printing file 0:/gcodes/1001.gcode
2023-10-30 17:36:34 [debug] File 0:/gcodes/1001.gcode selected for printing
2023-10-30 17:36:48 [debug] Done printing file
2023-10-30 17:36:48 [debug] Done printing file
2023-10-30 17:36:48 [warn] Cancelled printing file 0:/gcodes/1001.gcode, print time was 0h 0m
2023-10-30 17:36:48 [info] Event logging stopped

Then, based on your comment about the servo input filtering, I decided to test both my Y axis servo motors, and my Z which is a stepper...

1001.g with Z movement

;1001
;T24  D=10 CR=0 - ZMIN=-1 - FLAT END MILL
G90
G21


G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

And in the video below, the stepper also moves after the first stop (though not as far or as long as the servos, not sure if the amount of movement per axis has any impact), so even with steppers, there would still be enough movement to easily break a tool or shove the tool right through my part or bed. (Note: the Z axis stepper is the thing with the yellow tape flag spinning with the shaft)

https://drive.google.com/file/d/1ffUtCYofIbbLlfk8L9m_zjEHs5LbMnmi/view?usp=sharing

I've also noticed I can get pretty much 100% failure rate by triggering an estop near the end of a move.

hpiz

@hpiz Idk if it matters, but I didn't explicitly mention that all my axes are driven with closed loop external drivers.

hpiz

@timschneider I also want to really share my appreciation with you trying to help me out with this, you could just ignore my problems and focus on your own stuff, but to be getting support from a fellow CNC'er (who has an epic router) does not go without my gratitude. I commend your interest in getting more CNC machines running on a Duet!

timschneider

@hpiz
are your drivers enable active high or active low?

@hpiz said in Movement after M112 E-Stop!:

Utilizing enable signal on all drives, currently active disabled/low (plan to reverse in future for safety)

can you tell in which position the driver enable jumper is?

Driver Enable Polarity 	A jumper in the "left" position is used for external drivers which are enabled when a voltage is applied to the enable connection (Active Enable). A jumper in the "right" position is used for external drivers which are disabled when a voltage is applied to the enable connection (Active Disable) (Note the v0.1 boards have the silkscreen reversed).

M569 P0.4 S0 T3:3:6:0
M569 P0.5 S0 T3:3:6:0

This will fallback to the default, because no R parameter is set, and the default is active low:

Rnnn Driver enable polarity: 0 = active low, 1 = active high, -1 = driver is always disabled and is not monitored (default 0)

dc42

@hpiz I am trying to understand this behaviour. When M112 is processed it disables all drivers immediately and shuts down the movement system. So I don't see how movement can continue.

Do you see the Driver Error message in DWC? Unfortuately your video is not clear enough for me to read the message boxes on the laptop.

hpiz

@timschneider Currently Active low on all drivers. Jumper is on Active Low, (left for me because I mounted the board upside-down)

Enable Jumper Picture

Also, M18 and M17 work exactly as expected for all or specific drivers.

@dc42 I currently have a driver-error system macro, it was suggested to try removing my M291 message pop-up that I had indicating which driver failed (pretty much identical to the default message when driver-error doesn't exist), so it doesn't have any popups right now, my driver-error system macro is just a single line, M112. Having said that, when the message was in the macro it showed the correct driver that throws the error. The only visual indication of driver error is the yellow toast on the bottom of the laptop's screen indicating "Emergency Stop: yada yada"

Let me know whatever information/videos you need related to this.

BTW I've been uploading all the my images and videos to Google Drive which compresses the preview for both file types. If you download the files the quality of both is much better.

There's really not much physically set up on this machine so I am more than willing to try watered down/minimalist/test config.g's since I only have the one axis actually fully wired and assembled mechanically(the dual Y).

I also have an analog oscilloscope that may become useful, although a digital one would be more appropriate.

timschneider

@hpiz said in Movement after M112 E-Stop!:

Also, M18 and M17 work exactly as expected for all or specific drivers.

that was the next check I had in mind

so I'm starting to run out of ideas.

But one thing I've noticed while looking at the wiring/jumper picture is, that the GND Pin of the driver header is not connected. Can you show us a picture of the duet, one servo driver and the z-closed loop driver wiring? And maybe provide the datasheet for the drivers.

Cause I needed the seperate GND connection between the Duet and each closed loop driver, for the alarm pin.

And another thought, is your power supply strong enough to provide the over current in the stall event?

I have not been able to observe this behaviour with my setup, so this is the reason why I try to understand this as good as possible and in the end hopefully solve the problem for you as well

hpiz

@timschneider Seeing as the control signals for drivers pull to ground and all my drivers use optoisolated inputs, I am using 5v as common and the only ground connected per cable is the shield ground which flies over with the endpoint signal wire over the the IO headers and is grounded there.

My alarms for the servos are optoisolated for pull up, the z driver for the stepper is reverse poloarized optoisolated for pulldown, so I actually have the error pin for that one going to common (shared with alarm and brake) and 5v going into it's alarm output. I will eventually change to the proper setup and place a resistor between 5v and the alarm output, and ground on common to create an error low circuit. And then through configuration of integrated servos, change the output to be on when not in error so all drivers are error low.

I'm using JMC 400W integrated servos on Y and X
JMC Manual

And the Z is a StepperOnline closed loop 400W stepper
StepperOnline driver Manual

Full Duet board picture

Regarding power supplies, I actually don't know if there is enough overhead for stall current when it is moving at full speed and the 50kg of gantry and spindle are attached, but I think at the slow speed it is moving during these tests, and only moving the rotational inertia of the ballscrew plus the linear inertia of the little linear bearing, I would guesstimate there is little to no backfeed during these test.

There is one power supply for the Duet and 24V accessories (endstops, relays, solenoids,etc...) and one for each driver. The Duet/Acc PSU is 480W and the driver ones are all 36V 600W, all PSU's are switch mode.

Pic of PSU's just for fun

Edit: forgot the other pics

All driver wiring uses the following color code:
Yellow - 5V
Blue - Step/Pulse
White - Dir
Green - Enable
Red - Error/Alarm
Orange - Endstop input (except Z, unused for Z)
Brown - Unused
Black - Unused
Shield - Ground on Duet side

Back view of servo wiring

"Top" view of servo wiring

Just a pic showing the orange endstop signal wire going to the endstop wire

Z Driver wiring

timschneider

@hpiz hm, so I don't see anything wrong ...
Out of curiosity, can you try running your movement job file and pressing the emergency stop in the DWC? is it still moving?

hpiz

@timschneider When I get home from work today I'll grab that video evidence, but it does the same thing, albeit sometimes heavily delayed (~3-4 seconds), due to my WiFi I think, I've been having some intermittent disconnect issues with it lately.

@dc42 would know best I think, but is it possible there is a need to either reflash my firmware, or possibly an issue with the board (I find the latter hard to believe).

timschneider

@hpiz maybe a dumb question, but do you have a while loop in your daemon.g without a G4?

I try to understand what is causing the delay, as dc42 said, if the M112 is processed, there should be no delay. So something is maybe delaying the processing of the M112, but again that is not explaining the first and the second stop. That was the reason why I asked for the power supply (short power down/undervoltage can cause many different sotware problems), but I think this is sufficient. The reason why I keep asking about the while loops without a "break" is, that the control of the gcode processing is not handed back to process other codes if it is running in a tight loop. Or if for what ever reason there is a blocking(queueable) G-Code infront of the M112, the processing of the M112 will be delayed e.g. turn a relay off with M42 (that was the reason why I asked you to put the M112 at the first and only position of the driver-error.g).

On last idea is, to wire an e-stop and configure it as a estop in duet - just to rule the gcode processing out. if this also failes, it is something in the movement system or the drivers itself, but I don't think it is related to the drivers cause you are using two different kinds of drivers (servos and steppers)

e.g. recycle your tool probe depressed over limit and uncomment T2 under triggers

M581 T0 P0 S1 R0

hpiz

@timschneider Here's a test without the additional modifications you suggested using the EStop button in DWC...

https://drive.google.com/file/d/1hTqF0GCi4dEQjOZyk1uR_Ctzywv-66Zg/view?usp=drive_link

I really think the delay I mentioned is just a network communication delay and not a delay within the Duet itself (it's not delayed every time), but I could be wrong. I would rate this test as having zero delay, as soon as I hit the button the first (very short) stop happened "instantly".

@timschneider said in Movement after M112 E-Stop!:

maybe a dumb question, but do you have a while loop in your daemon.g without a G4?

I don't think any question about this behavior could be considered dumb, but no, I haven't even made a daemon.g, the only configuration I've done so far is the config.g, a few custom M command system macros, and the driver-error system macro everything else is stock.

Screenshot of Duet System Files
^Any file with a modify date of 7/26/2023 is unmodified. Everything other than config.g is very very simple, but let me know if I need to share the contents of any of them.

@timschneider said in Movement after M112 E-Stop!:

I keep asking about the while loops without a "break" is, that the control of the gcode processing is not handed back to process other codes if it is running in a tight loop.

I agree completely, it's what I would assume first as well, that would presumably have the same effect I'm having, but I only ever had the one loop in my movement test macro, no other loops were defined by me anywhere else.

And finally, I changed the tool probe overpress trigger to T0 and got the same behavior...

https://drive.google.com/file/d/1hVCYuPwHx6Yzlz80FHZKv9pIseA7QbPQ/view?usp=sharing

timschneider

@hpiz thank you for all these test and based on these tests I think, we don't need to focus on the driver-error or external driver configuration. It appears to me, that there is a problem with the following configuration

Duet 3 Main Board 6XD standalone mode
Emergency Stop (DWC and external trigger confirmed)
Active disabled/low external drivers

So may I ask you to do two more tests?

check if the stepper motors are active or disabled after the final stop, are you able to move them freely or not? If they are blocked/active that could describe the first and second stop.
put a M112 in the job file, somewhere in the middle. If the Y-axis is moving after the M112 in the job file, than there is a bug in the software, as the M112 is in the same input channel as the movement commands and there is no "normal" way, that movement will appear after the m112.

hpiz

@timschneider So I'm starting to lose my mind, and have begun talking to myself on video (lol, really so I have to type less, but I am starting to get quite lost)

Disclaimer: While my Z stepper can and has moved after a first stop of M112, it is far far less consistent, more than 80% of the time it stops only once as it should (compared to like 2% for the servos). But while the hardware differences clearly are making a behavioral difference, I believe the underlying cause (that I am currently convinced of) is still a problem. I'll get there...

@timschneider said in Movement after M112 E-Stop!:

Active disabled/low external drivers

I'm starting to narrow onto this or something about the enable signal (although the pulse/step signal is still misbehaving imo), and it could be as simple a fix as a wiring change.... maybe, I'm still very confused though. And my gut tells me no wiring change can fix this.

I'm getting confused about the effect of the Enable jumper, I can have it on either position and the drivers are active with no other changes to Duet config or driver parameters.

Also within config.g what does enable high (R1) on a driver mean if the enable pin is actually a ground sink, does that mean enable high (R1) means the transistor is on for the Enable(-) pin meaning it's actually pulled to ground, because that appears to be what I'm seeing. Enable low (R0) keeps my enable wire high since I have it fed by 5V through the optoisolater at the servo. And when I switch to enable high (R1) the enable wire is low, indicating current is passing through the opto on the driver.

@timschneider said in Movement after M112 E-Stop!:

check if the stepper motors are active or disabled after the final stop, are you able to move them freely or not? If they are blocked/active that could describe the first and second stop.

M18 test + EStop drive enable check - Conclusion: Stepper and servo motors are disabled after final stop

@timschneider said in Movement after M112 E-Stop!:

put a M112 in the job file, somewhere in the middle.

M112 mid job - Conclusion: Same effect

Oh, I didn't stop there (warning: the oscilloscope will make an appearance)

M112 in job with M291 right after - Conclusion: M291 is not executed but G movements are

M112 at end of job expecting no strange movement - Conclusion: Still moved after a stop...

Investigating that last test a little deeper - Conclusion: Yup, it did still move, and past where it should have. Ok, obviously the buffering of move commands is superseded by the M112 which executes as soon as it's read.

What about the Z stepper, it does behave somewhat better - Conclusion: I'd say you can see a few steps after the first pause, but much better than my other drives.

Ok let's test the x axis - Conclusion: You can see a clear stop and restart, then final stop just like the Y. While I say in-vid it's about the servo's, I'm not sure they are to blame, there's more.

I kept going off video to try reversing the enable polarity in both the servo params and the duet, I found some quirks I mention in the next vid but it's really not in my focus right now. Anyways, none of that changed anything about the behavior.

At this point I felt I had no option but to pull out the scope. I'm analyzing the following video with the following assumptions...

There is no signal being generated by the driver, the signals seen on scope are entirely from the Duet, I feel that's a pretty safe bet.
The difference in behavior between my Servo's and my Z stepper is down to some kind of buffer/safe time between disabling the drive and re-enabling. I would have to either also assume most drivers have said wait time, or my board is acting differently.

Watching the control signals on scope in realtime

After this test, I really can't blame the servo's at all. They're doing exactly what they are being told to do by the Duet, think it might be time give up. Why would there be steps still coming out of the duet after a stop? Why would the enable signal go to disable->enable->disable? I really am having a hard time trying to think of any configuration or parameter I can change to just have the Duet not send steps after an M112 let alone deactivate, then reactivate a driver.

hpiz

@hpiz I don't have the energy today, but I plan to show the same signals going to my z driver, but being ignored by the driver, which I assume will be the case. I mean why would one drive output behave differently from another?