DRO values not zero on startup

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.

If you end with G53 G0 X0 Y0 Z0 and then shut down what happens?

Rick G

I had another play around last night.

Initially things looked good - on the first start of the machine all the axes were at zero, so after homing at that position I tried a simple move - G0 x200 and then issued the G53 G0 X0 Y0 Z0 which returned it to the initial position before I shut down LinuxCNC. The second start wasn't so good though - X now reading -539.76, Y 0, Z -655.35.

So, I homed it again, tried moving all three axes (X200,Y-100,Z-50), returned to machine zero (G53 etc) and started for the third time - now we have X-539.77,Y511.86,Z-14.6. This looks strange and i wondered if the changes in readings were something to do with startup positions of the scales or movement they'd been through before shutdown, so i moved to X300, Y-140, Z-50 before shutdown.

4th startup: X-184.42, Y651.86, Z-619.96. I then homed all three axes without moving them from that position before shutting down.

5th startup: X-184.41, Y651.86, Z-619.96. I then moved back to my normal homing position at the end of each scale, homed the axes, ran G0 X200, Y-100, Z-50 followed by G53 etc before shutting down again.

6th startup: X-539.55, Y510.56, Z-16.1. As an experiment I homed the axes, then moved the X axis to 539.55 before shutting down.

7th startup X-423.75, Y 510.55, Z-16.11. Returned the machine to the homing position at the end of the axes, homed it, ran a couple of moves before returning home with G53 etc.

8th Startup X-539.61, Y510.55, Z-16.08

The funny readings I'm getting aren't totally random - they seem to be semi-consistent between starts, depending upon what's happened before or what position they're left in. In each case when the machine has been homed and left in the home position, the position.txt file shows the axes as all zero. I've attached screen dumps of each of the described stages for your viewing pleasure....

Thanks

Ben

i'd check for noise or spikes on startup especialy on the supply to the encoders or mesacards , and the pc etc
are the encoder cables screened and any other low voltage wiring

That's worth a check I guess, although the encoder cables are screened up to the point that they go into the computer cabinet and from there to the MESA cards they are using CAT5 twisted pair cabling. The external cabling has not been changed from the old Anilam installation, while the internal cabling used to be just plain unshielded ribbon cables.

The "restarts" I'm talking about here are just restarts of the LinuxCNC software itself, not the PC or any other power supply or hardware, so I cant think of what might be causing a spike. Also, the encoders are completely stable at all other times such as when moving, starting and stopping the VFD etc - it's just the initial readings that are strange.

I will stick a scope on the low voltage supply through the process though, to see what (if anything) is going on.

I would try a simple hal file like hm2-servo-hal
to verify if this is a setup or hardware issue
(disable your drives for the test)

freeby.mesanet.com/7i77.zip has .ini and hal files
for the simple hm2-servo config for a 5I25 and 7I77

Before going to that extreme, what happens if you set
"show machine position" instead of "show relative position"

Ok, now we're getting somewhere - show machine position or show relative position made no difference, but the sample ini and hal files certainly did!

I had to modify the ini file with the correct value for INPUT_SCALE so that my units were correct, but now on startup of LinuxCNC the positions read zero every time. If I enable the POSITION_FILE statement then the last position is stored and recalled as it should.

Now the question is what's wrong with my configuration files that's making this happen. I'm going to take a look through them now.

*very* relieved to find that this is likely to be a configuration issue rather than a hardware problem!

Ben

Ok. It's taken me a while, but I think I've found the source of the problem:

In the .hal file for each axis there is a statement similar to the following:

net x-pos-rawcounts <= hm2_5i25.0.encoder.00.rawcounts

I can see that it's taking the raw encoder counts from the MESA card and sending that to a signal called X-pos-rawcounts, which is fair enough. However, I don't know what it's actually intended for, if anything other than diagnosing the hardware using Halscope etc.

Can anyone shed any light on why that command might be causing my DROs to start up with odd values? When I comment out the commands, they start at zero. I haven't tried running the machine yet so I don't know if there are any other side effects - they were created by PcCConf originally, so I don't know what their purpose is.

Thanks

Ben

Can you post your hal file here to see where net x-pos-rawcounts is used?

Sure, the command is in there for each axis - I can't find any other reference to x-pos-rawcounts in the hal file though.

Thanks

Ben

If they are not connected, it may be a hm2 driver / linuxcnc / hal
bug of some kind

It is a pretty strange configuration, using both a 7I76 and a 7I77

Can you add some signals to some encoder rawcounts pins in the
hm2-sample config to see if this is a driver or hal bug?

A side issue is that the config line is rather suboptimal as well, enabling lots
hardware that is unused (the 5 unused stepgens, 7 encoder counters with only 4 used).
This should not cause a problem but will waste CPU I/O cycles.

Also with a 7I76/7I77 its better to use the 7I76/7I77s built in MPG support
than a normal encoder especially if you have a 100 count MPG Since the normal
encoder input does not support a 1X mode