if condition RFF3 on GPIO Pin

OwenD

@sylvain You can use tabs or spaces, but it will complain if you use both.
I think as @RS said, it could be timing.
What happens if you put M400 in before the IF statement?

duetlover

So :
I well indented with tabs.
I had M400 before if condition.

Random issue is still here. I would say that with these updates, wrong fails are more important than before

Thanks

dc42

I've added this to my list to look at. I hadn't considered using the abort command in a tool change file.

To confirm, after the G1 command that parks the tool, you will need to use M400 or G4 Pxx to ensure that the movement completes before testing the switch. If the switch is connected to a Duet 3 expansion board then there may be a latency of a millisecond or so before the new switch status is available on the main board, so a G4 command to delay a few milliseconds would be advisable.

duetlover

Hi

I tried :
G4 S1
M400

No better results.

Best regards

Sylvain

RS

@sylvain: am I right to assume that moving the print head towards the tool and actuating the grabber is done is tpreX.g?

If I were to debug this issue, I think I would write a gcode file that would simulate tool changes in a while loop, without activating/deactivating the tool. That would take some of the variables out of the game (e.g. the tool-switching logic in the firmware).

The gcode would look like this:

while iteration < 500; you may want to play around with this
  G0 ... ; move print head towards the tool
  ; grab the tool
  M400
  G4 S1
  ; check if microswitch was triggered and abort if not
  G0 ... ; move away from the tool holder
  G0 ... ; move back to the tool holder
  ; release the tool
  G0 ... ; move away from the tool holder

Try to get this as close as possible to your current setup, then let it run for a while. If this doesn't cause aborts any more, then the error is somehow related to the tool changing configuration. If it still fails, then at least we know it's not related to tool changing.

Divide and conquer

dc42

I am looking into this, and in the first instance it's a specification issue:

If the tfree file aborts:

Should the whole tool change be cancelled?
What state should RRF assume the machine is in: old tool still loaded, or no tool loaded, or something else?

Similarly if the tpre or tpost file aborts.

RRF does not currently have any concept of a tool change failing.

RS

@dc42: That's certainly useful to look into. I really like the idea of verifying a successful tool lock before moving away and potentially dropping the tool on the bed.

But as I understand it, @sylvain has more issues than an undefined state after the abort. The abort occurs because the microswitch is not recognized as pressed, even though it apparently is, and right now he has no idea why that happens.

Do you think that could also have something to do with the tool change procedure?

Of course, once that's resolved, there's still the specification issue you've mentioned.

duetlover

@RS said in if condition RFF3 on GPIO Pin:

@dc42: That's certainly useful to look into. I really like the idea of verifying a successful tool lock before moving away and potentially dropping the tool on the bed.

But as I understand it, @sylvain has more issues than an undefined state after the abort. The abort occurs because the microswitch is not recognized as pressed, even though it apparently is, and right now he has no idea why that happens.

Do you think that could also have something to do with the tool change procedure?

Of course, once that's resolved, there's still the specification issue you've mentioned.

In fact, at the moment the problem is the random answer of if condition. Sometimes it works, sometimes not...

To be sure this is not a connector issue, I deleted the last connector possible, soldered the wires => same issue !

So, yes, my real problem at the moment is this randoming process.

@dc42 : I'm working on tpost, not tfree

example with tpost :

; tpost0.g
; called after tool 0 has been selected

;heatup
M116 P0

;prime nozzle
;M98 Pprime.g

;mesh levelling on
G29 S1

;PCF fan on
M106 P2 S255


M400
G4 P500

if sensors.gpIn[0].value = 0  ;if the microswitch is not pressed...
	abort "Failed to grab tool 0"
; end if

duetlover

I also tried with if condition at the beginning without success :

; tpost0.g
; called after tool 0 has been selected

M400
G4 P500

if sensors.gpIn[0].value = 0  ;if the microswitch is not pressed...
	abort "Failed to grab tool 0"

;heatup
M116 P0

;prime nozzle
;M98 Pprime.g

;mesh levelling on
G29 S1

;PCF fan on
M106 P2 S255

Same random behaviour

RS

Could you also post your tpre0.g file?

duetlover

Here it is :

; tpre0.g
; called before tool 0 is selected

;Ensure no tool is selected
;T-1

if sensors.gpIn[0].value = 1  ;if the microswitch is pressed...
    abort "Tool 0 still mounted"


;Unlock Coupler
M98 P/macros/Coupler - Unlock

;Move to location
G1 X-10.5 Y200 F50000

;Move in
G1 X-10.5 Y230 F50000

;Collect
G1 X-10.5 Y242.5 F2500

;Close Coupler
M98 P/macros/Coupler - Lock

;WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
;if you are using non-standard length hotends ensure the bed is lowered enough BEFORE undocking the tool!
G91
G1 Z10 F1000
G90

;Move Out
G1 X-10.5 Y150 F4000

RS

Hm. The whole sequence of movements, plus M400 and G4, looks good to me.

Maybe double and triple check that the microswitch is really pressed correctly every single time? Or check if the cable from the switch to the boards runs close to other cables, where it could pick up noise. No idea how sensitive it would be to noise, but checking it and trying to move it away from other cables can't hurt.

Besides that, I have no more ideas than what I've suggested earlier: try writing a gcode file that simulates the tool change without actually invoking the T command. Just grab the tool, then release it again, in a while loop, and see what happens. In my experience, having a minimal example that reproduces the issue often helps.

dc42

When it fails to detect that the tool has been picked up, if you query the switch position using an echo command or M409, does it report the correct switch state?

duetlover

@dc42 I will echo just before and just after condition test

How should I write it ?
just:

echo sensors.gpIn[0].value

?
Thanks

dc42

Yes, that should work.

duetlover

@dc42 So when it fails the echo command says 0. No problem here

I finally change NO switch to NC one and now it seems to be OK !

Thanks for your help.

jwalker55

@dc42 Is it possible to read a sensor value twice within a single macro? For example, check the state of a switch at the beginning of tpre, then again at the end after the move out? When I do this (just by echoing to console) it outputs the state the switch was in when the macro started (or whenever the sensor was first read in the macro) for both instances despite the switch being pressed at the beginning and unpressed at the end. Aside from that it seems to work as expected if i'm only reading the sensor once.

A Former User

@jwalker55 maybe post your actual files in a new topic? sounds like it should work if the testing is done in the same file as the move is made.

jwalker55

Adding a short (10ms) pause using G4 prior to the second sensor reading seemed to fix it.

dc42

Alternatively you could have added M400 after the movement commands and before reading the switch again, so that the macro waited until the movement completed.