Duet not consistently running code

p8blr

I have a bunch of code to automatically open/close a retractable cover on my printer and I have subsets of code that run different beeps to indicate motion and M291's to prompt the user. What I'm noticing is that it's not always running all of my code. I can't tell if line 10 isn't running b/c the motor is stopped with relay logic, lines 11 and 12 are definitely not running.

Problematic code

M98 P"soundNotifyShort.g"	; beep
M42 P17 S1	; set motor direction to closing
G4 S0.25	; short wait to let relay flip
while sensors.gpIn[15].value == 1	; while not fully closed yet
	M42 P16 S1	; turn on motor
	G4 S4		; wait
	M98 P"promptUser.g"	; give user opportunity to cancel
	if global.userPrompt == 1
		break ; user canceled
M42 P16 S0 	; turn off motor
M98 P"soundAlert.g"	; beep - note this is apparently not running b/c I don't hear it beep
M291 P"Top cover is at max closed" S2 ; this doesn't run either b/c I don't see the message box in DWC

soundNotifyShort.g

M42 P20 S1
G4 S.37
M42 P20 S0

promptUser.g

; Working within the limitation of the firmware, for there to be a non-exiting default option you must have a Cancel button (J1) and a message box
; of S4 or above, so the options are redundant if you only want a yes or no value, which I do. So the logic is reversed, no response sets input = 0
; creating a new global variable, and setting it to a non-zero value. So IF the user responds, the variable will change to 0

set global.userPrompt = 3
M291 P"Continue?" S4 T3 J1 K{"Yes", "No"} F0
set global.userPrompt = input

; global.userPrompt legend
; 0 is Yes
; 1 is No
; 3 is No response

soundAlert.g

M42 P19 S1
G4 S2.2
M42 P19 S0

jay_s_uk

@p8blr SBC mode? Standalone? Firmware version?

p8blr

@jay_s_uk SBC mode, 3.5.3-rc.1. I'm afraid to update because that was an ordeal last time that bricked some of my expansion boards updating in sbc mode.

p8blr

This code runs every line

M98 P"soundNotifyShort.g"   ; beep
G4 S1   ; wait
var myCounter1 = 5
while iterations <= 5
    M98 P"promptUser.g" ; give user opportunity to cancel
    if global.userPrompt == 1
        break
    G4 S1
M98 P"soundAlert.g"    ; beep
M291 P"end of code" S2

This code skips the lines after the while loop

M98 P"soundNotifyShort.g"   ; beep
M42 P17 S1  ; set closing direction
G4 S1   ; wait
while sensors.gpIn[15].value == 1   ; while not fully closed yet
    M42 P16 S1  ; turn on motor
    M98 P"promptUser.g" ; give user opportunity to cancel
    if global.userPrompt == 1
        break
    G4 S1
M42 P16 S0  ; turn off motor
M98 P"soundAlert.g" ; beep
M291 "Top cover is at max closed" S2

droftarts

@p8blr Try putting in an M400 after the while loop. RRF 3.5 made changes to how things run, due to multiple motion streams, and M400 causes everything to resynchronise. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems.

Also, please update to 3.5.3. This might be resolved already. I doubt you'll have the issues when updating, 3.5.3 has been pretty stable. We don't support beta and rc releases once the main release has released.

Ian

p8blr

@droftarts I updated to 3.5.3 and tested the code but no change, I then added a M400 like this below, and it still did not run the last few lines of code, line 11 & 12.

M98 P"soundNotifyShort.g"   ; beep
M42 P17 S1  ; set closing direction
G4 S1   ; wait
while sensors.gpIn[15].value == 1   ; while not fully closed yet
    M42 P16 S1  ; turn on motor
    M98 P"promptUser.g" ; give user opportunity to cancel
    if global.userPrompt == 1
        break
    G4 S1
M400
M42 P16 S0  ; turn off motor
M98 P"soundAlert.g" ; beep
M291 "Top cover is at max closed" S2

droftarts

@p8blr You probably need @dc42 to have a look at this to figure out what's going wrong.

Ian

dc42

@p8blr your promptuser.g file includes this M291 command:

M291 P"Continue?" S4 T3 J1 K{"Yes", "No"} F0

If that message box times out then it will abort the macro that it occurs in and any containing macros. I suspect that is why the containing macro does not complete.

There is already a request for a feature to allow the behaviour on timeout to be changed.

p8blr

@dc42 Interesting. Any idea on an estimated completion date on the feature request? Or maybe a workaround I could do instead? I want the user to be able to have a way out of a very long while loop.

Thanks.

droftarts

@p8blr said in Duet not consistently running code:

@dc42 Interesting. Any idea on an estimated completion date on the feature request? Or maybe a workaround I could do instead?

See https://github.com/Duet3D/RepRapFirmware/issues/959

Scheduled for “after 3.6.0”.

Ian

benagricola created this issue in Duet3D/RepRapFirmware

Duet not consistently running code

open [FeatureRequest]: Allow `M291` to set `result` to `-1` when blocking modal "Cancel" clicked. #959