Hi, 

There are 2 ways to send commands to the robot.

A ) One of them is to send a whole file of script that will be fully treated before running. This is probably not the way you use but I cannot be sure unless you share your code. This way is quite variable in time before start as it depends on the process time to prepare your code for execution (alike runtime). This case can be estimated with the trick I give at the end. 

B ) The other way is to send single script command. I believe this is what you do. You ask a moveJ motion up to a position that the current Tool Center Point (TCP) will move to reach. You can set T for time to achieve the travel or acceleration and velocity. This one will only take 1 command at a time and might consider multiple command sent as a sequence. For the delay, we do not use much of this kind of control so it can be tested with the same trick. I expect to have setup dependent effect and that no static delay is available. It probably depends on the frequency of the socket scrutation that might depend on the main loop frequency. CB and eSeries Universal-Robots are not at the same Hz, eSeries are 500 Hz for example.  

Trick: You Send to the robot a command you can track from the control system. For example, you can send a move to type "Space" or "Enter" key or any other key of your choice. To avoid movement delay you can send a socket response. Again you might have a little latency from network delay. But in both cases, you shall have an estimate of the delay after the command are sent. 
The idea of this trick is to sync with feedback up to where the command came at first. I do not expect the initial timing to be perfectly identical from time to time. I would call it a short moment. See that, in this case, the moment is undetermined and can be between a few milliseconds to some seconds. 

Hope I do not break a deterministic approach. 
Socket or I/O feedback can be a good way to sync. 

Enjoy socket control on your UR. 

Regards,

David Gouffé
Integration Coach
Coach en intégration