PROBE BASIC - WRAPPED_ROTARY
26 May 2022 10:07 #243884
by Thom
PROBE BASIC - WRAPPED_ROTARY was created by Thom
Hi all,
On probe_basic (QtPyVPC interface), the wrapped_rotary i can't get working: The behaviour is like without the line.
(I tried it on the C-Axis; Joint3; trivkins coordinates=XYZC)
Any ideas what is wrong with my configuration?
Thankyou in Advance,
Thom
On probe_basic (QtPyVPC interface), the wrapped_rotary i can't get working: The behaviour is like without the line.
(I tried it on the C-Axis; Joint3; trivkins coordinates=XYZC)
Any ideas what is wrong with my configuration?
Thankyou in Advance,
Thom
Attachments:
Please Log in or Create an account to join the conversation.
30 May 2022 00:31 #244164
by andypugh
Replied by andypugh on topic PROBE BASIC - WRAPPED_ROTARY
Which version of LinuxCNC? (Just in case we need to try to reproduce the problem).
I would't expect the choice of UI to matter here.
Testing with 2.8.2 and latest master (and with the Axis UI) I see what I expect to see.
Are you 100% sure that you are editing the right INI file?
What are you seeing? How is that different from what you expect.
In my testing, after homing and with axis C at zero:
G0 C-10
The axis rotates in the negative direction, 0, 359, 358......11, 10.
I would't expect the choice of UI to matter here.
Testing with 2.8.2 and latest master (and with the Axis UI) I see what I expect to see.
Are you 100% sure that you are editing the right INI file?
What are you seeing? How is that different from what you expect.
In my testing, after homing and with axis C at zero:
G0 C-10
The axis rotates in the negative direction, 0, 359, 358......11, 10.
The following user(s) said Thank You: Thom
Please Log in or Create an account to join the conversation.
30 May 2022 17:14 #244230
by spumco
Replied by spumco on topic PROBE BASIC - WRAPPED_ROTARY
Probe Basic "WRAPPED_ROTARY = 1" works as advertised for me (I think). MDI/G-code will only accept position commands +/- 0-359.999. Positive input numbers will turn CCW, negative turns CW.
(config)
MX21.1
LCNC 2.9
QtPyVCP (master)
Probe Basic (python3 branch)
Maybe the OP is misunderstanding the intended movements: wrapped rotary does not cause the axis to behave like a 'shortest-path' indexer where a position command is treated like an absolute coordinate and the controller figures out how to get there. I believe this is the intended behavior, but I could be wrong.
[sequence from A0)
"A90" moves +90 degrees (DRO = A90)
"A-90" moves -180 degrees (DRO = A-90)
"A-180" moves -90 degrees (DRO = A-180)
"A-90" moves -270 degrees (DRO = A-90)
Guessing the developers' rationale here: a shortest-path scheme would be incompatible with continuous 4th axis machining as there would be no (easy) way of ensuring a continuous toolpath. A CAM post-processor (or human for that matter) couldn't possibly 'force' a 340-degree toolpath from A10 to A350; LCNC in shortest-path would always move 20 degrees (through A0) despite the desire to machine the long way.
On the other hand, it would be nice if there was a 3rd rotary axis control scheme built-in to LCNC for indexers. i.e. a shortest-path scheme with only positive position commands allowed. Since a locking indexer function is already built-in - and those aren't really compatible with continuous multi-axis toolpaths, adding a shortest-path control type/scheme would be useful for certain conditions.
Just a thought...
(config)
MX21.1
LCNC 2.9
QtPyVCP (master)
Probe Basic (python3 branch)
Maybe the OP is misunderstanding the intended movements: wrapped rotary does not cause the axis to behave like a 'shortest-path' indexer where a position command is treated like an absolute coordinate and the controller figures out how to get there. I believe this is the intended behavior, but I could be wrong.
[sequence from A0)
"A90" moves +90 degrees (DRO = A90)
"A-90" moves -180 degrees (DRO = A-90)
"A-180" moves -90 degrees (DRO = A-180)
"A-90" moves -270 degrees (DRO = A-90)
Guessing the developers' rationale here: a shortest-path scheme would be incompatible with continuous 4th axis machining as there would be no (easy) way of ensuring a continuous toolpath. A CAM post-processor (or human for that matter) couldn't possibly 'force' a 340-degree toolpath from A10 to A350; LCNC in shortest-path would always move 20 degrees (through A0) despite the desire to machine the long way.
On the other hand, it would be nice if there was a 3rd rotary axis control scheme built-in to LCNC for indexers. i.e. a shortest-path scheme with only positive position commands allowed. Since a locking indexer function is already built-in - and those aren't really compatible with continuous multi-axis toolpaths, adding a shortest-path control type/scheme would be useful for certain conditions.
Just a thought...
Please Log in or Create an account to join the conversation.
05 Jun 2022 12:38 #244610
by Thom
Replied by Thom on topic PROBE BASIC - WRAPPED_ROTARY
Hi Andy,
Thanks for you help
It was my mistake: i was confused by the visualisation:
The QTPyVCP DRO Widgets do not recognice the wrapped rotary axis and display Values below 0 and above 360 degree.
I worked around it with a quick fix in the dro_base_widget.py (attached)
Have a nice Weekend,
Thom
Thanks for you help
It was my mistake: i was confused by the visualisation:
The QTPyVCP DRO Widgets do not recognice the wrapped rotary axis and display Values below 0 and above 360 degree.
I worked around it with a quick fix in the dro_base_widget.py (attached)
Have a nice Weekend,
Thom
Attachments:
The following user(s) said Thank You: TurBoss
Please Log in or Create an account to join the conversation.
05 Jun 2022 13:06 #244611
by andypugh
Replied by andypugh on topic PROBE BASIC - WRAPPED_ROTARY
Do you want to submit this change as a pull request?
Please Log in or Create an account to join the conversation.
10 Jun 2022 19:18 #244898
by TurBoss
Replied by TurBoss on topic PROBE BASIC - WRAPPED_ROTARY
Hello,
I'm taking a look at the fixes they look good
Thanks!
I'm taking a look at the fixes they look good
Thanks!
Please Log in or Create an account to join the conversation.
Time to create page: 0.150 seconds