Waiting for S.Axes problem

Finally i found the bug:
The Axis prints "waiting for s.axes" because hal_ppmc driver crashes at line 1147.

src/hal/drivers/hal_ppmc.c -> funcion static void read_encoders(slot_data_t *slot)
1146 } else {
1147 *(slot->encoder.vel) = vel; // encoder without timestamp
1148 }

The tracking history:
1) Axis prints "waiting for s.axes" because src/emc/ini/iniaxis.cc fails in function loadAxis at emcAxisSetBacklash
2) src/emc/task/taskintf.cc fails at function emcAxisSetBacklash because function usrmotWriteWriteEmcmotCommand fails.
3) src/emc/motion/usrmotintf.cc fails at function usrmotWriteEmcmotCommand because function usrmotReadEmcmotStatus always return s.commandNumEcho = 0 (must be equal to commandNum sent)
4) Fixed this Axis loads.
5) But now i get an RTAPI fault.
6) So i read rtfaults.txt ( git.linuxcnc.org/gitweb?p=linuxcnc.git;a...rtfaults.txt;hb=HEAD ) and found that the problem was hal_ppmc.c at line 1147.
7) I commented that line and recompile.
I got back with the change in 4) and recompile again.
9) Now i can run the univstep example config (with Axis and hal_ppmc driver). I can get out of estop, home all and MDI G0 X100 Y100 Z100.

You could try a bug report about this:
sourceforge.net/tracker/?atid=106744&group_id=6744&func=browse
I am not sure which of the module authors is currently active though.

VNR wrote:

Finally i found the bug:
The Axis prints "waiting for s.axes" because hal_ppmc driver crashes at line 1147.

src/hal/drivers/hal_ppmc.c -> funcion static void read_encoders(slot_data_t *slot)
1146 } else {
1147 *(slot->encoder.vel) = vel; // encoder without timestamp
1148 }

The tracking history:
1) Axis prints "waiting for s.axes" because src/emc/ini/iniaxis.cc fails in function loadAxis at emcAxisSetBacklash
2) src/emc/task/taskintf.cc fails at function emcAxisSetBacklash because function usrmotWriteWriteEmcmotCommand fails.
3) src/emc/motion/usrmotintf.cc fails at function usrmotWriteEmcmotCommand because function usrmotReadEmcmotStatus always return s.commandNumEcho = 0 (must be equal to commandNum sent)
4) Fixed this Axis loads.
5) But now i get an RTAPI fault.
6) So i read rtfaults.txt ( git.linuxcnc.org/gitweb?p=linuxcnc.git;a...rtfaults.txt;hb=HEAD ) and found that the problem was hal_ppmc.c at line 1147.
7) I commented that line and recompile.
I got back with the change in 4) and recompile again.
9) Now i can run the univstep example config (with Axis and hal_ppmc driver). I can get out of estop, home all and MDI G0 X100 Y100 Z100.

WOW, I can't believe this is the first person to hit this bug! Now, this code has been only in the
development version of LinuxCNC for a long time, waiting for the long-fabled 2.5 version to come
out. This was done in November 2010!

OHHHHH! NOW I understand! This error REQUIRES the board to be very old (Pre ver 2),
from before late 2006.

What is going on is that the function export_encoders() should always export the velocity pin,
no matter what rev the board is. But, only if the board is greater than ver 2 does the current code
do that. For some reason, this was bundled with the encoder timestamp and index-enable
features. Older USC boards don't have properly working encoder index logic.
But, all encoders should be able to produce a scaled velocity from the position delta, so it
should always export the velocity HAL pin.

I am driving to the CNC Workshop on Wednesday, and will be coming back on Sunday.
I'm a little afraid to hack into this and make things worse.
But, if VNR doesn't need the
scaled velocity, commenting out that line is fine. If he does want that, then the fix is to
move lines 2141-2145 up before line 2132. Since no USC board has timestamping of
the encoder counter, it will just scale the encoder delta value.

I'm not sure I can cobble together a board of that old revision, that used a 5 V FPGA
instead of the newer 3.3/1.8 V FPGA, so I can't just put old firmware in a new board
for testing.

Well, thanks to VNR for finding a bug I should have tracked down!

Jon

jmelson wrote:

I'm a little afraid to hack into this and make things worse.

Well, after looking at it a bit, the fix seemed so obvious and simple, that
I went ahead and pushed, seems to be in the v2.5_branch tree, is
this the right place to be putting this?

Thanks,

Jon

jmelson wrote:

I went ahead and pushed, seems to be in the v2.5_branch tree, is
this the right place to be putting this?

Yes, that gets it in as a bugfix in 2.5, and it will then get merged into the dev branch in a day or so.

WOW, I can't believe this is the first person to hit this bug!

I'm not sure if he is the first, but he is certainly the first to resolve it. Well done!

These 2 threads are pretty much unresolved and the errors look similar
(well second resolved but print similar)
www.linuxcnc.org/index.php/english/compo...=38&id=20554&limit=6
www.linuxcnc.org/index.php/english/compo...tid=9&id=20485#20535

There is at least one more but I can't find it presently.

The error print
Debug file information:
Can not find -sec MOT -var MOT -num 1
Can not find -sec IO -var IO -num 1
Can not find -sec LINUXCNC -var NML_FILE -num 1
Can not find -sec EMC -var NML_FILE -num 1

seems to be coming up since 2.5 and appears to suggest a problem parsing / finding the .ini file
but that looks like that is a purple bloater and the problem was elsewhere.

regards