We are experiencing the C4A1 error frequently on a CB3.0 robot with Polyscope 3.13 when using our URCap.
The service manual mentions overloading the communication between the Safety Control Board and Motherboard as a possible reason, but what does it mean exactly, and which software versions are affected?
Our URCap contains a daemon process with some functions written in pure C++ that run quickly and requires very little cpu and memory, so I would exclude this module from the possible reasons. On the other side, the main robot program performs a lot of calculations, written in pure URScript, but URScript is running inside the URControl process, so that should not overload the communication either.
So my question: in what cicrumstances can the communication be overloaded and how can we locate the problem?
Additional info: in older Polyscope versions, we experienced often the runtime error “The program used too much time without instructing the robot what to do.” This error seems to be removed from recent Polyscope versions, but is it possible that C4A1 is a side-effect of this improvement?
I think there are several issue that can cause C4A1. If the issue is caused be high load on the URController due to your calculations, I will recommend you to insert some "sync()"s if you do not need the answer immediately.
Thanks for your answer @Ebbe, are there any simulation tools available for reproducing such communication overloads without a real robot? URSim does not include the simulation of the communication with the safety subsystem, as far as I know.
No, the embedded safety part is not a part of the simulation. I am not aware if anyone have tried to make a guest system that is targeting to deliver processing power equal to the robot(s). But since the also OS differs I will assume it to be a challenge to make identical.
Just wanted to chime in: we have 2 UR10 with CB3.0 controllers and have had tons of C4A1 errors since upgrading to 3.12 and above while they ran smooth before. We spent tons of time figuring out the issue and first noticed our workshop earth ground was bad which caused intermittent C4A1 errors while playing programs 24/7 but that was once in a few days. On the other hand the C4A1 error happened pretty much every few minutes while jogging them manually.
We just downgraded step by step from 3.14 to 3.13, 3.12 and now 3.11 where the C4A1 errors completely disappeared. If that can be of any help.
Have you looked into the load on the controller, you can use the UR log viewer to record the “Actual execution time” register. Please pay attention that textmsg()/varmsg() also put a big load on the system. So do not use them too intensive.
Hi @Ebbe, unfortunately as described we experience the crashes when manually jogging the robot, so no program is executing at all. We have seen the issue arise over and over even on a freshly booted robot with no program loaded, on both our robots same behavior. Just jogging them for a few minutes will bring the C4A1 error, making them unusable on 3.12 and above. I opened a support ticket many months ago but have had no news since then, do you have any further infos or internal progress regarding that?
The next release is expected to arrive in a not too far future. I am not sure if it will include a fix for your issue.
Ok thanks, we’ll test it and report if the problem is still persistent.