matthewd92
@arnoldgauge thanks for sharing that! Hopefully it will help others as well.
PE_Germain
arnoldgauge
Hi @PE_GermainPE_Germain said:Hi @arnoldgauge
I have already saw some lag in the robot but I never checked with the gateway. I would definitely try this. What is the version of polyscope that you use ?
I know it's an issue in the 5.4 and 5.5 releases. I suspect it has been a long-term issue as I had a similar complaint on an older UR5 when we did a Pick-it proof-of-concept a few months ago. One of my engineers complained that it took forever to boot-up the robot. Pick-it uses a private ethernet network to communicate with the camera.
Samuel_Bouchard
Hi all,
We ran into an issue that I consider a bug with UR, but wanted to describe it here as the problem and fix were not at all intuitive. Hopefully, it can help someone save some grief if they run into a similar issue.
We have a number of UR5Es we're deploying in a complex application. https://www.youtube.com/watch?v=nl7J9RwkEH8 Heavy use of Force Co-Pilot, Socket communications, Modbus control of a pneumatic stack, prox switches, etc. Once we set up the program, the UR was very, very sluggish. 8+ minute boot-up times from power-on to program-load screen, very sluggish response times on the teach pendant, etc. Random lockups, etc. Force Copilot would overshoot and give a safety-fault at random times, etc. The robot just acted drunk.
We upgraded and downgraded, tried different versions of UR Caps with no luck. Frustrated as heck. Nothing made sense.
Turns out the issue was with the network stack. The network was defined as:
If the network gateway is not physically connected and available, the UR becomes incredibly sluggish and unreliable. Changing it to this fully addresses the problem:
If anyone else has this kind of issue, hopefully, a search will lead them here.