PCSDK RAPID Data Access Performance

Gandalph

Hello, I'm building a C# application in which I load a file full of parts from a remote server and get a list of parts. As the parts come, I'm supposed to transfer a list of fastener points to a robot for the robot to go to each point and insert a fastener.

Existing documentation got me there without a problem, but unfortunately some of these parts require a huge number of fasteners. Usually several hundred and sometimes more than 1000.

Unfortunately, it looks like any time I change a piece of RAPID data, the PCSDK writes to the controller right away and incurs some overhead for communicating with the controller. Every write seems to be taking about 20-30 ms.

So I organized the targets into record objects so that a target's information could be written in one go, and got a large performance improvement as the number of write operations that I have to do to the controller decreased.

However, with several hundred updates to do and 30 ms per fastener to update the controller, it's still taking over 10 seconds to transfer all the data to the robot. The records representing the targets are held in an array in the controller, so I thought to try a block copy.

The documentation only mentions methods for setting array values one at a time. Setting these values one at a time with WriteItem() or using the ArrayData object with FillFromString() both set the values in the array one at a time, taking the performance penalty for each fastener.

It is possible for me to work around this poor performance by transferring the data in smaller working chunks as things come up to the robot, but this will require a significant rework of the robot-side code so I would like to avoid it if possible.

So I ask: Is it possible to write more than one array value at a time with a single command to improve performance? I'm looking for something similar to Block Copy functions in C/C++/C# that take a list/array/pointer to values and a number of values to copy.

xerim

It would appear that this is the intended functionality as to not exceed the RAPID data limit of 1024 bytes.

I found this in the Release Notes for the FlexPendant SDK 6.01