Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 18 Jun 2013 14:04:10 +0000

Hi Ralph,

> B) The PINI field menu currently has 6 options:
> NO, YES, RUN, RUNNING, PAUSE, PAUSED.
> What is the intended behavior for the four options that were not yet mentioned in this thread?

Before I sent my post I searched the latest version of the Application Developers' Guide for the description of PINI.  This is the only mention of PINI in that document.

************************************
7.4.10 Initial Processing
initialProcess processes all records that have PINI set to YES.
initHookAfterInitialProcess is announced.
************************************

What are the intended meanings of the other values of PINI and where is that documented?

> 1. DB is dominant, takes value from DOL or AutoSaveRestore, and writes to the device.

That would be achieved with PINI=YES.  With an asyn driver and standard asyn device support this requires that the driver return asynError on an attempt to read the value before interruptAccept=TRUE.

> 2. DB is recessive, reads value from device.

With an asyn driver and standard asyn device support this requires that the driver return asynSuccess on an attempt to read the value before interruptAccept=TRUE, assuming it did successfully read the device.  The value must not be in AutoSaveRestore, or that value will replace the value read from the hardware.

> 3. DB is minimal invasive, takes value from DOL or AutoSaveRestore, and
> does not interact with the device.

That would be achieved with PINI=NO.  With an asyn driver and standard asyn device support this requires that the driver return asynError on an attempt to read the value before interruptAccept=TRUE.

These comments above apply to the IOC start or restart.  

In case of my proposed solution #3 on a device reconnect this is modified as follows:

> 1. DB is dominant, takes value from DOL or AutoSaveRestore, and writes to the device.

That would be achieved with PINI=YES.  The current value in the record will be written to the device on a reconnect.

> 2. DB is recessive, reads value from device.

That would be achieved with PINI=NO.  On reconnect the value is read from the device and put into the record.

> 3. DB is minimal invasive, takes value from DOL or AutoSaveRestore, and
> does not interact with the device.

This is where the single-bit for PINI has a problem.  How do we indicate the the record value should be preserved and the value should not be read from device?

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Ralph Lange [[email protected]]
Sent: Tuesday, June 18, 2013 6:21 AM
To: EPICS Tech-Talk
Subject: Re: EPICS device disconnects and reconnects

Hi Mark,

I have a comments and a question on this topic:

A) From my experience, there are three possible options to handle the
reconnect/reboot situation, that all have valid use cases:

1. DB is dominant, takes value from DOL or AutoSaveRestore, and writes
to the device.
2. DB is recessive, reads value from device.
3. DB is minimal invasive, takes value from DOL or AutoSaveRestore, and
does not interact with the device.

I am not sure how a single bit could encode these three options.

B) The PINI field menu currently has 6 options:

NO, YES, RUN, RUNNING, PAUSE, PAUSED.

What is the intended behavior for the four options that were not yet
mentioned in this thread?

Thanks,
~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System