UR5 don't move if you have too many targets

[vsardenberg]

Hi Robots people!

When I am using robots to send programs to my UR5 it only works if I have less than ~2500 targets. So, I've been splitting the programs, which is not ideal. Do you have a solution for it?

Best!

[visose]

Only solution I think is to not use the stream program feature, copy the script to the controller, create a program using the pendant that runs the script (you might or not have to split it into multiple subprograms that the main program runs one after another).

[robin-gdwl]

@visose we also constantly run into this problem.
What is the bottleneck in the connection? a TCP-connection via LAN should have no problem sending a few thousand lines of code in a short time.
Is the problem/slowness on the side of the Robot-Controller or is there a way to speed it up on the GH/Robots side?

[visose]

I am not exactly sure where the limit is. Usually very large programs have to be split into multiple subprograms, because when a program is loaded it has to fit in the memory of the controller. This happens with milling programs made of lots of targets or the very common practice in architecture school of using an industrial robot to slowly extrude thick plastic and calling it "3D printing".
Most robots have a way of automatically loading/unloading a sequence of sub-programs.

In this case this is probably different as the size is smaller. It could be a limit of the size of the data that can be sent to the UR in one go through via streaming. But haven't seen in the documentation anything about a limit. I think the best is to use the streaming function for tests and for the final program with lots of targets create a URP program and assign a script generated with Robots, the script can be sent to the controller by FTP or USB.

[UnfoldAntwerp]

Hi @visose @robin-gdwl,

At the start of my experiments with UR10 and Robots I ran into similar issues off remote connection not being reliable over network especially on large target counts. For some unknown reason that got solved early on, did we change network settings, I don't remember but currently we're running into issues again when operating the machine in a different network setup (see my other post). But during the time that I had a stable setup I ran some experiments finding the upper limit of targets I could send. To be honest, I did not find an upper limit, when you wait long enough, it comes through eventually. So I decided to time how long an increasingly larger list of targets would upload and found a nice correlation:
2500 frames: 6 seconds
3000: 8 seconds
4000: 10 seconds
6000: 16 seconds
10000: 27 seconds
20000: 54 seconds
50000: 135 seconds
So on average 370 targets/s...
I've not tested more than 50.000 targets.
I integrated a countdown timer connected to the send button that would give me a nice indication of how long I should sip on my coffee instead of continuously wondering if it did send or not. But given that the sending issues crop up again, I'm not sure if that 370 targets/s upload speed is related to a specific network setting or sending computer or if that is how fast poly scope writes to memory...
The timer is attached, integrate using the left components.
IsolatedRobotsTimer.gh.zip

[visose]

Hi @UnfoldAntwerp , thank you for calculating those numbers, very useful. I wonder if it's due to the time it takes for the controller to load the program and calculate the path planning. Another experiment to do could be to create a UR program in the controller with the same generated code from Grasshopper and see if it also takes as long to start. You can copy the code to the controller via a USB stick or connecting to the ftp server of the controller.

[UnfoldAntwerp]

Hi @UnfoldAntwerp , thank you for calculating those numbers, very useful. I wonder if it's due to the time it takes for the controller to load the program and calculate the path planning. Another experiment to do could be to create a UR program in the controller with the same generated code from Grasshopper and see if it also takes as long to start. You can copy the code to the controller via a USB stick or connecting to the ftp server of the controller.

Hi @visose, yes that really helped us understand that we just needed to be patient and that worked great... until we moved to another place and network and we see many programs failing to upload again. See my post I just submitted: #156
But as part of debugging that issue I would love to test your suggestion, was already on my list. But I believe we tried this in the past but couldn't get the saved file to run on the pendant, do we need to do something special to get the .URS to run on the pendant?

[visose]

There is now support to upload the program via FTP using the Remote component, this might fix the issue when streaming large programs. More info here: #107 (comment)