DRO not counting for JOINT_4
05 Apr 2021 10:00 #204871
by marks
Replied by marks on topic 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
.
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) :
# assign correct joint to the btn_home_{} button
for num, axis in enumerate(INFO.AVAILABLE_AXES):
axis_index = "XYZABCUVW".index(axis)
joint_number = INFO.GET_JOINT_NUM_FROM_AXIS_INDEX[int(axis_index)]
print ("working on axis %s, joint will be %d, index was %d" %(axis, joint_number,axis_index))
self.w["btn_home_{}".format(axis.lower())].setProperty("joint", joint_number)
#self.w["action_zero_{}".format(axis.lower())].setProperty("joint", joint_number)
#self.w["dro_axis_{}".format(axis.lower())].setProperty("Qjoint_number", joint_number)
#self.w["axistoolbutton_{}".format(axis.lower())].setProperty("joint", joint_number)
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:)
# convert joint number to axis index
# used by dro_widget
self.GET_AXIS_INDEX_FROM_JOINT_NUM = {}
self.GET_JOINT_NUM_FROM_AXIS_INDEX = {}
for i in self.AVAILABLE_JOINTS:
let = self.GET_NAME_FROM_JOINT[i][0]
axisnum = "XYZABCUVW".index(let)
self.GET_AXIS_INDEX_FROM_JOINT_NUM[int(i)] = int(axisnum)
if not int(axisnum) in self.GET_JOINT_NUM_FROM_AXIS_INDEX:
self.GET_JOINT_NUM_FROM_AXIS_INDEX[int(axisnum)] = int(i)
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
![:-) :-)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
05 Apr 2021 12:15 #204885
by marks
Replied by marks on topic DRO not counting for JOINT_4
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..
Please Log in or Create an account to join the conversation.
05 Apr 2021 20:35 #204961
by cmorley
Replied by cmorley on topic DRO not counting for JOINT_4
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.
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.
Please Log in or Create an account to join the conversation.
06 Apr 2021 07:30 #205049
by marks
Replied by marks on topic DRO not counting for JOINT_4
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
)
![:-) :-)](/media/kunena/emoticons/smile.png)
![:-) :-)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
06 Apr 2021 10:41 #205064
by marks
Replied by marks on topic DRO not counting for JOINT_4
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.
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.
Please Log in or Create an account to join the conversation.
06 Apr 2021 10:46 #205067
by marks
Replied by marks on topic DRO not counting for JOINT_4
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
.
![:-) :-)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
06 Apr 2021 10:50 #205069
by cmorley
Replied by cmorley on topic DRO not counting for JOINT_4
Thanks for the update and explination.
I have to figure out why the sample configs with gantry axes didn't error, but yours did.
I have to figure out why the sample configs with gantry axes didn't error, but yours did.
Please Log in or Create an account to join the conversation.
07 Apr 2021 06:01 #205230
by marks
Replied by marks on topic DRO not counting for JOINT_4
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
![:-) :-)](/media/kunena/emoticons/smile.png)
Please Log in or Create an account to join the conversation.
Moderators: cmorley
Time to create page: 0.090 seconds