Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: Undefined Timestamp on Motor Record
From: Torsten Bögershausen via Tech-talk <tech-talk@aps.anl.gov>
To: "Johnson, Andrew N." <anj@anl.gov>, Dominic Oram - UKRI STFC <dominic.oram@stfc.ac.uk>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 16 Aug 2019 18:13:32 +0200
Thanks Andrew for the long explanation -
I managed to send my stuff before I received your email.

To answer that question, the motorRecord
set the UDF in one situation:

    /*** Collect .val (User value) changes from all sources. ***/
    if (pmr->omsl == menuOmslclosed_loop && pmr->dol.type == DB_LINK)
    {
        /** If we're in CLOSED_LOOP mode, get value from input link. **/
        long status;

        status = dbGetLink(&(pmr->dol), DBR_DOUBLE, &(pmr->val), 0, 0);
        if (!RTN_SUCCESS(status))
        {
            pmr->udf = TRUE;
            return(ERROR);
        }
That is well-documented, I think, and makes sense to me (now).

Dominic,
can I have a look at your source code?
I may have an idea why you see the undefined time stamps, may be
/Torsten


On 16/08/19 17:57, Johnson, Andrew N. wrote:
A record type gets to decide for itself (by the code that implements it) what it means to be Undefined, and as Dominic describes there can be more than one kind of undefinedness.

All records start out in a UDF_ALARM state, that being the initial value of the STAT field, although the record type can change that during record initialization and it may also be cleared if PINI is set. In earlier days a record in UDF/Invalid Alarm state had probably never been processed, so it also had an <undefined> time-stamp, and users often thought the two were linked. However at some point we added code to the Base ai/ao/calc type records to set their UDF field and raise a UDF alarm when their VAL field holds a NaN value, so the UDF field is no longer related to whether a record has ever processed. More recently we added the UDFS field to all record types so the alarm severity of a UDF alarm can be configured.

If a record's time-stamp is <undefined> that actually means the TIME field contains (0,0) which is the initial value of that field, implying the record has never set its time-stamp which it usually does some time during record processing. Some record types such as seq and probably the motor record set their time-stamp more than once during processing because it takes an extended period of time to finish an operation. There are also several ways for the record or device support code to obtain a time-stamp value (which doesn't have to be the current wall-clock time), although the TIME field can't be written to directly at runtime using a link or via CA or PVA.

The motor record does have code that sets and clears the UDF field and raises a UDF alarm, although I don't know the exact circumstances in which it does that, hopefully it's documented...

- Andrew


On 8/16/19 4:54 AM, Dominic Oram - UKRI STFC via Tech-talk wrote:

Hi All,

Thank you for all the suggestions.

Writing to the PROC field after iocInit or setting PINI to 1 both fix the issue. As does setting motorStatusCommsError_ to 0 first then to 1. So I will do one of these.

Torsten, the initial state I see isn't actually a conventional UDF state. The UDF field is 0 and there are no alarms on the PV. The only way of telling that it's in this state is that the timestamp is invalid. If it was a normal UDF state I would be happy just leaving it as the alarms will propagate through to the user. In the timestamp invalid state it's not obvious that there is an error. Are you instead seeing a normal UDF state?

Thanks,
Dominic

-----Original Message-----
From: Torsten Bögershausen <torsten.bogershausen@esss.se><mailto:torsten.bogershausen@esss.se>
Sent: 16 August 2019 07:45
To: Oram, Dominic (STFC,RAL,ISIS) <dominic.oram@stfc.ac.uk><mailto:dominic.oram@stfc.ac.uk>; tech-talk@aps.anl.gov<mailto:tech-talk@aps.anl.gov>
Subject: Re: Undefined Timestamp on Motor Record



On 15/08/19 19:16, Dominic Oram - UKRI STFC via Tech-talk wrote:


Hello,

I'm in the process of writing a model 3 motor driver using version 6-11 of the motor record.

I have found some unexpected behaviour on initialisation if the driver has no device connected.

It appears the motor stays in the following state unless a parameter is updated at some point after initialisation (I'm not sure when):

caget -a MOTOR
MOTOR        <undefined> 0

If I have no device connected I set motorStatusCommsError_ to 1 on the first call to poll(). However, because all subsequent calls to poll() do not change any parameters I stay in the above state. I would instead expect to see something like:

caget -a MOTOR
MOTOR        2019-08-15 15:57:41.931650 0 COMM INVALID

as in the undefined timestamp situation it's not obvious to users that there is a comm error.

Setting motorStatusCommsError_ to 1 at some time after initialisation does give me the expected state.

Is this actually expected behaviour?


May be, may be not.
My understanding is, that all EPICS records stay in "undefined" state (UDF) until the device support is able to talk to the device.
In that sense the "undefined" state is OK.
(And this is what we do with motors here at ESS,
   never connected -> undefined.)

  > Do other people see something similar?
Yes, fully reproducible here.
I think that easiest solution is to do a workaround like this:

    status = initialPollInternal();
    if (status != asynSuccess) {
      setIntegerParam(pC_->motorStatusCommsError_, 0);
      setIntegerParam(pC_->motorStatusCommsError_, 1);
    }




Thanks,

Dominic Oram
Senior Software Engineer
Experimental Controls
ISIS Neutron and Muon Source




--
Complexity comes for free, Simplicity you have to work for.


References:
Undefined Timestamp on Motor Record Dominic Oram - UKRI STFC via Tech-talk
Re: Undefined Timestamp on Motor Record Torsten Bögershausen via Tech-talk
RE: Undefined Timestamp on Motor Record Dominic Oram - UKRI STFC via Tech-talk
Re: Undefined Timestamp on Motor Record Johnson, Andrew N. via Tech-talk

Navigate by Date:
Prev: Re: Undefined Timestamp on Motor Record Torsten Bögershausen via Tech-talk
Next: Re: connection timeout between ioc and logstash Johnson, Andrew N. via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: Re: Undefined Timestamp on Motor Record Johnson, Andrew N. via Tech-talk
Next: Re: Undefined Timestamp on Motor Record Torsten Bögershausen via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 16 Aug 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·