How to obtain the current time

jmagdaleno · February 2017

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.

matthewd92 · February 2017

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()

The sync command takes up a time slice of robot time which is processing at 125 Hz or 8 milliseconds.

Then in your program you can get the time at the start of a process and the end by simply referencing this value. we do cycle timers by simply setting time to 0 at. The start of the process and then grabbing the time at the end of the process. I also do similar things for wait timers when I want the robot to wait for instance both a time or an input to happen. An instance of this is wenfite a camera for a feature verification. The camera gives us an OK input if the feature is present but nothing if it's not present so I want to wait for either the output to fire, good part, or a specific time to expire, bad part. So we do something like

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

if i<3 
   goodPart = True

That will cause the program to wait for either the timer to exceed 3 seconds or the input to fire. Once the loop ends if the time is less than 3 seconds then the input must have fired so we have a good part

jmagdaleno · February 2017

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.

matthewd92 · February 2017

@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.

jmagdaleno · February 2017

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.

matthewd92 · February 2017

You're welcome. Glad I could help.

Cessna · March 2017

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.

matthewd92 · March 2017

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

Discussion

How to obtain the current time

Best Answer

Comments