X Coordinate Lags MPG Encoder

I am having a problem with the display of the commanded X coordinate in axis and I am hoping someone could help me. I've attached the hal and ini files to this post.

The problem is that when using the jog dial of my wired pendant, the commanded x coordinate often stops updating its display. For example, if it's displaying 0.0001 and I advance the jog dial several clicks, the x coordinate doesn't get updated. If I switch to actual position and then back to commanded position, the x coordinate is updated to the correct value. Or if I just keep rotating the jog dial, the display is eventually updated with what appears to be the correct value. To put it another way, it seems that axis is not polling the x coordinate or refreshing the screen on a regular basis. The problem is worse at low multipliers; its very noticeable at X1, less at X10 and completely gone at X100.

I have used halshow to verify that the hardware is providing the correct signals and hal has the right position data. I've also confirmed that Y and Z work perfectly at all multipliers with no lag or "stuttering".

I commented out many lines in the attached hal file in an attempt to isolate the cause of the problem. But so far no luck.

Any ideas?

My first guess would be that X is not tuned properly
(and the minimum P=.001 seems several orders of magnitude too small)

you shoudt move your mpg to the postgui
this gives more space stzo the timeline
as 1000steps per second max

pl7i92: Thanks. I moved the MPG hal commands to custom_postgui.hal. That didn't solve the MPG X coordiante problem, but it sounds like good practice to keep the MPG commands in a separate file. I've also moved my servo hal commands to custom.hal to avoid pcconf overwriting any changes I've made.

PCW: You are correct, X is not tuned. I was going to tune the servo motor after I got the MPG working. I am surprised that tuning the servo motor would have any effect on how the MPG performs. I viewed the MPG as an input that simply provided pulses and switch positions. I wasn't aware of any interactions it would have with tuning and the servo motor. I'll investigate this further. BTW, I have noticed that if I switch to Y on the MPG and operate the jog dial and then switch back to X, X will then display the correct value and keep up with the jog dial. Thank you for your help.

I didn't read carefully, tuning does not affect the commanded position so I'm not sure whats up with the lag in jog inputs.

Do the GUI jog + - buttons have the same issue?

PCW: "Do the GUI jog + - buttons have the same issue?" Yes, but only on the X coordinate.

Here are the results of testing the coordinates display using the jog + - buttons:
X Y Z
0.0001 Y N N
0.001 Y N N
0.01 N N N
0.1 N N N

Y means there is a noticeable lag in the commanded position display.
N means there is no noticeable lag - the commanded position display updates
immediately.

Lag means sometimes it will take several clicks before the display updates.
When it does update, it appears to have the correct value. In other words
it seems as if it is recording the clicks but not displaying them.

The above test was run by cycling through the multipliers for each axis
starting with X. If Y or Z is tested first and then X is tested, then
X does not lag behind the input clicks. The X coordinate will lag again
if machine power is toggled.

A few things to note:

a) X is configured as a servo motor. This motor is not PID tuned and is
powered off.

b) Y and Z are configured as stepper motors. These motors are not connected.

c) This behaviour also occurs with the MPG. Examining the hal pins & signals
indicate that linuxcnc is receiving and recording pulses correctly. For
example, mpg-out, hm2_5i24.0.encoder.04.count and hm2_5i24.0.encoder.04.rawcounts
all track the mpg input correctly - one click of the mpg jog dial increments
or decrements by 4.

I guess I would trace the numbers in hal, does motions jog count-in lag?

Is this possibly related to your X backlash setting? (you might remove it temporarily)

I've used Pncconf to generate new ini and hal files (attached). I believe these files are fairly simple and generic. This might help debug this problem. Note that I specified a 5i23 in Pcconf and changed it to a 5i24_16 in the hal file to match the Mesa card I have.

"...does motions jog count-in lag?"
I'm not sure where to find that variable. Instead I monitored halui.axis.0.pos-commanded and halui.axis.1.pos-commanded. I'm thinking these variables should always match the commanded position display in Axis. It turns out Y always matches but X does not. I once clicked about 50 times at 0.0001 and while halui.axis.0.pos-commanded was always dead on, the X commanded position coordinate display in Axis was way out of sync. And I found out that I can get them back in sync by clicking in the Preview window. I guess that forces a screen update??

"Is this possibly related to your X backlash setting?"
Unlikely as this new ini file doesn't have backlash in it.

This is a weird problem and I'm running out of ideas. PCW, thank you very much for your help.

It does sound like its an axis issue of some kind, have you tried another GUI?

I meant that you could monitor "axis.0.jog-counts" but if the halui jog pins are OK it sounds more and more like a GUI issue or perhaps something odd with the ini file
that causes axis to setup something wrong.

I cannot duplicate this here with axis and 2.8, what version of LinuxCNC are you running?

"have you tried another GUI?" Yes. gmoccapy behaves the same except I can't get X to update at all - it's stuck at 0.0000. Y & Z are fine. I tried TkLinuxCNC & Mini and they work correctly for all three axis. Looks like this is an Axis issue possibly in combination with my .ini file.

I might try reinstalling LinuxCNC, but I think that is unlikely to help.

"what version of LinuxCNC are you running?" 2.7.14

How stable is 2.8?