DWC beta 3.2-1 endstop status

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