USRMOT: ERROR: command timeout

01 Mar 2017 13:22 #88806 by Reinhard

I'm working on a hal-driver.
First step was a comp file with some pins and just telling the arguments received through the pins. Worked so far.
Then I created a client/server blueprint and tested it outside of hal. Worked fine.
Third step I extended the comp-file with the client code and started the server, before starting linuxcnc.
Now linuxcnc fails to start with
... USRMOT: ERROR: command timeout
messages in an endless loop.

No suspicious messages in syslog, no info at linuxcnc_debug.txt or linuxcnc_print.txt

How can I narrow the problem?
When I load my driver with halrun, it loads without error.
01 Mar 2017 14:35 #88814 by andypugh
I assume you are loading the component in a HAL file with the "loadrt" command?

Perhaps try loading it later in the sequence?
01 Mar 2017 14:41 #88816 by Reinhard

my driver is already the last in the sequence of my hal-file (kinematics, emcmot, my driver)
One effect of the error is, that the frontend comes up with destroyed surface and unresponsive - have to kill the session to close linuxcnc.

Is there any logging in hal, that I could enable?
01 Mar 2017 19:38 #88837 by andypugh
The most likely problem is that you are over-running array bounds and writing to memory occupied by another part of LinuxCNC. (C does no checking for this)

Can we see the .comp file?
02 Mar 2017 04:03 #88859 by Reinhard

The samples where both verified with valgrind and I hope, that I did no typos on transfer
02 Mar 2017 13:31 #88872 by andypugh
Do you know that sendto() and recvfrom() are thread-safe and guaranteed to return without blocking?

The hm2_eth driver seems to use different (simpler?) functions and looks to run a timeout-loop to avoid blocking.

Bear in mind that any realtime function needs to be guaranteed to complete in much less than the thread period.
03 Mar 2017 03:38 #88913 by Reinhard
I don't know much about programming.
I only read manpages and stuff from internet ...
afaik blocking is a socket property and does not depend on the used system calls.
The calls I used are said to be right on connectionless communication (I don't use connections).

Respect to timing - I extended the client to tell the time spended on system calls:
feed back:  12/ 38/ 29/ 44/ 40
time to transmit: 0.55056
time to receive:  0.98814
feed back:  33/ 99/  0/  3/ 58
time to transmit: 0.59392
time to receive:  0.81668
feed back:  55/ 11/ 22/ 34/ 49
time to transmit: 0.37009
time to receive:  0.108219
feed back:  34/ 55/ 28/ 19/  9
time to transmit: 0.57034
time to receive:  0.80696
digits after the dot are nanoseconds from clock_gettime - and even the slowest response time is 10 times faster than required.

From the failed start of linuxcnc I can tell, that my server did not receive any message, so I don't know, what will block.
03 Mar 2017 10:15 #88919 by andypugh
I think that you might have to ask this question on the developers mailing list. The only people with any experience of ethernet comms are much more active there than here.

Which kernel are you using? I don't know why it is, but hm2_eth requires the PREMPT_RT kernel, it doesn't work with RTAI.
04 Mar 2017 04:51 #88981 by Reinhard
Thank you for your support!

currently I don't have any realtime kernel on my desktop. May be, that the VMs with realtime-kernels don't work with non-realtime host ...
So I'm gonna reinstall my desktop with a realtime linux. May be, I have more luck then :)

Cheers Reinhard
Time to create page: 0.182 seconds
Powered by Kunena Forum