Re: Alarm if no status update received for a given time

[Ralph Lange <Ralph.Lange@helmholtz-berlin.de>]

Another option - as it is in your own device support and epicsTimers are 
not too expensive:

Create an epicsTimerQueue for the device support and an epicsTimer for 
every record instance. Whenever the record processes, it cancels the 
active timer and sets up a new one after <timeout> seconds (<timeout> 
probably taken from the INP link info @....).
The handler function (that gets called with a record* when the timer 
expires) sets the record state to INVALID/TIMEOUT (or READ ERROR, as Bob 
prefers).

Good luck!
Ralph


On 06.05.2009 17:16 Dalesio, Leo wrote:
> The standard way to handle hardware errors is to have the device support set the alarm severity to INVALID and the alarm state to READ ERROR. The device support defines what conditions are needed to do this - how many reads before it fails. If you want to configure this, you can extend the device support to decide pseudo channels to the driver by using the INF extension. Create ao device support for setting these parameters. The device support for CAN and extend the OUT field with an @TIMEOUT. Make the record passive - and whenever you write to the VAL - this replaces the timeout counter. You can do this per link or per device - whatever you decide.
>
>
>
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov on behalf of Martin Konrad
> Sent: Wed 5/6/2009 5:57 AM
> To: tech-talk@aps.anl.gov
> Subject: Alarm if no status update received for a given time
>  
> Hi all,
> I'm using some devices via a simple CAN device support for SocketCAN without 
> support for acknowledged writes etc. The IOC instead periodically asks the 
> devices for an update and they reply with a CAN packet containing the device 
> status.
>
> Now my question is very simple: What is the EPICS way of implementing a 
> timeout which raises an alarm if a device did not answer for a given time? Is 
> it possible to configure this alarm condition in the database?
>
> Thanks a lot in advance.
>
> Martin
>
>