Waiting for S.Axes problem

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

andypugh wrote:

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.

OK, I hope that VNR can test this, as I don't have an old enough board to test it here. But,
the problem was quite obvious, the velocity pin did not get created, and then the encoder
module tried to write a value to it.

I did test it with a USC and a UPC board, and it works fine in both cases, so it didn't
break anything (I think). If the lines were moved to the right place to satisfy C syntax,
I don't see how this code could go wrong.

Jon

andypugh wrote:

I think that you get the "waiting for s.axes" problem any time that the realtime part of a HAL component crashes the realtime thread.
It might be worth adding a diagnostic to check for that cause.

Right, and write a much more informative message. Not exactly sure how you detect a crashed
RT module in a thread, but hopefully there is a simple way to do so.

This particular bug did not cause the driver to crash during initialization, which would
cause LinuxCNC to shut down immediately with a slightly more informative message.
It only caused it to crash on the first servo thread execution.

Jon

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

I instaled the update and it is working OK with my USC card (by the way is an old card Rev 2.2 2005-9-1 Number 0046)
Thanks Jon for the patch.

VNR 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

I instaled the update and it is working OK with my USC card (by the way is an old card Rev 2.2 2005-9-1 Number 0046)
Thanks Jon for the patch.

Excellent! Thanks so much for FINDING the cause, and then testing the fix!

The board rev # is not the same as the firmware rev #. But, a huge change was
made at the rev 3.0 board going to a newer FPGA chip, so older boards
couldn't accept newer firmware.

Jon

i will run the linuxcnc by commond but i have this error .

so please quide me how to fix it.



RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/share/linuxcnc/tcl/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.5
INIFILE=/home/shailesh/linuxcnc/configs/sim.axis/axis.ini
PARAMETER_FILE=sim.var
TASK=milltask
HALUI=halui
DISPLAY=axis
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
Killing task linuxcncsvr, PID=4845
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments