Duet3 + 3HC Dual Y-Axis CAN Problem

dc42

I have not been able to reproduce this issue on my bench setup. I think this is because it is sensitive to timing, and I am not able to operate the endstop switches by hand as quickly as they are activated in your printer. Additionally, my bench setup uses normally-closed endstop switches, so I had to change the M574 command to accept active high inputs.

What type of endstop switches are they? They appear to have active low outputs. If they are plain microswitches, then you appear to be using the normally-open (NO) contacts. I recommend you use the NC contacts instead (and then remove the leading ! from the pin names in the M574 commands) because this will make them less sensitive to noise pickup. This does not apply if you are using the Makerbot-style endstop switches with resistors and LED mounted on a small PCB.

The firmware checks the endstops prior to starting a G1 H1 move, and also during the move. I have identified that there may be a small time window while the move is starting during which a transition on a remote endstop input might not be recognised. It is possible that your machine configuration and homing files are resulting in the endstop transition occurring during this window. If that is the case, we should be able to work around the problem by adjusting the homey.g file. Currently you use:

G1 H1 Y550 F5000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F6000 ; go back a few mm
G1 H1 Y455 F360 ; move slowly to Y axis endstop once more (second pass)

Please try the following changes, individually:

Replace F6000 in the second line by a lower speed, for example F360
Replace Y-5 in the second line by a larger value, for example Y-10
Between the second and third lines, insert a new line: G4 P100

CR3D

@dc42 Thank you for your answer!

I use NPN inductive sensors on all axes.

I will test the changes in my homey.g file and give you feedback!

dc42

@CR3D said in Duet3 + 3HC Dual Y-Axis CAN Problem:

I use NPN inductive sensors on all axes.

Thanks. An inductive sensor should provide a clean transition. However, when it is not triggered the sensor is essentially open circuit, so the endstop input is held high only by the 27K pullup resistor in the Duet. So the wire connecting it to the Duet endstop input may pick up noise, especially if it is an unshielded cable and it runs close to a stepper motor wire.

I recommend that you you use shielded cable for these wires. Another possibility is to connect a lower value pullup resistor between the IN and +5V pins of the endstop IO_x connector.

CR3D

I tested the changes at the homey.g file

here the new one:

; homey.g
; called to home the Y axis
;
G91              ; relative positioning
G1 H2 Z5 F6000  ; lift Z relative to current position
G1 H1 Y550 F5000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-10 F360  ; go back a few mm
G4 P100
G1 H1 Y455 F360  ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000  ; lower Z again
G90              ; absolute positioning

unfortunately, this change did not help either.

dc42

Thanks. With that Y homing file, I can reproduce the problem - probably because I no longer need to release the Y endstop switch as quickly as I needed to using your original file. I will investigate it tomorrow.

PS - I can see what is happening. When the firmware executes the second G1 H1 move, which involves only stepper drivers connected to the expansion board, it doesn't wait for that move to complete before scheduling the next move - and in scheduling the next move, it disables the endstop.

dc42

I'm on the way to solving this, but meanwhile I have a temporary workaround. Between every pair of G1 H1/H2 moves that involve only drivers on the expansion board, insert a move that involves a motor on the main board. For example, this works for me:

; homey.g
; called to home the Y axis
;
G91              ; relative positioning
G1 H2 Z5 F6000  ; lift Z relative to current position
G1 H1 Y550 F5000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Z0.1
G1 H2 Y-10 F360  ; go back a few mm
G1 H2 Z-0.1
G1 H1 Y50 F360  ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z0.1
G1 H2 Y-10
G1 H2 Z-5.1 F6000  ; lower Z again
G90              ; absolute positioning

dc42

This is getting strange! The problem goes away if I reduce the length of the second homing move slightly, or I increase the speed of that move slightly. For example, this homing file fails:

; homey.g
; called to home the Y axis
;
G91              ; relative positioning
G1 H2 Z5 F6000  ; lift Z relative to current position
G1 H1 Y550 F5000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-10 F360  ; go back a few mm
G1 H1 Y455 F360  ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000  ; lower Z again
G90              ; absolute positioning

but it works if I reduce Y455 in the second G1 H1 line to Y450, or if I increase F360 to F361.

dc42

Found it! It was a subtle timing issue. Fixed firmware build at https://www.dropbox.com/s/p28vp6fbnkc4rbz/Duet3Firmware_MB6HC.bin?dl=0.

deckingman

@dc42 said in Duet3 + 3HC Dual Y-Axis CAN Problem:

Found it! It was a subtle timing issue. Fixed firmware build at https://www.dropbox.com/s/p28vp6fbnkc4rbz/Duet3Firmware_MB6HC.bin?dl=0.

@dc42 Might that be the reason why my Z homing switch doesn't work at 600mm/min minute but works fine at 300mm/min (yet XY and U all work at 1200 mm/min+) as per this thread https://forum.duet3d.com/topic/17404/z-switch-on-expansion-board-latency-issue/20

dc42

It might be if your Z drivers are not on the main board.

CR3D

Ok thank you very much! I will test it

CR3D

sensational david ... you did it!

thank you for this !!!!

Now it works...