Experimental Physics and Industrial Control System
Item 1: Meeting on Saturday, November 4th.
OK, I will be the bigmouth on this one... I have horribly little interest
hauling my butt into down town Chicago on a Saturday to talk about EPICS
error messages and codes. [Feel free to use this message as the meeting's
dart board.]
Item 2: MURMUR and DRAMA
I have looked at MURMUR and DRAMA. These are nice systems that may very
well take care of the functionality you desire. But...
If you look closely at DRAMA (that is, if you can actually get the docs in
from AU without their web server disconnecting 12.648% of the way thru), you
will notice that it is the foundation of the system's internal function API.
Force-fitting it into EPICS is something that I figured, would not fly.
(I honestly don't recall the part about how it mapps its error messages to
status codes. But if the quote about it doing a static association is true,
that I object to it times 2.) It might be OK if starting from scratch. But
redesigning the core of EPICS to make the required information available for
the DRAMA message system is PROBABLY too much to deal with. (The idea
of another Rx comes to mind here.)
MURMUR is ALOT closer to the architecture that seems to have been the talk
of this thread for the last week. However, I would like to object to:
1) The translation of a status code to a static message.
2) Passing anything other than the EPICS *database* level information
up thru Channel Access.
Some discussion of this point:
The EPICS system is an OO system made out of black boxes called
records. Records have fields. A field is the 'atom' that Channel
Access knows of and connects to. The EPICS information atom is made
of the following Quarks [if I may continue the theme]:
status
severity
units
upper_disp_limit
lower_disp_limit
lower_warning_limit
lower_alarm_limit
upper_ctrl_limit
lower_ctrl_limit
value
Notice that there is no indication of it being an input or output, static
or dynamic, or that the field is associated with an algorythm, device or
anything else. (Feel free to have a gander at the lovely db_access.h
for yourself.)
Adding a device status to this collection is possible, but what will it
really mean? What would be so useful about it that it would warrant
an 11th quark? The status and severity already deliver a VALID/INVALID
status associated with the value. The ONLY additional information made
available in the proposed status code schemes would be a canned message
such as "Timeout on GPIB bus." Which, I can tell you (from years of
getting complaints of such things) is pretty useless to all but a FEW
cases. If the user has any clue about how the real device is attached
or can understand the specific device at all, they will still gripe that
you did not mention the TYPE of device that timed out. Given the type,
they will want to know which of the 4 attached devices of that type is
the ONE that timed out. And then it will be which of the 3 identically
configured GPIB buss adapters is the one that...
Look, what we NEED is a real error messaging system that allows code to
log meaningful, arbitrairly complex, appropriate messages.
I object to the idea of basing the error message and logging scheme on
a return code to message mapping system. And that goes for anywhere,
including on the IOCs themselves.
I think the errMdef system stinks because it too is based on the assignment
of static messages to return codes. Even though it's support functions
allow additional text to be appended to a print message, it is still just a
silly static message if it is used at the higher level for messaging
purposes.
Static codes will require an athority to designate groups or ranges. The
WWW page idea is great, but we will run out of codes well before everyone
who wants a group can have one. [Espically if non-EPICS institutions want
to be part of it.] I suppose we could adopt a TCP subnet point of view to
sort-a solve that, but we would still have static mesages.
Saving code numbers and performing future translation is great if you need
to save space/bandwidth... as long you can say what you need in the messages
and as long as the codes never change. [When was the last time a standard
like this did NOT change?]
I would like to see the error system be based only on text and that it
provide the following minimal functionality:
1) Allow any function in the system to print or log an arbitrairly complex
message to the IOC console and/or log file.
2) The log file server/management system/thingy should provide a triggering
mechanism that provides for system status mail-biffs perhaps similar to
syslog.conf(5).
3) All functions be allowed to return an arbitrary status code to the caller.
Each of which may or may not represent an actual error condition.
4) IF messages ARE to be statically assigned to return codes from a function,
those messages should be assigned to the status codes in a header file
appropriate to the function's api (which may not match that of EPICS or
the calling function.)
Anything beyond this is icing on the cake. I don't have a problem with the
request that messages be printable on user interfaces. Lets just make sure
that the changes to the impacted systems are really warranted and provide
a way to deliver meaningful information.
--John Winans
- Replies:
- Re: EPICS status codes proposal watson
- References:
- Re: EPICS status codes proposal watson
- Navigate by Date:
- Prev:
Re: NT changes for 3.12.2 Andrew Johnson
- Next:
Re: EPICS status codes proposal William Lupton
- Index:
1994
<1995>
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS status codes proposal watson
- Next:
Re: EPICS status codes proposal watson
- Index:
1994
<1995>
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024