DWC beta 3.2-1 endstop status

deckingman

@Phaedrux It came about when I discovered that if a normally closed switch fails, or if a wire falls off, then when homing a particular axis, it will get flagged as homed at the start of the homing macro, before any movement takes place. So for example the X axis could be flagged as homed and the zero position set, when in fact the gantry is in the centre of the build plate (or any other position). To get around that, I wrote macros (with help from forum members) to detect if the endstop was already triggered at the very beginning and abort if that was the case. For that to work, I needed to know the index value of the endstop in question (for each of the axes).

dc42

@deckingman said in DWC beta 3.2-1 endstop status:

@Phaedrux Expanding on this, I have another as yet unanswered question. Can someone explain how end stops are assigned to axes? What I mean by that is that endstops are assigned an index but how can one determine which endstop index is assigned to which axis. For simple 3 axis single endstop machines it's easy - X is 0, Y is 1, Z is 2. But in my case, I also have UVA and B. Other users might have multiple end stops e.g 2 end stops on the X axis. The only way I've been able to determine the index to axis relationship is to physically trigger each switch and observe which endstop index changes state, then write to this out as a table for future reference. If endstops are not shown in DWC, that will render that method impossible. So an alternative way of deducing which index value is assigned to which axis (or which end of an axis where multiple endstops are used) is needed. I haven't been able to determine a logical relationship but one must exist.

I suspect the answer is that the display of endstop input states in DWC 3.1 was quite primitive and it needs to be reworked to use the object model. However, once that is done, the endstops will be listed by axis# and motor# because that is what the OM provides. So you should no longer need to work out the mapping between endstop index and axis/motor.

deckingman

@dc42 said in DWC beta 3.2-1 endstop status:

I suspect the answer is that the display of endstop input states in DWC 3.1 was quite primitive and it needs to be reworked to use the object model. However, once that is done, the endstops will be listed by axis# and motor# because that is what the OM provides. So you should no longer need to work out the mapping between endstop index and axis/motor.

Err yes but ..........ideally we need both the endstop index number and the axis/motor to which it is assigned to be displayed - or if not some mechanism whereby the endstop index for a particular axis/motor can be determined. The usage case is as I described - i.e. when writing conditional gcode macros for (say) homing files which are axis specific, but for which one needs to know the endstop index which is associated with that axis.

By way of illustration, I have this at the start of my homeu.g macro.

if sensors.endstops[3].triggered 
	abort "U endstop already triggered at the beginning of the homing move - aborting"

So one needs a mechanism to determine which endstop index (in this case it was [3]) is associated with which axis (in this case it was U) in order to write that command.

dc42

@deckingman said in DWC beta 3.2-1 endstop status:

So one needs a mechanism to determine which endstop index (in this case it was [3]) is associated with which axis (in this case it was U) in order to write that command.

"sensors.endstops[]" is indexed by axis number. So, if the first additional axis you create using M584 is U, then "sensors.endstops[3]" will be the endstop for the U axis, because indices 0,1,2 are X,Y,Z. Also, "move.axes[3].letter" will equal "U".

I appreciate that this is neither obvious nor documented! Maybe we need a function to map axis letter to axis number. Also, in the case of multiple endstops for an axis, the individual endstop states are not reported.

deckingman

@dc42 Thanks - that helps a bit. I suspected that the index would be incremented by something, but wasn't sure if it was the order that axes are created in M584 (as it seems is the case) or the order that endstops are created using M574 (which is equally logical). As long as it's documented somewhere will save any future confusion.

The only thing that I'm still not clear on is the endstop index values for axes that have multiple motors and end stops. So in the case of (say) M584 Xn:n Yn Zn (2 X motors and end stops) is it fair to say that sensors.endstops[0] and [1) would be the two X axis endstops, [2) would be the Y axis and [3) would be the Z axis?

dc42

@deckingman said in DWC beta 3.2-1 endstop status:

The only thing that I'm still not clear on is the endstop index values for axes that have multiple motors and end stops. So in the case of (say) M584 Xn:n Yn Zn (2 X motors and end stops) is it fair to say that sensors.endstops[0] and [1) would be the two X axis endstops, [2) would be the Y axis and [3) would be the Z axis?

No, sensors.endstops[0] would report triggered if either X endstop is triggered (the same as M119). That part of the OM needs to be expanded to report the individual X endstops.

deckingman

@dc42 thanks - I think it is clear now.

One more quick question to be absolutely sure. Is it fair to say that the index value for end stops is derived from the order in which additional axes are defined in the M584 command? So in my case the axes are defined in the order M584 Xn,Yn,Zn Un,Vn,An and Bn and the respective index values are X=0, Y=1, Z=2, U=3, V=4, A=5 and B=6. But if my M584 had been Xn, Yn, Zn, An, Bn, Un and Vn then the end stop indexes would become X=0, Y=1, Z=2 A=3, B=4, U=5 and Y=6 yes?

dc42

Almost right. When processing M584, RRF looks for axis letters in the order UVWABCD. So if you create several axes in a single M584 command, they will be allocated axis numbers in that order. For example, M584 C1.0 A1.1 W1.2 U2.0 would create axes in order UWAC, so you would get U=3 W=4 A=5 C=6. However, if you created each axis in a separate M584 command, then they would be allocated numbers in the order that you created them.

dc42

PS - you can check it with this macro:

while iterations < #move.axes
  echo "Axis", iterations, "is",move.axes[iterations].letter

deckingman

@dc42 Thanks. For the benefit of others in the future, it'd be good if @droftarts or someone could get this into the documentation (including your useful checking macro).

FolsomMike65

@dc42

Has any improvement been made on this issue?

A "primitive" but very useful function was replaced with...nothing?

I can't even find a reference to the "object model browser" on the DWC user manual page.

Phaedrux

@folsommike65 It's a plugin now. Probably included with 3.3

https://github.com/Duet3D/DSF-Plugins/tree/master/EndstopsMonitor