EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: alarm hook
From: "Liyu, Andrei" <[email protected]>
To: Geoff Savage <[email protected]>, Matthias Clausen <[email protected]>
Cc: Andrew Johnson <[email protected]>, EPICS core-talk <[email protected]>, Fritz Bartlett <[email protected]>
Date: Wed, 28 Jun 2006 16:52:37 -0400
Geoff,

I like your #1 -> #6 :-)
and chain 
hook -> logAlarm -> queue -> sendToNetwork -> createMessage -> send  
to A -> send to B (if send to A fails)


1. hook
2. hook function
>logAlarm(struct dbCommon *prec, unsigned short sevr, unsigned short
stat)

Why not logAlarm(struct dbCommon *prec)?

>It should also do something reasonable if the data can't be inserted in
the  
>queue.  It might simply keep track of the number of insertion  
>failures and report this number in a message once the queue has space.

I think that a way is
something happen -> error message to Error log (through network).
If ErrorLog can't send message that stop by MPS (through special net).

Another question how can be used this way?
Maybe something like: logAlarm can't put message into queue -> +1 -> if
==100 -> send message to error log and reset counter?

We can decrease quantity of Alarm messages. I suppose alarm with status
DB_LINK is duplicated of another alarm.

3. queue
Sure. Size has default value and can be adjusted by env variable.

4. sendToNetwork.
I think the priority depends of system type. For example, for diagnostic
devices maybe better have alarm then another incorrect data from scan
task? For first step I think alarm can be less than CA task. 
Maybe have default value and can be adjusted by env variable.

5. Message through network and createMessage() and #c
>The createMessage routine constructs a string message to be sent  
>across the network.  To be more generic users should be able to  
>define their own createMessage routine.  This allows users to use a  
>different message protocol within the push out framework.

Sorry but I have totally another approach. I think Alarm message must
have standard! That is like CA standard. From distributed view Alarm and
CA messages definitions are more important than record standard. But it
must be flexible. I would like to have something like 
- some predefined fields [ID, Alarm severity, timestamp]
- one flexible field [Alarm status for Epics]
- separator 
- string (characters), maybe length can be adjusted by env variable.
In this case anyone can add anything in the end and then take care on
client side.

6. Send the message to server A/B
Env variables can have 1,2,3 Alarm servers. At first try 1, then 2 and
so on. If there is not env variable = "" than Alarm system doesn't work.

Again error concerning Alarm server problem sends into error log.

Also Alarm service can sends one message but it can sends some messages
in one package. It should save time.

Thanks, Andrei.


Navigate by Date:
Prev: RE: alarm hook Liyu, Andrei
Next: RE: alarm hook Liyu, Andrei
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: alarm hook Liyu, Andrei
Next: RE: alarm hook Liyu, Andrei
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·