Experimental Physics and Industrial Control System
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 <[email protected]>
Sent: 16 August 2019 07:45
To: Oram, Dominic (STFC,RAL,ISIS) <[email protected]>; [email protected]
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
>
- Replies:
- Re: Undefined Timestamp on Motor Record Johnson, Andrew N. via Tech-talk
- Re: Undefined Timestamp on Motor Record Torsten Bögershausen via Tech-talk
- RE: Undefined Timestamp on Motor Record Pearson, Matthew R. via Tech-talk
- 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
- Navigate by Date:
- Prev:
Re: Undefined Timestamp on Motor Record Torsten Bögershausen via Tech-talk
- Next:
Re: connection timeout between ioc and logstash J. Lewis Muir 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
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Undefined Timestamp on Motor Record Torsten Bögershausen via Tech-talk
- Next:
Re: Undefined Timestamp on Motor Record 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
<2019>
2020
2021
2022
2023
2024