Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 31 May 2002 15:38:59 -0600

Arne,

I think I may see the cause of your troubles, but a definitive solution
will probably be delayed until the person maintaining the interface of
EPICS R3.14 to POSIX returns from vacation.

Here are the boring details for all who are interested.

In EPICS R3.14 there is a small code that interfaces EPICS to POSIX
compliant operating systems. It appears that your problem occurs in the
following code fragment.

  Some code calls this function
    epicsEventWaitStatus epicsEventWaitWithTimeout
       (epicsEventId pevent, double timeout)
  The current time is fetched into an epics time stamp 
  This epics time stamp is converted to a struct timespec
  A small offset based on the specified "timeout" argument is added to 
    this struct timespec
  The resulting struct timespec is passed as the absolute time timeout

    argument to pthread_cond_timedwait()

When an epicsTime is created from a date just prior to the epics epoch
it creates an epics time stamp with a seconds field that is just about
to roll over. This will produce the correct result if an epics time
stamp just before the epics epoch is subtracted from an epics time stamp
just after the epics epoch. 

However, in this situation we are mapping from an epics time stamp to a
struct timeval and it looks like the code is incorrectly guessing that a
seconds field that is just about to roll over is very long after the
epics epoch and not just prior to it, and we get an absolute time
timeout argument for pthread_cond_timedwait() which is very far in the
future. It's probably difficult to make a better guess if we allow for
this part of the EPICS to survive that far in the future. Fat chance of
that :-]

In any case, the most reliable solution for this specific problem may be
to, only in this POSIX specific portion of the code, maintain absolute
time in native POSIX time format.

Jeff

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Friday, May 31, 2002 12:30 PM
To: epics tech talk
Subject: epics-3.14/seq2.0.2 on pc104 card running linux

We've been playing around with the latest  epics base (3.14) and
seq2.0.2 on a pc104 card running linux.    We've been having difficulty
getting the sequencer to work.  At first we thought is was due to  some
incompatibilities between the desktop linux machine that compiled the
code and the pc104 card.   After many "printf" insertions into the
code,  we found that sequencer was getting stuck in
pthread_cond_timedwait. 
Printing out the tv_sec and tv_nsec  elements of wakeTime  showed that
we had the wrong date set on the pc104 and the tv_sec element was
returned as a negative value from convertDoubletoWakeTime. 
Correctly setting the date, fixed the problem...... 
Not sure what the moral is,  nor have I looked into
convertDoubletoWakeTime to see if the code can be fixed to work with
unreasonable "pre-epics-epoch" dates. 
Make sure  your ioc's boot with the correct date........ 
Arne

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System