PROBE BASIC - WRAPPED_ROTARY

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

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.

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...

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
 

Do you want to submit this change as a pull request?

Hello,

I'm taking a look at the fixes they look good

Thanks!