I have reproduced “No controller” with the following code
Thread_1
socket_close(“Socket_Not_Opened”)
sync()
Thread_2
socket_close(“Socket_Not_Opened”)
sync()
.
.
.
Thread_7
socket_close(“Socket_Not_Opened”)
sync()
Anyway In my case when trying to close socket which is not opened, “NO Controller” occurs occasionally.
“No Controller” means that URControl, linux process, is killed.
Hi,
below, the report incident from a UR10 CB3.1, update 3.8 (s/n : 2018300842)
The problem just occur on the 09/01/19
We are still seeing this same issue on our CB3 robots, we have upgraded to 3.8 and that has not helped with the situation. Has anyone figured out anything further on what is causing this situation?
There are a number of reasons, that can cause the controller to crash, and throw a “No Controller” error.
We are investigating multiple causes. The release of 3.9/5.3 will mitigate some of these errors.
Possible causes include the usage of secondary programs and multiple threaded XML-RPC calls.
There are no known issues for XML-RPC calls on e-Series, only CB3.
Is there a planned fix for the issue on CB3 with multi-threaded xmlrpc calls? We have this issue today with our own xmlrpc server and the need to have multiple threads keeping track of different bits of data, or different threads handling different messages as well as the main program making xmlrpc calls when needed. We are also running ATI FT sensors and they use XMLRPC and that probably compounds the situation.
BTW, we have seen the controller disconnect issue on e-series and we are not using secondary programs, nor do we have any URCaps installed on them but we are using multi-threaded xmlrpc calls.
The issue only seems to plague us when the robot program is paused or stopped. When it happens it seems to be after sitting for 30-60 seconds and then we lose the controller.
@jbm any update on fixes for this issue? We are seeing a lot of no controller errors on UR10e in the field, almost anytime we press stop on the controller we get a no controller error. We see this on CB3 but not at this frequency and running similar programs on the robots.
I am troubled with the same problem on th UR10e with PolyScope 5.2
I am using an URCap with XMLRPC-calls and noticed that it is related to the frequency of calls in my case.
Case 1:
The gripper moves via URCaps without moving the robot.
A Frequency of prob. 10 calls per second causes the error after 12 Minutes almost every time.
Tested several times with same result.
Case 2:
Same Story, lesser amount of XMLRPC calls (1 per second)
The error occurs after almost 2 hours.
For some reason, the PolyScope Interface becomes really laggy 1 or 2 minutes before the “No Controller”-Error occurs.
The lags prevent using user elements on the interface until the “no controller” error appears.
@mbush
We have fixed few issues around controller stopping unexpectedly in upcoming release 3.9.0/5.3.0 .
Details will follow with release notes.
There is still known issue with XMLRPC on G3, we’re working on solution. This should not be a problem on eSeries.
Same problem with Polyscope 5.3.0 on eSeries
Hi @dervis.mutlu,
Could you report steps to reproduce issue through your local tech support?
I got a brand new UR10 CB3.1 with 3.9.0 on, and it stops with NO CONTROLLER.
There are no URCap’s installed, and it isn’t connected to any network either.
Looks like something is still wrong, unless it is a hardware issue on this robot.
Hello,
we’ve also noticed a “No Controller” error on one of our robots with concurrent XML-RPC calls in combination with a Weiss gripper and FTS (problem is not caused by the gripper).
The problem seems that the DNS resolver of the libcurl library (used by the xmlrpc library) is not suitable for multi-threading.
The error is described in more detail here:
A possible fix is described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570436#74,
We solved the problem by replacing the libcurl.so.4 library from the libcurl3 package with a new version manually, that does not have that multi-threading DNS problem.
Maybe this helps to solve some problems with concurrent XML-RPC calls.
That’s exactly what we did in release 3.10.0. Did you update to the latest version?
libcurl3 (+required dependencies) was updated to version 7.38.0-4.
We updated the mentioned libcurcl library sometimes last year due to the problem with concurrent XML-RPC calls.
Good to know that an update to PolyScope 3.10.0 also adresses this problem now.
Thank you very much!
It is good news, that multi-threading issue was covered by libcurl update. Is there a similar way how to avoid this issue when using a Python daemon? Any help is strongly appreciated.
What do you mean by “similar issue”?
Do you get “no controller”, or does python demon crash?
The Python daemon usually don’t crash because of libcurl issue.
It seems to be xmlrpc client (urscript) side unhandled situation. But the source of the issue is probably in the libcurl on the server as mentioned earlier.
Sometimes it invokes a NO-CONTROLLER state (usually on CB series), sometimes it comes with following message (usually on e-Series):
XMLRPC Failed with exception: Unable to transport XML to server and get XML response back. libcurl failed to execute the HTTP POST trasaction, explaining Recv failure Connectionn reset by peer.
It is always invoked by URScript multi-thread pogram with calling XMLRPC request simultaneously. Defining XMLRCP calls in critical section of the thread doesn’t help.
Good solution in C++ based daemons is to include updated version of libcurl. This update you’ve probably done in the robot image already.
My previous post was about Python daemon support, where this issue still occurs, because the python libraries remains the same (2.7.3).
Thank you for explanation.
On eSeries libraries were updated from day zero, so python should not be affected.
Get back to tech support of forum if you have reasonably good way to reproduce it.
I have been working on Polyscope 5.4.3 and my URCap has a python daemon file. Following error was occurred and I am not able to deduce a suitable reason for this error. Any help is strongly appreciated to solve this problem.
Hi, I am having the same problem too. I am working with a UR10 E-Series with V5.5.1.82186.
A have a Python-Daemon communicating with the URSCRIPTand within the daemon is also a RTDE communication running.
The error is difficult to reproduce. But all my test bring the same error after a couple of hours:
Runtime error (85:15): XMLRPCClient : Failed with exception: Unable to transport XML to server and get XML respose back. libcurl failed to execute the HTTP POST transaction explaining: Recv failure : Connection reset by peer.
