Secondary Tool move breaks Z homing

optical

@Phaedrux I have edited the post to make it public.

Phaedrux

Thanks.

Ok, so just to clarify what I'm seeing. The left head does the G28 Z it goes down, triggers, backs up, and goes down again. T1 is sent, it switches to the right head, G0 X150 is sent to make it spin and then G28Z is send again but this time the Z endstop is already triggered at the start of the move.

@optical said in Secondary Tool move breaks Z homing:

G92 Z12

Where does this value come from?

@optical said in Secondary Tool move breaks Z homing:

G1 H2 Z-5 F500

Did you remove that H2?

@optical said in Secondary Tool move breaks Z homing:

homing Z is working properly until i use commands:
T1 G0 X10

Does the behaviour change if you don't also send the G0 X10 command? Does it behave different if you send G1 X10 instead?

What are you using for the Z endstop now? Is it still a probe or is it a simple switch?

Phaedrux

@optical said in Secondary Tool move breaks Z homing:

I do not have any tool change files tfree0.g, tpre0.g and tpost0.g in /sys on the SD card

Could you try creating them? Even if they are empty.

Phaedrux

Can you also post your config.g as it currently stands.

optical

I have created empty files:
tfree0.g, tpre0.g and tpost0.g
tfree1.g, tpre1.g and tpost1.g
The issue still persists
My current config is
config.g
homez.g

Phaedrux

@optical said in Secondary Tool move breaks Z homing:

G92 Z12

Where does the Z12 come from?

optical

This is because the Z Axis has to have 0 coordinate in the neutral position. When the nozzles are at the same height. The induction probe is not all the way at the end of the heads movement range.

Or do you have some other idea how to tell the board that the end switch is not at maximum or minimum coordinate?

optical

@Phaedrux Do you think that the issue is the G92 code to set the position ?
@dc42 You mention testing the configuration on you test gig at the office. Is it possible that you have a look at it ? It seems that the gcode configuration is not an issue here.

optical

This post is deleted!

optical

@Phaedrux @dc42
I have found that there is M119 Command to report endstop states so i made the test where the Z endstop stops working.

alt text Image upload does not work...

It shows that the M119 state does not change when the endstop stops working. There must be some kind of mapping associated with the tool changing.

The reason why i think the endstop is not working is that when i disconnect the probe for the expected broken homing the head is behaving as the switch is open.
However when connected for the expected broken homing it reads it as closed.
(Open, Closed in terms of active switch not the voltage level.)

When the machine is in the broken state when i activate the switch manually the M119 reports correctly that it is stopped.

Endstops - X: not stopped, Y: not stopped, Z: at max stop, U: not stopped, V: not stopped, Z probe: at min stop

There must be some kind of issue in move command that it is checking wrong input or something. After the tool change

Phaedrux

Sorry for the lapse in replies. Was not intentional.

And that's still with empty tool change files?

optical

@Phaedrux Yes

dc42

@optical

Is your config.g file still exactly as you posted it at the star of this thread? If not, then please post it here again.
What is the current minimal set of operations to reproduce the problem?

optical

@dc42 Thank you for you valuable time
Latest configuration files with homing files needed.
homez.g homex.g homev.g config.g

Minimal set of gcode to reproduce the problem.

G28 X ;
G28 V ;
G28 Z ; Homing works fine multiple times
G28 Z ; Works

T1 
G0 X200 ; Move with secondary tool

G28 Z ; Does not work. Detects the induction endstop immidietly eventhough it is not triggered

Earlier i have posted video showing the problem for better undestanding the procedure visualy: Video

Phaedrux

I don't think this is the problem here, but I noticed you've got double values for your Y axis which are not needed. It's only extruders that you would need to define the values per extruder motor.

M584 U2 Y0:1 Z5 X4 V3                                            ; set drive mapping
M350 U32 Y32:32 Z4 X32 V32 I1                                    ; configure microstepping with interpolation
M92 U213.248243767313 Y213.248243767313:213.248243767313 Z20.21 X17.777 V17.777          ; set steps per mm
M566 U200.00 Y200.00 Z900.00 X900.00 V900.00                     ; set maximum instantaneous speed changes (mm/min)
M203 U50000 Y30000:Y30000             ; set maximum speeds (mm/min)
M203 Z5000.00 X5000 V5000             ; set maximum speeds (mm/min)
M201 U5000.00 Y3000.00:3000.00 Z2000.00 X2000 V2000              ; set accelerations (mm/s^2)
M906 U2800 Y2800:2800

Remove the duplicate values for Y. In fact this one would probably provoke an error message M203 U50000 Y30000:Y30000

Send M98 P"config.g" to check for any syntax error messages.

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.