Hello everyone.

I'm trying to measure the cycle time of a process using a UR10.
My idea was to get the time at the start and at the end of the process and calculate the elapsed time with it.

The problem is that it seems there is no function that returns the time ( or at least I couldn't find it in the script documentation ). I was trying to overcome this problem connecting to the real time interface and read the timestamp from there, but then again, there is not a function to read binary floats.

Any ideas on how to get the time?

We want to be able to do it only with the robot. We want to avoid using an external computer to ask for the time.

Simply measuring the time with a clock is not acceptable as it is needed to obtain precision values.

There is not a time function on the robot. Here's how you to it though. Place a thread in the program and in that thread you place the following. 

time=time+.008
sync()

I=0
goodPart= False
Loop I<3 or digital_input_0 not true
  I=I+.008
   sync()

if i<3 
   goodPart = True

First of all, thanks for the answer.
It seems that is the best way to do this kind of things without having a proper time function in UR.

The downside is that it doesn't deliver very accurate results and it is dependant on the program because the threads management overhead.
In a sample program, with only time calculation and a simple cyclic movement between two points there was a 5 seconds delay in just 2 minutes of execution. In the process that I want to measure the 5 seconds delay was already present at 1 minute of execution.

Anyway, even not perfect, is enough for our case, but if someone else needs really accurate readings should search for another solution. I hope UR will include this kind of function in the future as other robot manufacturers do.

@jmagdaleno you may want to check your code or how your manually timing it again. We see very accurate results using this method. All of our robots run cycle timers on background threads as well as wait timers anytime the robot is waiting on humans, equipment or the process. We use these times for billing purposes and so accuracy is a must. For instance I just timed one of our production robots and the stopwatch had 297.54 versus the timer value of 297.616.  I timed it a couple of times with similar results.  To give you an idea, this program is running 13 background threads currently controlling a vision system as well as 7th axis of motion and is placing 72 parts in that cycle time. 

Not sure if this matters but background threads do not start running until the program gets into the actual robot program, if you're hitting start on the watch when you hit play that's not an accurate method of timing.  If you have code in the before start section that code must finish executing before the threads start.

If we have instances where we need very precise time we make an xmlrpc call to a server we have attached to all of our robots and return the current epoch time, that gives us a time down to the ms. 

I checked it again and it is as accurate as you say. I was not doing the manual timing in a good way.
Thanks again for the help Matthewd92.

You're welcome. Glad I could help. 

I have used the timer example above and it works well until the operator breaks the light curtain, then the program along with the timer pauses. 

You can access the clock or the time the UR has been powered on through RTDE 'timestamp'.  IS there any way to use this feature as a variable or is there any other way around this?

The clock seems like such a no-brainer basic feature to allow programmers to reference I'm surprised they make it so difficult (or impossible) to access it.

The only way we have found to have a real clock currently is to use a RPC server. We have a getTime() function that returns the current epoch time from the server. You could prop up a server fairly easy on the network and then get the time from there using xmlrpc