Experimental Physics and
Industrial Control System

Hi all,

   I wish to add more technical information on what I posted on Fri., July 26
at http://www.aps.anl.gov/epics/tech-talk/2013/msg01529.php
because technical discussions should be posted at [email protected]
to inform the author and users.

As one can see from the E-mail below, which I wrote on 07/19/2013 11:03 AM, I have
originally proposed:

> B)  For the camera's input records, the I/O interrupts should be called in the driver's
>     connection callback function to process them so that the alarm status will be updated
>     on those input record.

However, on Fri., 19 Jul 2013 16:12:21 -0400, one replied to me :
> Posting an EVENT would be the appropriate solution for I/O Interrupt scanned records,

Did I miss something ?  How could that be appropriate ? Does one meant to say I/O interrupt
event ? If so, it is the same as what I proposed originally in B).  My understanding is that I/O Interrupt
scanned records are not activated by post_event(). If one prefers to solve it via database, a better
alternative is to incorporate an EVENT post with the fanout/forward links. The solution was presented in
ADBase.template.diff at http://www.aps.anl.gov/epics/tech-talk/2013/msg01529.php

Regarding the output records, originally I have proposed to add the linked list at the IOC
level because on 6/11/13, Mark Rivers discussed offline about the option of reconnecting a camera of
a different model. This is possible because one can easily modify the IP address or the ID of a different
camera in model to match with that of the corresponding ASYN records.  In that case, it would be on the
safe side to set the values of the output records to match the new values of the camera. 

On 6/11/13, I replied:
> Regarding when the camera is reconnected, I think that the software should detect if it is the same camera model.

BTW, the patch I proposed on Fri., July 26 is a prototype I wrote to quickly carry out the concept I have
proposed so far among the IOC level, database, and GUI.  I understand that ASYN drivers have its own software
structure that only the devEpics/* should handle the EPICS record. However, the software structure can be
fine-tuned once the prototype is written and tested successfully.

In conclusion, what I have proposed via the IOC level (and possibly via the database) would have appropriately fix
the application to reflect connection issues. Every record that connects to the device will have an alarm severity
of invalid and will show the status in the display.  See disconnected.jpeg from
http://www.aps.anl.gov/epics/tech-talk/2013/msg01529.php

Best,
Kate Feng

*************************************************************************************************************

-------- Original Message --------
Subject:     Re: clear statement that the two camera solution was accepted
Date:     Fri, 19 Jul 2013 11:03:02 -0400
From:     Kate Feng <[email protected]>
To:     Dalesio, Leo <[email protected]>

Hi Bob,

    Thank you for your follow-up note.  Attached is the updated document, which I have added
the section VII) for the conclusion. I will send Mark Rivers the following :

A) At NSLS2, we have decided that at the reconnection/disconnection of the cameras,
the values of all the records should be processed to be the same as what was set
previously by EPICS users before the camera was disconnected. By doing so, the alarm
status of the records will be updated, too. One exception is that the 'Acquire' (i.e. busy)
record should always be reset to be 0 (i.e. off) at the reconnection/disconnection. This
can be achieved either

  1. by creating an event-driven binary input (i.e. bi) record, which will read
the status of the camera's connection/reconnection (i.e. AsynIO.CNCT), when the event is generated
in the driver's connection callback function. Via this bi record, the EPICS fanout records can forward
the processing link to the camera's corresponding output records. The driver should reset the value of
all the busy records (e.g. the 'Acquire' record for the cameras) to be 0 before the event was generated
when the camera is disconnected or reconnected.

 or
  
 2. by keeping a link list of pointers to all the record that need to be processed at
    disconnection/reconnection, and call 'dbpf' to process them in the driver's connection callback function.
    The driver should reset the value of all the busy records (e.g. the 'Acquire' record for the cameras) to
    be 0 .

B)  For the camera's input records, the I/O interrupts should be called in the driver's
    connection callback function to process them so that the alarm status will be updated
    on those input record.

C) To be precise and be consistent with other ASYN software written in asyn4-21/asyn/devEpics/*.c,
the busy record (e.g. for the Acquire on/off record) should set EPICS alarm status to be “COMM”
instead of WRITE_ALARM, when the device is disconnected. The ASYN ao, asynFloat64, bo, lo,
and mbbo records written in the directory asyn4-21/asyn/devEpics ( see devAsynInt32.c and
devAsynFloat64.c)
sets the EPICS alarm severity to be “Invalid” and the EPICS alarm status to be “COMM”, which
are correct actions.

D) The 'Acquire' record at ADBase.template should be set as 'PINI=YES' and 'VAL=0' to set the
camera in a known state (i.e. 'off' state).


E) To whiten the rectangular box, a new devConnected Boolean variable can be added in the
GUI manager (e.g. MEDM) to monitor the connection of the ASYN device. If the STAT field of
an EPICS record is changed to be epicsAlarmComm, then pr->devConnected is set to 0, and
pr->updateValueCb will be called to draw white rectangular boxes on the device's records.

Sincerely,
Kate Feng