Posts made by lycean

@dc42 Thanks, that's great, and I also see your suggestion in @SumoSniper's thread to get the inactive reader to skip processing problematic macros with

if state.thisInput != null & !state.thisInput.active
  M99

@SumoSniper Thanks for pointing out your thread!

@gloomyandy Interesting, thanks for the information!

It certainly looks like something is evaluating the gcode ahead of the motion processing, and when the G31 is hit that evaluation follows the true path for the if statement (because that's correct given the state of the system at that instant) and then hits the abort. However, if that's the case, it shouldn't do anything - just like the echo doesn't do anything.

Hopefully someone with some more knowledge can take a peek, I just don't have the time or motivation to go pull the code and figure out how all this works.

@gloomyandy The reason I said 'simulation' was this quote by @dc42 (from https://forum.duet3d.com/post/104962)

One of the applications for multiple GCode streams is to have the second stream reading the print file ahead of the main one and simulating it, so that it can predict a tool change or colour mix change in advance, and prepare the new tool or change the colour mix ahead of time.

Using the multiple motion streams that you pointed out requires the use of the M596 command which I'm not using, so my assumption was that it might be the simulation idea mentioned in that post.

I'm running this stand-alone on a Duet 3 MB6HC (with a TOOL1LC board as well).

@gloomyandy That's an interesting point about the multiple gcode streams feature, I wasn't aware of that. If a second stream is simulating the job in advance it may be that the abort is actually being executed by the simulation instead of being ignored.

Correct, the failure occurs at the G31, but only when the command in the if block is an abort.

The abort command works whether the script is called from a print job or from the console. You can test this by putting the line abort "This should abort" at the top of test.g and run it, either way it'll abort as expected.

If you replace the abort command with an echo command then the problem doesn't occur, i.e. replacing the if block with this:

if sensors.probes[1].speeds[0] < sensors.probes[1].threshold
  echo "1.5 SHOULD NEVER FIRE: Probe speed "^sensors.probes[1].speeds[0]^" is less than threshold "^sensors.probes[1].threshold

works fine, here's an example of the output when test.g is called from a print job:

10/02/2024, 5:56:08 pm	M32 "0:/gcodes/run-test.g"
                        File 0:/gcodes/run-test.g selected for printing
                        1.0 Starting test
                        1.1 Commanding move
                        1.2 Pausing
10/02/2024, 5:56:11 pm	1.3 Setting threshold to 500
                        1.4 Testing to see if probe speed 1000.0 is less than threshold 500
                        1.6 Finished test
                        Finished printing file 0:/gcodes/run-test.g, print time was 0h 0m

The echo didn't get executed, as you'd expect.

@OwenD Thanks for pointing that out, it seems to have happened copying & pasting the code (not sure how I managed to do that...). I've re-copied the code in the original post.

I upgraded from 3.4.6 to 3.5.0-rc.3 and started getting spurious aborts while docking the Z probe on my printer. After a bunch of experiments I've managed to get a minimal repro script for the problem.

Save the script below as test.g in the sys directory (or macros, it doesn't matter, but I'm assuming it's in sys).

If you execute it from the console with M98 P"test.h" then it'll work as you expect. If you put that same line in a print job (a job with just that one line will do) and start the job the second abort command will trigger when the pause starts, i.e. before the if statement is reached.

; Use probe 1 as a dummy source for values
M558 K1 P8 C"0.io6.in" H2 F1000

; Center the head before we start
G0 X{(move.axes[0].max - move.axes[0].min) / 2} Y{(move.axes[1].max - move.axes[1].min) / 2} Z50 F10000
M400

;
; First test block
;
echo "1.0 Starting test"
G91
echo "1.1 Commanding move"
G0 X50 F1000    ; ** Need to command a move for the problem to occur.
G90
G31 K1 P2000    ; ** Need to set threshold so the 'if' statement below will evaluate to true before the pause.
echo "1.2 Pausing"
G4 P1           ; ** Need a delay after the move.
echo "1.3 Setting threshold to 500"
G31 K1 P500 ; Set threshold to 500 so the 'if' statement below should be false and the 'abort' shouldn't be executed. 
echo "1.4 Testing to see if probe speed "^sensors.probes[1].speeds[0]^" is less than threshold "^sensors.probes[1].threshold
if sensors.probes[1].speeds[0] < sensors.probes[1].threshold
  abort "1.5 SHOULD NEVER FIRE: Probe speed "^sensors.probes[1].speeds[0]^" is less than threshold "^sensors.probes[1].threshold
echo "1.6 Finished test"

Output if you run the script from the console:

09/02/2024, 8:21:00 pm	M98 P"test.g"
                        1.0 Starting test
                        1.1 Commanding move
                        1.2 Pausing
09/02/2024, 8:21:03 pm	1.3 Setting threshold to 500
                        1.4 Testing to see if probe speed 1000.0 is less than threshold 500
                        1.6 Finished test

Output if you run the script from a job:

09/02/2024, 8:22:09 pm	M32 "0:/gcodes/run-test.g"
                        File 0:/gcodes/run-test.g selected for printing
                        1.0 Starting test
                        1.1 Commanding move
                        1.2 Pausing
                        Cancelled printing file 0:/gcodes/run-test.g, print time was 0h 0m
                        1.5 SHOULD NEVER FIRE: Probe speed 1000.0 is less than threshold 2000
09/02/2024, 8:22:12 pm	1.3 Setting threshold to 500
                        1.4 Testing to see if probe speed 1000.0 is less than threshold 500
                        1.6 Finished test

This is the same issue I see in probe dock/undock process, the critical bits being the move, the condition for the if being true before the pause, and the pause.

EDIT: Re-pasted test.g script to fix up the problem @OwenD pointed out, which seems to have happened copying & pasting the code.

@dc42 Any chance of having trigger events that can be used to execute macros immediately before power off and immediately after power on so we could unhook & rehook the toolboard automatically?

@dc42 I'm running into this same issue. What would be nice would be to have a macro that, if defined, would be run immediately after asserting the PS_ON signal so that we could automatically reconnect the board (and re-initialize anything else too).