Secondary Tool move breaks Z homing

Phaedrux

Why do you have this at the end of homeZ?

G1 H1 Z0 F500

It's an endstop seeking move with no distance.

optical

If you remenber from the video the PNP head has two heads which are moving in oposite direction to each other. The last G1 H1 Z0 F500 endstop seeking move is there to prevent damage to pnp nozzles when the homing sequence fails, due to the limit switch miss detection.

dc42

I have viewed your video and I have some questions:

Which axis moves the gear wheel, that moves one tool up and the other down?
Where is the inductive sensor?

dc42

I have replicated your setup as best I can, and I can't reproduce the fault. I used RRF 3.2beta4.1. I didn't have an inductive sensor so I used an IR sensor instead. I tried that sequence multiple times, but each time the final Z homing operation move in the correct direction until I triggered the sensor.

I can see a few possible reasons why the electronics might see the board as triggered:

It might really be triggered. Is there an LED on the inductive sensor, so that you can tell whether it is triggered or not?
If the output wire of the inductive sensor runs close to the stepper motor cable for the V axis, then it might pick up noise from the stepper motor cable when the V axis is energised. The inputs of the Duet MB6HC have a 27K pullup resistor to +5V, and if it is an NPN sensor then it will be relying on that pullup resistor to pull the output high when the sensor is not triggered.To prevent noise triggering the sensor, you could add an external pullup resistor in the range 1K to 10K between the IO0_IN and +5V on the IO0_IN connector.
IO0 used to be reserved for connecting a PanelDue. That limitation was lifted in firmware 3.1, so as you don't have a M575 command in config.g to enable the serial port on IO0, using IO0 for your inductive sensor should work. However, you might like to try using IO2 or higher instead, just in case there is an obscure firmware issue that is affecting your system but not mine.

I suggest you test the effect of various tool 1 moves on the value read by the endstop input. To save you doing Z homing all the time, you can send the following command to read the input:

echo sensors.endstops[2].triggered

HTH David

optical

@dc42
1, Z axis moves the gear wheel.
2, It is behind the left tool(Nozzne) it is setup that it senser the linear carrige.

optical

@dc42
1, The led is off i checked it to ensure it is not triggered.
2, i wil give it a try this might be the cause of the issue, however the board is still reading not trigged even when the T1 is energenized. In past i checked the voltage with voltmeter. this time i will try to check it with osciloscope to ensure there is not some ripple there.
3, I have tested i previouse attempts to switch to different io with the same result. I will try it again.

echo sensors.endstops[2].triggered; Before T1 energized
false
echo sensors.endstops[2].triggered; After T1 energized
false

optical

After investigating with the Voltmeter it appears that the T1 energized pushes the voltages to lower level so i expect that the additional movement of the Z combined with the T1 energization pushes the level into active region.

I will try to add aditional pull up.

dc42

That's interesting! What voltages are lower with T1 energised?

optical

Voltage levels:
Idle(No motors energised): 4.12V
Z motor Energised: 4.12V
Z + T0: 4.06V
Z + T1: 3.60V

I have tried to add 3.9K pull up to 5V.
Which moved:
Z + T1: 3.6V -> 4.4V.

The interesting thing is that the voltage level is not lowering at least on my voltmeter. I would assume the voltmeter does not have the range to see the ripple causing the end stop to trigger.

If i disconnect the T1 motor the homing sequence finishes successfully. It must be the reason you specified with number 2.

optical

However it is a little bit strange that the movement of the Z motor would effect the endstop only when the T1 motor is energized and it is not moving.

dc42

Which voltage are you measuring that gives those reasons?

@optical said in Secondary Tool move breaks Z homing:

However it is a little bit strange that the movement of the Z motor would effect the endstop only when the T1 motor is energized and it is not moving.

It's not strange. The motor will still be energised after the move, unless you use M18 or M84 to de-energise it. As long as it is energised, the chopper in the driver chip will operate, and there will be 12-24V square wave at about 40kHz on all four stepper motor wires.

If the inductive sensor output runs in the same cable bundle as any stepper motor wires, then I suggest you use shielded cable for the inductive sensor output wire; or alternatively 2-core+shield cable to handle all three connections to the sensor.

optical

@dc42 do you think that low pass filter is also an option here ? For example with cut off 1khz ?

dc42

@optical said in Secondary Tool move breaks Z homing:

@dc42 do you think that low pass filter is also an option here ? For example with cut off 1khz ?

Yes, but there are better solutions. Do the sensor wires run in the same cable bundle as the wires to the stepper motor that is causing the problem? If so then I recommend you use shielded cable for either the sensor wires or the stepper motor wires, unless you can separate them.

optical

@dc42 So the problem is indeed that the endstop wires runs in the same wire bundle as the motor. I have temporarly solved the issue with low pass filter with cut off frequency 1Khz.

I'm currently working on having expansion boards and D-Sub cables which should ease my assembly of the Pick and Place machine. I will address this issue in the new revision of the cableing.

I'm deeply sorry for my lousy cableing which caused so much trouble. I wasn't expecting this issue because both two steppers didn't caused the issue.

Thank you very much for helping me find the issue in my machine.

dc42

I'm glad you solved it! Bear n mind that the Duet 3 has 27K pullup resistors on the inputs, so any low pass filter you add should have a low enough resistance so as not to affect the low-level voltage significantly. A 1nF capacitor connected between the input pin and ground would probably be sufficient, but then the output transistor in the NPN sensor will discharge this rapidly when it turns on. That is unlikely to harm the sensor, but if you want to avoid it then I suggest a series resistor in the range 100R to 1K between the sensor output and the capacitor/IOx_IN pin.