DRO values not zero on startup

When I start up LinuxCNC the DRO readouts are not zero.

I've not really worried about it too much as to fix it I just have to home the machine and zero the scales and I've had other things to think about. I tried to deal with it by using the POSITION_FILE parameter within the ini file as I suspected it was something to do with the startup of the linear scales. The last position of the machine was successfully stored in the position.txt file, but when I next started the machine, the displayed co-ordinates were again all over the place.

Sometimes the position displayed is quite close to where the machine actually is, other times it's out by a country mile. For instance, the Z axis may display a position of 653mm, but the scale itself is only 200mm long! Further, sometimes when I home the machine, the axis does not zero, it just changes to some other arbitrary position.

So far I've been able to work around this as I'm manually homing, but I want to install home switches and implement automatic homing, so I suspect that this issue may come back to annoy me when I get started on that - particularly the "non zero homing".

My machine consists of linear encoders connected to Mesa 7i77/5i25 hardware in case that is relevant.

Can anyone shed any light on what might be happening here?

Ben

With incremental encoders you really have no idea where the machine is until its homed
I would remove the POSITION_FILE statement in the .INI file and check you homing
sequence/switches

Hi

Thanks for the reply, but I don't actually have a homing sequence or switches at present - that's what I intend to be installing soon.

My question is actually about the positions shown by the DRO at the startup of LinuxCNC: With or without the POSITION_FILE statement enabled, the position values change every time it starts. I would have expected the values to show up at zero by default with no POSITION_FILE and to show the values stored in position.txt with the statement enabled, but I'm getting neither.

I dont think the encoders are explicitly cleared at startup
so the count is wherever it last was. Since the count is purely
relative until homed this makes no difference. If you want the DRO to read
0 before the system is homed you would probably have to use the (HAL) reset pin
on the encoder.

spangledboy wrote:

Hi

Thanks for the reply, but I don't actually have a homing sequence or switches at present - that's what I intend to be installing soon.

My question is actually about the positions shown by the DRO at the startup of LinuxCNC: With or without the POSITION_FILE statement enabled, the position values change every time it starts. I would have expected the values to show up at zero by default with no POSITION_FILE and to show the values stored in position.txt with the statement enabled, but I'm getting neither.

First, LinuxCNC ASSUMES you have homed the machine to some kind of repeatable position.
THEN, it applies the last known offset from that position, which was saved the last time
LinuxCNC was shut down cleanly. If you had a fixture on the machine and had touched off to
align to that fixture, then when you restarted LinuxCNC at a later date and homed the machine,
the same offset would be reapplied. This is VERY nice when you have to do some task in
several sessions.

The homing sequence is also a great benefit, as then the limits of machine travel can be entered
into the .ini file. This allows each program to be checked against machine limits when they
are loaded, or the run button is pressed. MUCH better to get a warning before the first move
is made that the program will exceed travel limits at line 9999 that have to get there to discover
you have not positioned the work properly on the table!

Jon

Ben,

Before you shut down the machine (assuming it can be safely moved to these positions) you might try returning to your start positions.
For a 3 axis mill I use...
Rick G

Ok, I've spent a few minutes starting, homing and restarting LinuxCNC and I've noticed a few things (in Axis at least - GMoccapy seems to give different results, but I'll forget about that for the moment). I've attached screen dumps too illustrate what I'm seeing:

1) Started LinuxCNC. The displayed positions are X=-243, Y=1420, Z=-1280 - all outside the machines normal limits.

2) Without moving anything, I homed all three axes. Displayed positions X=0, Y=134, Z=29.28. These are the arbitrary values that seem to come up - any idea why Y & Z are "zeroing" to these values?

3) Moved the X axis by 10mm, then shutdown LinuxCNC.

4) Restarted LinuxCNC - before homing the, X axis has reset to zero and the other, unmoved axes are on the original values (this is actually what I'd expect to happen, with the exception that Y & Z don't actually read zero). After homing, the values remain unchanged.

I'm beginning to wonder if there's some configuration remnant from PNCONF that's somehow entering the 134 & 29.28 figures or if this is something to do with my lack of understanding of the coordinate systems. Fortunately this is more of a minor irritation than a major issue, but I really want to understand what's going on here.

Thanks

Ben

looks like at the minimum you have some G54 offsets set (and these are saved in a file so persistent)

linuxcnc.org/docs/html/common/User_Conce...9_3_user_coordinates

Just verified, with a standard 7I77 hal file at linuxcnc startup the DRO read all 0s

Thanks to both of you! Indeed, using the G10 command as described in 5.2 & 5.3 cleared the offset.

I'd even looked at that page but not noticed the (now obvious!) "When you're lost" heading. I guess I was suffering from "staring at the problem for too long" syndrome.

However, when I next started up LinuxCNC the Y axis read 655.35 while the other axes are at zero and when I home them they all go to zero.

I then tried moving X & Y by 10mm and closed down Axis. On opening Axis again, the positions had been stored correctly and (understandably) homing cleared them back to zero. But when I next closed down Axis and reopened, the Y axis was again displaying 655.35.

Interestingly I have a similar behavior with Gmoccapy, although the Y axis comes up with a different value - something like 1053. When I home the axes there they return to zero.

I think now that I've got back to the actual issue that I originally posted about, although I'm grateful to have got past the offset question that was further confusing me.