LinuxCNCrsh: rel_act_pos & abs_act_pos values?

I'm having difficulty understanding the positions I get with LinuxCNCrsh.

For example, I move the X position manually and do a "Touch Off" to zero, then manually move the Z position and do a "Touch Off" to zero which gives me a G54 offset. Then I manually enter an MDI command: "g0 x0.2 z0.3" and the stage moves as expected.

In the DRO tab window, I see:
Rad: 0.200
Z: 0.300
G54 X: 0.0438
G54 Z: -0.0818

I realize the G54 offsets came from the Touch Off, and the X and Z positions are what one would expect after entering the "g0 x0.2 z0.3"

Here's the mystery -- when I try to get the positions with LinuxCNCrsh I never can get the 0.200 and 0.300 values. Here's what I see with LinuxCNCrsh:

hello EMC x 1
HELLO ACK EMCNETSVR 1.1
get abs_act_pos
get abs_act_pos
ABS_ACT_POS 0.243818 0.000000 0.218158 0.000000 0.000000 0.000000
get rel_act_pos
get rel_act_pos
REL_ACT_POS 0.156182 0.000000 0.381842 0.000000 0.000000 0.000000
get joint_pos
get joint_pos
JOINT_POS 0.243818 0.000000 0.218158 0.000000 0.000000 0.000000
get pos_offset
get pos_offset
POS_OFFSET 0.087637 0.000000 -0.163683 0.000000 0.000000 0.000000

The absolute position from the "get abs_act_pos" makes sense -- it's the absolute position including the G54 offsets. What I don't understand is the number I get with the "get rel_act_pos". I would have expected to get 0.2000 and 0.3000. Instead, it looks like I'm getting the actual position minus 2x the G54 offset. Why the 2x offset?

Also, the "get pos_offset" gives me 2x the G54 offset. I would have expected it to give me the actual G54 offset.

Is there any way to get the displayed coordinates using LinuxCNCrsh? Alternately, is there a way to directly get the G54 offset so I can subtract that from the absolute position?

Any explanation of these results would be appreciated. This is on version 2.5 in a lathe application.

Thanks for the reply. That was my first thought as well (a bug?) but I admit that I'm not as experienced as many others who watch the forum. I realize that there are not a lot of people out there using rsh.

My objective is to digitize the outline of a shape by manually positioning the location of the cutter (like touching off) and grabbing the coordinate on my design computer rather than manual typing the coordinates. I can't use the more traditional technique of automatic probing because my cutter is a like a fly cutter (an ornamental lathe) which makes automatic probing difficult on a curved surface.

Any other thoughts out there about the LinuxCNCrsh actual vs. relative values?

Hi

My objective is to digitize the outline of a shape by manually positioning the location of the cutter (like touching off) and grabbing the coordinate

If you look at the zip I attached to this post www.linuxcnc.org/index.php/english/compo...imit=6&start=6#18889
It shows another way to generate co-ordinates by pressing a button when in place and writing to a log file, might help you.

Regards the emcrsh co-ordinates I'll try and have a play later.
The only thing that strikes me immediately is that you appear to be in radius mode rather than diameter, so the figures are not exactly as they first seem, but it still does not explain it.

I never use radius mode as I am interested in the finished diameter of a work piece, but I suspect your requirements with an ornamental lathe may differ.

regards

Hi

OK ran a test using a metric mill sim (axis_mm)
( Because imperial does my head in - haven't used it since school - besides which it makes it a lot clearer as to what is being returned in this instance. )

With a running axis_mm sim, already homed and G54 set to X10 Y10 Z10 in machine co-ordinates

So aside from the POS_OFFSET figure being doubled, the rest seems logical.
POS_OFFSET is in fact the difference between ABS_ACT_POS and REL_ACT_POS, but not exactly clear what use it is supposed to be.

regards

With a running axis_mm sim, already homed and G54 set to X10 Y10 Z10 in machine co-ordinates

I suspect that the sim configs end up with zero "home offsets" so there is possibly a missing degree of freedom there. (I confess I have not looked in detail at the simulated-home HAL)

In practice all it seems to do is take the axes to G53 X0 Y0 Z0, in the case of the mill, and mark as homed.

If you want a meaningful co-ordinate output Bill, might be easier look at the use of G92 with the #5211 and #5213 parameters as per my first link.
You could still do it remotely if you needed to, rather than just transfer the file once written.

regards

Thanks to all for the replies. I'm off for the holiday today (not in the shop). I'll look more closely at the details of the replies tomorrow.

Playing with it some more today, the abs_act_pos makes sense -- it's the G54 offset from touching off plus the coordinates you went to from the last gcode. However, I'm still puzzled why the pos_offset is twice what you would think it should be.

I don't think it has anything to do with being a lathe or the diameter DRO value. The z-axis does the same thing, and ArcEye's metric mill does the same -- the pos_offset is twice what you would expect.

I don't understand how the "G53 X0 Y0 Z0" does anything in this situation. It simply moves the machine back to where I first homed the machine after turning on the power. Marking each axis as home again doesn't change anything. When I issue "G0 X0 Z0" it goes right back to the point where I did the touch-off (as expected). (I not currently using home sensors -- home is where it is when I turn on the power and manually home each axis, then I touching off on the work).

I'll take a closer look at the link provided for other ways to get current position and see if that's easier to implement in my situation. I guess the other option is (for now) divide pos_offset by 2 and subtract it from the abs_act_pos.