Need help with homing XYUV and conditional gcode

deckingman

I use two gantries. XY carries the hot end. UV sits above XY and carries 6 extruders plus 2 expansion boards. There are 6 Bowden tubes from the hot end to the extruders plus numerous wires from the hot end and XY gantry to the expansion boards. Therefore XYU and V must always move in sync but there is some positional "tolerance" due to flex in the Bowden tubes and wires.

So homing X and U must be done together, (as must Y and V). Therefore the first move for XY is:
G1 X-380 U-380 F4800 H1; move X and U together until one or other switch triggers.

After which, each individual axis is homed independently. This is all fine and dandy and has been working well for a couple of years or more.

However, the other day I was working on the machine and had disconnected the X end stop and forgot to reconnect it. So when I tried to home the printer, that first X&U move didn't happen because the X end stop switch was already triggered (they are normally closed switches). The homing macro then tried to home each individual axis but because both gantries were near the centre of the bed, it didn't go well. After straightening everything out and fixing the torn out wiring, it occurred to me that this could happen if ever a switch fails or a wire breaks.

So what I need to do is check the end stop status at the start of homing and if either X or U are already triggered, abort the rest of the homing macro and display a message.

I guess I could do this with conditional gcode if I was clever enough and/or had the time to learn but I'm not/don't have, hence the request for help.

EDIT. Thinking about it a bit more, I guess an elegant solution would be to have a macro which checked the status of all end steps, which could be called at the start of any homing macro, but I'm open to suggestions.

T3P3Tony

Hi Ian

suggestion from @chrishamm

if sensors.endstops[x].triggered || sensors.endstops[y].triggered
  abort "Endstops already triggered at the beginning of the homing move, aborting"

would need expanding for all the endstops you wanted to check

arhi

IMHO the "abort if already.." is the best course of action. Will not help if the switch/cable die during the home move but I think that's an acceptable risk.

A Former User

This post is deleted!

deckingman

@T3P3Tony said in Need help with homing XYUV and conditional gcode:

Hi Ian

suggestion from @chrishamm
if sensors.endstops[x].triggered || sensors.endstops[y].triggered
  abort "Endstops already triggered at the beginning of the homing move, aborting"
would need expanding for all the endstops you wanted to check

Hi Tony,

Thanks for that. Could you confirm what I suspect the "abort" does? I assume that if the above command (with X and U end stops) was at the start of my home all macro, it would abort that home all macro yes? If I had a similar command later in the macro file but with Y and V as the end stops, I assume that XU will home but then the rest of the macro would terminate if either a Y or V endstop is already triggered yes?

Edit. Scratch that - just found a description of the "abort" command.

deckingman

I've tried the above suggestion - i.e .......................

if sensors.endstops[x].triggered

.............and I get an error message:

Error: in file macro line 18 column 21 : meta command : unknown value 'x'.

I tried both upper and lower case "x".

chrishamm

@deckingman x and y must be replaced with the indices of your endstop (first item is 0, second 1 etc). You can send M409 K"sensors.endstops" to view the current list and states.

deckingman

@chrishamm said in Need help with homing XYUV and conditional gcode:

@deckingman x and y must be replaced with the indices of your endstop (first item is 0, second 1 etc). You can send M409 K"sensors.endstops" to view the current list and states.

Ahh - thanks for that.

deckingman

~~So I just sent M409 K "sensors.endstops" and got~~

~~Error M409 : expected string expression.~~

Scratch that. I discovered that one must not have a space after the K

deckingman

This M409 isn't very helpful. It just lists the status (true or false) for all the end stops but it doesn't say which end stop is associated with which axis.

deckingman

Other than using DWC to show the end stops, then triggering each one by hand and looking to see which one changes state, is there any other way to know which index value is assigned to which axis?

It isn't the order that they are created in config.g because I created XYUVAB and finally Z in that order but Z is index number 2. I haven't been able to find anything in the documentation but it might be buried in there somewhere.

deckingman

Well that was fun. For anyone else stumbling across this thread, the only way I could discover which end stop index value refers to which axis was to use DWC to display the end stops under machine properties. Here the end stops are listed by index value rather than by axis letter, along with their trigger status. So I had to trigger each one in turn and revert to pen and paper to record which index is assigned to which axis.

It would be helpful if someone who knows how end stop incises are assigned to axes could add that to the documentation somewhere.

I ended up using separate statement for each end stop so that I got a meaningful message about which end stop to check. i.e.......

;****check if an enstop is alreday triggered becuase it might be a wire has fallen off
; X=0,Y=1,Z=2,U=3,V=4,A=5,B=6

if sensors.endstops[1].triggered 
	abort "Y endstop already triggered at the beginning of the homing move - aborting" 
if sensors.endstops[4].triggered 
	abort "V endstop already triggered at the beginning of the homing move - aborting"

OwenD

@deckingman said in Need help with homing XYUV and conditional gcode:

EDIT. Thinking about it a bit more, I guess an elegant solution would be to have a macro which checked the status of all end steps, which could be called at the start of any homing macro, but I'm open to suggestions.

You can iterate over all endstops (or other arrays) by using # to give you the number available

while iterations < #sensors.endstops
	if sensors.endstops[iterations].triggered
		echo "Endstop " ^ iterations " is triggered"
		abort

I had thought maybe this could be expanded to try to move away from any active endstop which would effectively test if it was broken (i.e. if it's still active after a 6mm move it's broken), but I can't see an easy way in the object model to determine if the endstop is at min/max or whether it's N/O or N/C.
Nor does it seem possible to determine the axis it is associated with other than to assume the endstop number would align with the axes number.
But if you had two endstops on an axes that'd fail.