Hi,
> 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.
>
Take care with processing the motor record after IOC init. It could easily cause the motor to move if the motor record has a position different from what's currently on the controller.
Cheers,
Matt
> 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]>; tech-
> [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
> >
- 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
- Navigate by Date:
- Prev:
Re: connection timeout between ioc and logstash Johnson, Andrew N. via Tech-talk
- Next:
Re: connection timeout between ioc and logstash 吴煊 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:
SynApps 6-1 Released Lang, Keenan C. 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
|