Re: Analog Input records, Stream Device, and INVALID Alarms

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Dave,

StreamDevice sets record to INVALID state when there was a communication 
problem (timeout, errors reported from asynDriver, parsing errors). 
Whenever the device support is not able to fetch the valid value from 
the hardware the record becomes INVALID to signal that the value is not 
trustworthy. The STAT field and probably error messages on the IOC will 
tell you more about the reason.

This should not break the processing chain. The ai record should have 
finished its processing being INVALID and processing should continue 
with the FLNK, monitors, etc.

Normally the record recovers when the record is processed the next time 
and the hardware sends a value. How do you process the ai record? It may 
help if you describe your processing chain.

An input record has no IVOA field because it does not do any output 
actions. To do something similar you can read the value with an ao or 
calcout record with MS in the input link (DOL or INPA) and use IVOA of 
that record. It depends on what you want to do in case reading the value 
fails.

Best regards,
Dirk


Dave Reid wrote:
> I have a database that communicates via RS-232 to a vacuum gauge 
> controller.  I do this by setting up an Analog In record, that has the 
> DTYP set to "stream".   These Analog In records are part of a processing 
> chain in the database.
>
> What happens is that one of my AI records goes into the "Invalid" alarm 
> state, and this breaks the processing chain, and the only way we have 
> been able to recover from this is to reboot the IOC.
>
> So the questions are:
> 1-Why are we getting into this alarm state?  Is this something that the 
> stream device support is doing?
> 2-How does one recover gracefully from an "Invalid" alarm state?
> 3-Why is there not an "IVOA" field for input records?
>
> Thanks....
>
> dave