Jump to content
OMRON Forums

Linux time stamping


Steven Beaumont

Recommended Posts

I have been working on capturing encoder positions and logging it relative to real world UTC time.

I have the Linux operating system synced to a ptp time source but the only access to this time I have found is the C++ code "time()" which give time as an integer in seconds, is there a method to get sub second time from within C code, I am looking for at least millisecond resolution anything better would be a plus.

I have already tried to use "ftime()" but found it crashed the system.

any help here would be appreciated.

 

Regards

Steven

Link to comment
Share on other sites

  • Replies 14
  • Created
  • Last Reply

Top Posters In This Topic

You might want to refer to this thread:

 

http://forums.deltatau.com/showthread.php?tid=2518&highlight=NTP

 

Sorry I have already passed the stage of getting time synchronised to a master clock.

Since my last post I have also got system time from the Linux operating system using C code, thank you for replying anyway.

 

Regards

Steven

Link to comment
Share on other sites

This code will get time since epoch with nanosecond resolution. You can convert to milliseconds and round first if you want.

 

struct timespec start;
clock_gettime( CLOCK_REALTIME, &start);
return(start.tv_sec+start.tv_nsec/1000000000.0);

 

It should be added to the NTP app note soon.

 

Thanks used this code but it locked up system if it is run on every plc cycle

 

struct timeval MyTimeVal;

gettimeofday(&MyTimeVal, NULL);

 

Which code would be best in your opinion.

 

Regards

Steven

Link to comment
Share on other sites

I found that clock_gettime() works perfectly on a CK3E, but when I take it over to a UMAC 460 CPU I'm freezing up my CPU as well.

 

Please send an email to support@deltatau.com with your CPU type and how you're calling the function (CPLC, PLC calling CfromScript, etc) so I can make sure the solution I find will work for you.

Link to comment
Share on other sites

  • 1 year later...

I found that clock_gettime() works perfectly on a CK3E, but when I take it over to a UMAC 460 CPU I'm freezing up my CPU as well.

 

Please send an email to support@deltatau.com with your CPU type and how you're calling the function (CPLC, PLC calling CfromScript, etc) so I can make sure the solution I find will work for you.

Hello Eric,

 

right now I'm observing some freeze problems, too.

Ath the moment I'm far away from the PMAC in question, and have only another with some different cards in it (no ACC65E, ACC72EX, only one ACC24E3,2 channel instead of 3x4 Channels). So it is difficult to reproduce...still I try to find the reason.

 

Since I'm experiencing the same problems and using these methods, too:

Dind you find any reason for this problem? Or do you have at least found a solution for this problem?

 

My usecase right now:

PMAC UMAC, 465 CPU dual core

I'm calling 'gettimeofday' from RTI Cplc, background C programs and I'm also using the custom threading library.

Also in the linux part there is a chrony daemon running which updates the time.

 

Since a few days I have increasing problems with freeze/lockup/software watchdog trip or something else. Even with a state of the project which was once quite stable.

 

So if You have found the reason why the 'gettimeofday' is locking up the PMAC, this might be helpful debugging my problems.

 

Right now I'm just putting some of the programs on another PMAC I have available right here, but the Projects are too different so it is difficult to reproduce these errors.

 

Perhaps you have some idea,

Georg

Link to comment
Share on other sites

I can't compile with the name GetTimeOfDay(), but I am able to run a bgcplc 0 with only "pshm->P[0]=GetPMACTimeOfDay();" for contents on an otherwise empty 465 CPU running firmware 2.5. Do the freezes only show up in IDE communication?

 

At default settings this seems to increase my background CPU load by about 20%. What is your CPU load like? Perhaps adding a delay in the bgcplc or increasing Sys.BgSleepTime could help resolve the issue.

Link to comment
Share on other sites

Edit: found one problem, for the critical "quick freeze": I added one GoBack on the wrong position and wrong value...

But the freezes after a while might still be there (in the range 1+hour, but not critical for now).

 

I is too much offtopic now here, since gettimeofday() is most likely not the problem.

But is there a possibilty to PM one of you guys to discuss some more details which I'm using and perhaps not in a way it should be used, which might cause the sudden problems?

 

original text

=======

Hello,

 

I'm using inside the "Linux background programs" and inside RTI CPLC the "gettimeofday()" from 'time.h'.

 

this works so far and worked well until last week.

 

My CPU load did not show any problematic signs...

the Symptomes are like: PMAC Linux unresponsive, so no SSH or so. But (some) PLCs are working. I have one PLC which only toggles an LED on the ACC65E, which is still happily toogling away while the SSH Part freezes. (not always, but I did not systematically watch all things...this I start today ;) )

 

Regarding the freeze problem and the time:

I tried to reproduce it on another PMAC, but this one has no ACC65E and no ACC74EX with canbus.

I could not get it to freeze there. So Right now I'm quite sure that none of my background Programs (using the manually scheduling library and TCP/UDP sockets) or the gettimeofday() inside RTICPLC.

 

It could perhaps be some problem in combination with the CanBus or other stuff ,which is only available here at this specific PMAC.

 

At the moment I'm trying to put an old version of the project on the PMAC, which did not freeze (at least not after 20 minutes). Perhaps I find the problem.

 

Well, long story short: right now there is a chance that the freezing here has nothing to do with the gettimeofday().

But I was hoping Eric did find some "good to describe problem" which perhaps lead to a solution at my place, too.

 

 

 

Greetings,

Georg

Link to comment
Share on other sites

I see my issue, I assumed you were using one of the functions in the app note. Now I have time.h included and gettimeofday working.

 

I don't see any problems running a bgcplc that does nothing but call that function on a 465. It introduces maybe 15% background cpu load with default clock speeds (besides bgcplc0, my project is default).

When I try to do the same thing on a 460, PMAC immediately seems to die (in the IDE) and a few seconds later I hear and click and get a watchdog.

I was able to stop the watchdog by adding a delay.

 

It sounds like you are running this in a few places, have you tried one at a time to isolate it?

Have you tried adding a delay?

MySleepSec(0.100); will work after the following functions are compiled.

 

struct timespec Sec2TimeSpec(double TimeSec)
{
struct timespec Timer;
Timer.tv_sec = (long int)TimeSec;
Timer.tv_nsec = (long int)((TimeSec-(double)Timer.tv_sec)*1000000000.0);
return Timer;
}
void MySleepSec(double SleepTimeSeconds)
{
struct timespec Timer;
Timer = Sec2TimeSpec(SleepTimeSeconds);
nanosleep(&Timer,NULL);
}

Link to comment
Share on other sites

I see my issue, I assumed you were using one of the functions in the app note. Now I have time.h included and gettimeofday working.

 

I don't see any problems running a bgcplc that does nothing but call that function on a 465. It introduces maybe 15% background cpu load with default clock speeds (besides bgcplc0, my project is default).

When I try to do the same thing on a 460, PMAC immediately seems to die (in the IDE) and a few seconds later I hear and click and get a watchdog.

I was able to stop the watchdog by adding a delay.

 

It sounds like you are running this in a few places, have you tried one at a time to isolate it?

Have you tried adding a delay?

MySleepSec(0.100); will work after the following functions are compiled.

 

struct timespec Sec2TimeSpec(double TimeSec)
{
struct timespec Timer;
Timer.tv_sec = (long int)TimeSec;
Timer.tv_nsec = (long int)((TimeSec-(double)Timer.tv_sec)*1000000000.0);
return Timer;
}
void MySleepSec(double SleepTimeSeconds)
{
struct timespec Timer;
Timer = Sec2TimeSpec(SleepTimeSeconds);
nanosleep(&Timer,NULL);
}

 

Hello Eric,

 

Yes, I use it at different locations.

And yes, in this project I can avoid it and call it at a central place.

I tried to reduce these calls allready before your answer. So perhaps this is the reason why the "long time freezes" don't appear that much anymore.

If you could reproduce these problems, then I'm hoping that these also relate to my problem.

After all these "freezes after some longer time" were not here in the beginning. They appeared somewhere while wrinting the rest of the programs, so chances are that they got in when I implemented the timestamping.

The whole observation of these freezes calls for something like "not enough pause" and "timing issue".

 

I will try to reduce the calls to that function more.

On a different project I make timestamping in combination with ServoCount, clockspeed and some defined "time to servocount mapping"...This way I could reduce it further to calling it about once every seconds and make the rest with Sys.ServoCount.

 

Thanks for your Help,

Georg

Link to comment
Share on other sites

  • 2 months later...

Is there a reason you are using gettimeofday? I added some timestamps to my program and GetPmacTimeOfDay seems to take about half as long. It also doesn't watchdog my 460 cpu if I run it with no delay.

 

Hello Eric,

 

sorry for the late answer. I just did not notice that there were news in this topic.

 

actually I'm not sure if I did not find this function until now or did discard it, because it sometimes returned the wrong time.

There is a big problem with "initial startup" and some time functions on the PMAC.

 

(sidenote: another problem is timespec and timeval. timespec should return nsec but actually returns usec like timeval...and I do not mean 1usec = 1000nsec ;) )

 

I have no clue how fast some ntpdate or chrony must set the linux clock at boot time, in order to get the correct time with for example "GetPmacTimeOfDay".

 

I checked multiple times right now.

1. The times differ for nearly a year or so, if it was not fast enough synced on boot.

That means always after "cold boot" I have not the correct time with GetPmacTimeOfDay.

 

Every "build and download" of changes did not change this beheaviour. In this state only a $$$ worked after the linux clock was set to get the correct time.

 

2. What makes it worse: it drifts away.

I did call both at the same method time in rticplc.c.

Afther that i substracted the times and got a increasing difference.

Right now I had -0.72, which means gettimeofday is about 0.7 seconds ahead of GetPmacTimeOfDay.

 

Long story short: After these tests I can say that GetPmacTimeOfDay ist not usable for our needs here right now.

 

Do you have an solution for this?

I could of course get time with gettimeofday. Compare it than to GetPmacTimeOfDay. And when they are not in sync I could issue $$$ from a PLC to restart the firmware. But this does not look like the "right way".

Link to comment
Share on other sites

Please take a look at our NTP App Note.

http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Application%20Notes/Network%20Time%20on%20Power%20PMAC.PDF [FILE REMOVED]

 

Take a look at page 8 of the app note under Ntpdate. This shows how to install Ntpdate. Then take a look at Ntpdate on page 10. Installed Ntpdate should be enough to get the power on time correct in PMAC.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...