Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Mon, 30 Jun 2014 13:40:07 +0200

On Friday, June 27, 2014 17:34:58 Mark Rivers wrote:
> I took a quick look, and it seems like all of the other asyn device
> support the initCommon sets pact=1 and returns -1 if there is an
> error in processing the drvUser or other calls.  However, the
> record-specific initialization functions that call initCommon
> (initAi, etc.) immediately return 0 rather than the error return from
> initCommon in case of a failure.  Thus the init_record function in
> aiRecord.c does not get an error return.  This seems wrong to me, but
> Marty wrote it so it needs to be looked at carefully to see if it is
> OK.

I think setting PACT=1 and returning -1 is the right thing. If you do
not return -1, then record support thinks initialization went ok, and
might set UDF to 0; at least some record types do so, IIRC. Setting PACT
effectively disables the record, so it will remain in UNDEFINED/INVALID
state, which makes sense IMO.

> The devAsynOctet code is different from all of the others.  It does
> not call drvUserCreate in initCommon, but in another function
> initDrvUser, which as you said does not set pact=1 on error.  Some of
> the record-type specific functions call initDrvUser and some do not.
> I don't understand this, it seems like they should all call be
> processing the drvUser field, and so this should be put into
> initCommon like it is for other device support.
>
> I'm happy to have you look at making this more consistent.
>
> Mark
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> [email protected] Sent: Friday, June 27, 2014 12:01 PM
> To: [email protected]
> Subject: What to do when device initialisation fails
>
> All,
>
> What is the correct thing to do when a bad link name is encountered at
> initialisation?
>
> We recently had a problem when an string parameter was badly named in
> the OUT link of  stringoutRecord of an areaDetector device. This
> printed an error message at start up (which no-one saw) but didn't
> disable the record and subsequent writes to the record (by
> autosave/restore) trashed the first parameter in the device (which
> was also a string). I don't think this is the right thing to do.
>
> The rough call chain at the time of the problem is that iocInit
> initialises the record by calling:
>
> prec->rset->init_record (i.e. init_record in stringoutRecord.c)
>   prec->dset->init_record (i.e. initSoWrite in devAsynOctet.c)
>     initDrvUser in devAsynOctet.c
>        ...
>        asynPortDriver::drvUserCreate in asynPortDriver.cpp
>
> The bottom routine prints an error message because it can't find the
> parameter and returns bad status but doesn't change
> pasynUser->reason.
>
> Then initDrvUser also printed an error, but couldn't do anything more
> since it is a void function. Hence the record didn't know there was a
> problem and believed that initialisation had succeeded.
>
> If it did return an error it could propagate it up to the initSoWrite
> function which has access to the record structure and so could change
> the value of fields or return an error to record support. If record
> support gets an error it returns it to iocInit, but otherwise ignores
> it. iocInit then ignores any bad status.
>
> The options are:
>  - set the reason to -1 and check for it in asynPortDriver so any
> subsequent write fails. - change initDrvUser to return a status and
> disable the record somehow (or set it to Soft Channel) in device
> support, record support or iocInit.
>
> In similar circumstances devAsynInt32 tries to disable the record by
> setting pact to 1 and returning a bad status - is this the right
> thing to do? I looked at various other device drivers and consistency
> wasn't a feature. Some called recGblRecordError, but this only prints
> a message, doesn't disable the record.
>
> I know that consistency in device support isn't one of EPICS's
> features, but if we could decide on a reasonable approach I would be
> happy to make asyn adhere to it...
>
> Cheers,
>
> Nick Rees
> Principal Software Engineer           Phone: +44 (0)1235-778430
> Diamond Light Source                  Fax:   +44 (0)1235-446713

--
"Make it so they have to reboot after every typo." ― Scott Adams

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System