Much better results, but I'm guessing I can go even further. Thanks for the tip.

@dc42 said in Allow slower minimum movement speed:

n 2.03

If no one has told you yet today, just wanted to let you know that you're awesome.

Love the Duet board, your firmware, the community. Great stuff happening here.

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

Duet3Firmware_MB6XD.bin

You sir, are a wizard. I spent probably 2 hours looking at the code and IterateDrives was not something I even looked at, I kept going back to the DisableAllDrivers in the platform, which I guess was in the ballpark for the enable signal, but I was mostly looking for step loop hangs.

I loaded up your firmware and after 6 tests (M112 in job, driver error, and DWC EStop) I was unable to get any motion after M112. Bravo, I think I'm gonna keep your firmware until dc42 takes the pull request and releases. I still have a lot of work to do on my machine, although I've taken like a two week break.

@dc42 My Duet 2 does not produce pulses after M112 running 3.4.6

Note: The scope is in trigger mode

Duet2: M112 in job

Duet2: Using DWC Endstop

@dc42 From my experience, it would seem it is just continuing with the moves it was already performing. For example, I don't really see any behavior difference between the following two GCode jobs...

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

M112


G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

G1 Y500 Z100 F4000
G1 Y600 Z0 F4000

vs

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

M112

The M112 seems to be executed as it's read into the buffer, around the second movement loop, it then tries to complete the third loop after a brief stop (0.25 secs), nothing after M112 seems to ever try to execute, so that's good. Not sure if this matters, but the continued moves seem to move beyond where they should, which in my mind could only happen if more steps are sent than should. I'm gonna test my Duet 2 ethernet today (will post back maybe 2 hours from now) and see if it's got the same step continuation.

As far as the code goes, I wish I could help more but I mostly make websites in C#. Though, I will keep trying.

@dc42 Hi, I have a Duet 2 I could test 3.4.6 with to see steps on my analog scope. Not sure if that helps...

@timschneider Obviously my scope is way worse than Tim's so I would reference Tim's scope grabs over my shoddy videos, but I'm trying to do what I can...

Z stepper test with M112 in job

Z stepper test with no M112 in job, using DWC EStop

And lastly...
Z stepper test using external estop trigger with T0

That last one, in my mind, all but confirms there is a wait delay in that driver after enable is reactivated, and depending on how long the Duet keeps it enabled, eventually it too does move, but reacts to disabling immediately.

@timschneider What a relief to hear this is reproducible, I was starting to get really depressed. And you beat me to yanking my 6xd out of the cabinet and wiring resistors on an unconnected drive output on the 6xd. That was literally gonna be my next course of troubleshooting.

I took a vacation day today, so I'm about to test the Z (although your test all but confirm this is board/firmware behavior). Will post vid shortly.

@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?

@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.

@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 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).