DoF - a Robotiq Community
Warning sign
The Dof Community was shut down in June 2023. This is a read-only archive.
If you have questions about Robotiq products please reach our support team.

So here is where it can get a little the robot is operating at 125 Hz or every 8 milliseconds (ms).  Which means every 8 ms the controller is sending a command to the robot, when it is moving you are actually seeing thousands of points stitched together in 8 ms time slices, this is the physical time of the robot. When you are sending commands like this program does those can be processed in less than 8 ms so there is a chunk of time where nothing is happening and the robot is looking for that time to be consumed, hence the sync() command.  So in this instance lets say that turning on an output only takes 1 ms to execute the command, when I am turning on 4 outputs I would only be taking up half of the time of that physical slice of robot operating time, so I need to get my operation back in sync with the robot, so I use sync().  The other option is to use a wait command (if you are using URScript it is the sleep command) and give it at least 8 ms to wait.  The difference is this will always wait 8 ms, so in that scenario above the fastest my script could run would be every 12 ms, not 8 ms.  Once you can get your head around that issue everything else becomes easier.

The reason that you see a delay in the video probably has more to do with the simulator than the timing between events occurring.  The actual outputs on the robot are pretty darn fast, we actually had to put delays between the outputs turning on when dealing with safety systems so that the safety system could see the small lag, less than 100 milliseconds, and not think that someone had wired the two palm buttons together.  I feel like I have seen somewhere the actual specs for turn on and off time but I can't seem to find it quickly.

I know when we fire two outputs at the same time you can't see it happening with the naked eye, however scientific that is.

As far as EthernetIP or ModBus they are going to be slower, we have had issues in the past with modbus inputs on a punch press where we could not reliably see the input signal on the robot because it was happening too fast for the modbus communications to get it to us, we wired it directly to the robot and have since made over 500,000 parts without ever missing an event.

@Stefan_Stubgaard do you have any actual specifications on how fast the on board IO is compared to EthernetIP/ModBus/Profinet?


mbaril said:
Thanks Matthew for the clarification!
Thats what we are all here for.  Glad that it helped.