Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 27 Jun 2014 17:34:58 +0000

Hi Nick,

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. 

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

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System