Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Linux time stamping
#1
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
Reply
#2
You might want to refer to this thread:

http://forums.deltatau.com/showthread.ph...hlight=NTP
Reply
#3
This code will get time since epoch with nanosecond resolution. You can convert to milliseconds and round first if you want.

Code:
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.
Reply
#4
(10-11-2017, 08:16 AM)DaveBarnett Wrote: You might want to refer to this thread:

http://forums.deltatau.com/showthread.ph...hlight=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
Reply
#5
(10-11-2017, 12:58 PM)Eric Hotchkiss Wrote: This code will get time since epoch with nanosecond resolution. You can convert to milliseconds and round first if you want.

Code:
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
Reply
#6
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.
Reply
#7
(10-12-2017, 04:42 PM)Eric Hotchkiss Wrote: 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
Reply
#8
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.
Reply
#9
Also, note that the Linux “gettimeofday()” function has several arguments. Verify your arguments and types.

You must also include “sys/time.h”.

Please refer to your Linux documentation for details.
Reply
#10
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
Reply
#11
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.

Code:
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);
}
Reply
#12
(06-10-2019, 11:34 AM)Eric Hotchkiss Wrote: 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.

Code:
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
Reply
#13
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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)