Secondary Tool move breaks Z homing
-
Hi,
today i have been able to produce behavior to use the tools with axis mapping to remember their position.
I have changed the rotation to be represented by axis X(One nozzle). The other i have mapped to axis V to be able to use M563 to change driver mapping for Axis X.However, the issue with inverting axis is still present. This time right after homing.
G28 G28 ZNote: I think it would be nice to allow using M563 to remap any axis. Due to this limitation i had to move my X axis to be labeled as U. Which makes things rather messy.
G28 Z G28 V G28 Z ; FailesThis is the minimal usecase when the Z homing failes.
It is propable related to the way i'm homing the axis which does not have endstops and are infite(free-rotation).Could you help me maybe change the way i'm homing the rotation axis ? Is there Gcode which would just declare the axis as homed ?
Currently i set the stall detection to lowest value and move.
These axis can be homed in any position.The other possibility is that the Z axis breaks whenever the second tool/driver moves.
Configuration:
homeall.g config.g homez.g homey.g homex.g homev.g homeu.g -
@optical said in Secondary Tool move breaks Z homing:
Is there Gcode which would just declare the axis as homed ?
G92 will let you set the position of an axis.
https://duet3d.dozuki.com/Wiki/Gcode#Section_G92_Set_Position
-
I tested new homing scripts using G92 for the infinite axis. And i have come to conclusion that whenever the other drive(Currently V axis) moves. The Z axis homing becomes inverted.
-
After further testing it seems that somehow the input is inverted.
M574 Z2 P"!io0.in" S1Because the problem of the movement is "solved" not present when i remove the induction probe connector from the board.
Is it possible that switching from the probe endstop to sensorless endstop breaks the input ?After messing with the endstop settings. I think that really something is wrong with the input it self.
G28 T1 G1 X10 G28 Z ; Broken home M574 Z2 P"!io0.in" S1 G1 H1 Z+40 F500 ; stops immidiently even when sensor is not triggered M574 Z0 P"nil" G1 H1 Z+40 F500; Continues fine M574 Z2 P"!io0.in" S1 G1 H1 Z+40 F500 ; stops immidiently even when sensor is not triggeredI have tried to change io0 for io1. The issue is still present.
I have checked that the sensor is indeed working even when the problem with the io is present. -
Well the ! inverts the signal.
-
@Phaedrux Ofcourse it does the inversion is correct. The input works for the homing until the Tool 1 is moved then it stops working(propably gets inverted (uninverted)).
I'm suggesting that it is propably a bug inside the firmware. -
Post your gcode so we can see what's all going on.
-
-
Can you try add M400 before all of your instances of M913?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M913_Set_motor_percentage_of_normal_current
Important! When M913 is executed, it does not wait for all motion to stop first (unlike M906). This is so that it can be used in the M911 power fail script. When using M913 elsewhere, you will typically want to use M400 immediately before M913.
; Axis Limits M208 U-7.7 Y-39.2 Z-22.5 S1 ; set axis minima M208 U650 Y400 Z22.5 S0 ; set axis maxima M208 X-18000 V-18000 S1 ; set axis maxima M208 X18000 V18000 S0 ; set axis maximaCan you try condensing that into just two commands?
-
@dc42 Did you managed to reproduce this issue ?
-
@optical Did you try any of my suggestions?
-
@Phaedrux @dc42
My maching was unavailable due to some maintanance.Yes i hae tried your suggestion with M400. It did not work.
As i said i discovered in past comment that the issue is with the induction sensor on input pin. The pin stops reading correct value.The machine thinks that the sensor is always triggered after movement with Tool 1.
Is there some other way how to configure the endstop to stop this issue ?
-
May i ask if this is correct way of setting Endstop for Z axis, because the input just breaks on tool change. Is it possible that the machine starts to expect different endstop for its movements ?
M574 Z2 P"!io0.in" S1Homez:
; homez.g ; called to home the Z axis G91 ; relative positioning M400 M913 Z25 G1 H1 Z+40 F500 G1 H2 Z-5 F500 G1 H1 Z+5 F500 M400 M913 Z100 G90 ; absolute positioning G92 Z12 G1 Z0 F500; Park -
Yes that looks ok for a zmax endstop switch, but it depends on the kind of switch. NO or NC.
@optical said in Secondary Tool move breaks Z homing:
G1 H2 Z-5 F500
Remove the H2 on that move to back away from the switch.
-
@Phaedrux Keep in mind that the homing Z is working properly until i use commands:
T1 G0 X10After these commands the input sensor stops working. So it must be related to the movement of the second tool.
I think there has to be bug in the firmware. Otherwise the homing before the movement would be also faulty. -
@optical said in Secondary Tool move breaks Z homing:
the input sensor stops working.
Meaning the inductive probe? Does the switch also stop?
Sorry, I'm having a hard time visualizing what's all going on. Can you post a video showing step by step what's happening?
-
-
Your video link is private.
-
@Phaedrux I have edited the post to make it public.
-
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 X10Does 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?
