DRO not counting for JOINT_4

Hi tommieh / cmorley,

I ran into comparable issues running the qtdragon screen (which, looking at the code are reproducable for qtdragon_hd and woodpecker)
I have configured linux cnc in a gantry config, having 2 joints assigned to the Y-axis. This is causing issues as joint 2 is assigned to my y-axis and not the z-axis as is assumed by the hardcoded joint numbers in the screens. The result for me is an error when homing the z-axis standalone (home all does work fine).
I fixed this issue by making 2 changes:
- Dynamically assigning the correct joints to the elements on screen.
- fixing the assignment of GET_JOINT_NUM_FROM_AXIS_INDEX in the INFO library (the 2nd joint was assigned to Axis Y but when looking up the Axis assigned to that joint, Axis Y2 is returned)

to fix this (for my specific case!) I changed the following:
In the qtdragon_handler.py file, I changed the init_widgets method and added the below code after line 230 (this is the 2.8.1 release) :
The last 3 commented out lines of code change other elements in the screen with a reference to the joint number. I did not test these changes and for now stuff appears to be working without the changes so I applied the "dont fix it if it aint broken" methodology but maybe the author of the qtdragon screen can check this out. I'll try to do some more testing to see if I can break stuff.

To fix the INFO library, I made changes to qt_istat.py file in /usr/lib/python2.7/dist-packages/qtvcp directory (again, 2.8.1 release of linuxcnc). To prevent the assignment of joint 1 to axis y to be overwritten, I added a check in the code. If a joint has already been assigned an axis, the the code no longer overwrites this with the 2nd joint parsed. I understand this change is arbitrary. Both options are technically correct (in my case, both joint 1 and joint 2 are assigned to axis Y), however, making the change here seems the more logical place, as this code is created to be used by the dro_widget (at least, reading the comments, it appears to be).
An alternative is to change the btn_home_clicked method in qtdragon_handler.py to handle these cases. I however choose this method.
The below code can be found from line 157 and onwards in the qt_istat.py file. I added the last if statement (if not int(axisnum) in self.GET_JOINT_NUM_FROM_AXIS_INDEX:)

Hope someone can pick these changes up and have a look at them. If needed, I could make a pull request. Would have to figure out how that works though .

Just realized I left a print statement in the first code block (5th line). Very sloppy. If someone copies/pasts this code, do remove the print statement. It doesn't add anything..

Was the original problem that the wrong joint was homing? was the wrong joint displayed in the DRO?

can you post your modified handler file or show some surrounding code - the handler file has changed a fair amount line 230 is in the middle of the preference function.

The original problem was an error message where if I recall correctly, the code tried to access the dro_axis_y2 object, which doesn't exist. I'm at work now (working from my home office, like so many others nowadays), so can't spend a lot of time, hence the quick reply only. When I'm off, I'll send a copy of the changed files. I'll have to get them from my cnc, which isn't running right now. (i Still have to get used to the whole git world and only make code changes in your local git repo . I'm old scool and make changes in PROD )

Hi Cmorley,

I have attached both changed files:
qtdragon_handler.py -> Changes are starting at line 230.
qt_istat.py -> actual changed lines are 165,166

The change to qt_istat.py changes the behavior of building the INFO object in the INFO library.
Instead of : ('GET_JOINT_NUM_FROM_AXIS_INDEX is:', {0: 0, 1: 2 ,2: 3})
it will result in : ('GET_JOINT_NUM_FROM_AXIS_INDEX is:', {0: 0, 1: 1, 2: 3})
in the case of having 3 axes and 4 joints,
Joint 0 assigned to X,
joint 1 and 2 assigned to Y
and joint 3 assigned to Z.

This was needed as the btn_home_clicked method in the qtdragon_handler used the joint number to lookup the axis and created a dynamic reference to a UI element using that axis. If the wrong joint was populated, it would in my case find an axis named y2. This would result in a lookup for 'dro_axis_y2' which doesn't exist.
The fix in qtdragon_handler.py made sure the correct values are populated in the joint property of the button, based on the data made available in he INFO object (instead of relying on hard coding). The fix in the qt_istat.py made sure the right data was available in that object.

And, don't forget, this most likely also is valid for the qtdragon_hd and woodpecker screens. I see large parts of code copied between them and the btn_home_clicked method is one of those parts .

Thanks for the update and explination.
I have to figure out why the sample configs with gantry axes didn't error, but yours did.

If you want to compare my setup with the sample configurations then have a peek. I've attached all my config. I wouldn't be surprised if I made some shortcuts which ended up resulting in what I got