EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: Message values and message texts.
From: "Pearson, MR (Matthew)" <[email protected]>
To: "Rees, NP (Nick)" <[email protected]>, <[email protected]>
Date: Mon, 6 Jul 2009 11:52:42 +0100
Hi,

Having a well defined mapping between bits and libraries would make it
easy to mask out status messages and alarms, so this looks like a good
idea.

I'm sure the alarm handling people will be interested in this, and have
probably thought about it before.

I would add a STS_K_DEBUG to that list, and then possibly use bits 6 and
7 for level of debug (low, medium, high). 

Benjamin Franksen's email about run time extendability of alarm strings
might be a better way to go long term, in terms of adding alarms/strings
at runtime by new software.

Cheers,
Matthew 
 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Rees, NP (Nick)
> Sent: 03 July 2009 17:43
> To: [email protected]
> Subject: Message values and message texts.
> 
> Hi All,
> 
> It being Friday afternoon, I have decided to send out a 
> message on this
> subject that I've been meaning to send for some time.
> 
> Currently, as I understand it EPICS has a problem relating to status
> numbers and messages. EPICS base has status values in libraries
> consisting of a 32 bit integer where:
> 
>   - most significant 16 bits is the library modifier code
>   - least significant 16 bits is the status value within that library.
> 
> These status values have comments in the header files associated with
> them, but these ASCII comments are of no use to any software.
> 
> Also, within records of the database there are 22 fixed status values
> defined and 4 associated severities. These do have text 
> associated with
> them, but only minimal text.
> 
> Back in the bad old days, VMS had a message system that users 
> could also
> use. This provided a mechanism of accessing message numbers and
> associated text strings via a system library. The system also 
> provided a
> way of generating an object file which could be linked in with any
> program which would automagically augment the system status 
> values with
> user defined status values and messages.
> 
> The 32 bit message number was divided up as follows:
> 
> Bits 0-2: The severity, as follows
> 	Symbol 		Value Description
> 	STS_K_WARNING 	0	Warning	
> 	STS_K_SUCCESS	1	Success	
> 	STS_K_ERROR		2	Error	
> 	STS_K_INFO		3	Informational
> 	STS_K_SEVERE 	4	Severe (Fatal) error
> 				5	Reserved
> 				6	Reserved
> 				7	Reserved
> 
> Bits 3-14:	Message number (1-4095)> 
> Bit 15:	Reserved, must be set true	
> Bits 16-26:	Facility system number (i.e. library identifier)> Bit
27:
> Reserved, must be set true	
> Bits 28-32:	Reserved, must be set false	
> 
> Now this generated an incomprehensible number, but there was a library
> routine to turn it into a string.
> 
> In a previous life, I used a system called DRAMA, which had a library
> and set of utility programs that basically replicated this 
> functionality
> for Unix and VxWorks systems. There are two problems:
>  - There has to be some way of assigning Facility numbers (so 
> they don't
> clash). This is an issue, but manageable.
>  - Every client that wants to turn a number into a string has to have
> access to a site specific object file that has all the strings in it.
> This has to be routinely regenerated as people add more libraries and
> messages. At my last site we had a script that walked the CVS 
> repository
> and dragged out all the message files on a regular basis.
> 
> What do people think of this as an approach? Does it solve any of our
> problems? I could easily dust off the Drama message facility. 
> If people
> are interested go to:
> 
>  - http://www.aao.gov.au/drama/html/mess_routines.frames.html
>  - http://www.aao.gov.au/drama/html/mess_programs.frames.html
>  - http://www.aao.gov.au/drama/doc/ps/mess_6.ps
> 
> Cheers,
> 
> Nick Rees
> Principal Software Engineer           Phone: +44 (0)1235-778430
> Diamond Light Source                  Fax:   +44 (0)1235-446713
> -- 
> Scanned by iCritical.
> 
> 
-- 
Scanned by iCritical.


References:
Message values and message texts. Rees, NP (Nick)

Navigate by Date:
Prev: Message values and message texts. Rees, NP (Nick)
Next: Base Release 3.14.11 Timetable Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Message values and message texts. Rees, NP (Nick)
Next: Base Release 3.14.11 Timetable Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  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 ·