2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Ideas for Codeathon |
From: | "Schoeneburg, Bernd" <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | [email protected] |
Date: | Thu, 19 Feb 2009 19:07:46 +0100 |
Hello Andrew and others... Andrew Johnson schrieb: To overcome this problem, we should possibly keep the existing list and use the "DISABLE" alarm together with severity = NO_ALARM. Although "disable" means something else. It is a pitty that the alarm status and severities can not be extended as easyly as scan times.Hi Bernd, On Tuesday 17 February 2009 13:43:33 Schoeneburg, Bernd wrote:*2. Alarm Disable Field in all Records *If a record rises an alarm because of a "known bug" or in case of maintenance or special operating conditions, it would be a very smart solution to disable this alarm at the source. Otherwise all connected clients must mask this alarm individually. Setting all severities to "NO_ALARM" does not help if the alarm is set by the device support. Setting a new disable-field to "DISABLE" would set SEVR to "NO_ALARM" and STAT to something like "ALMDIS" or so. Changing the disable field would need some special function which sends out the change. If disabled, the alarm bit in the monitor mask is ignored and the logAlarms-hook-function returns without doing anything. This change is useful if using the conventional alarm handler as well as the new AMS used by CSS.This idea needs some discussion. There is a related suggestion in my list called "OFFLINE Alarm Status" which takes a different approach, requiring device support to set an Invalid/Offline alarm instead. I don't know whether using a NO_ALARM severity with a different status would work properly with alarm acknowledgments.This looks for me like a solution for a different problem. If a record has its alarm disabled, other record should still be able to read data from it and the severity (if MS of the inlink is set) should not become invalid. Nothing is really offline. In an alarm tree display, the root of the tree shows the highest severity of the leaves. An alarm-disabled record therefor must have NO_ALARM severity for not to interfere the status of the root. Why is acknowledgment necessary if the severity is NO_ALARM?I agree that the two are not really the same. I may have been wrong about the acknowledgment issue, but I have just looked at the code for the alarm handler; adding a new alarm status value will require rebuilding ALH at the same time; old versions will report alarms with any new status values that get added as a WRITE_ACCESS_ALARM (the highest existing alarm status value). It is not possible for a CA client program to request a complete list of alarm status names through CA, because the protocol can only transport at most 16 status string for any ENUM field, and we already have 22 alarm status values. The strings used come from an array in libCom, but of course there is no guarantee that the libCom that ALH was built with is the same release as the libCom that the IOC is using, thus incompatibility is possible. I'm not saying we can't add new status values, but it does have implications that must be made clear if we do so. Yes, but you don't want log entries from one record 10 times a second, too. So this rate must be limited in the device support. Here in our group we are just working in an extension of our alarm logging system. It will be possible to send the ioc log-messages, ca-put-logging and query-messages (with and without answer requests) using udp-messages and then jms (java message system). Alarm logging is in production. The new features are in test or in coding.. . . . . Of course using the messages we can already see the problem. And perhaps this is sufficient. The string field in the record would just make it easier to display a short information in any GUI. It is possible to set really strange combinations of severities. We have never used them. Either we set e.g. hihi to major and high to minor or we disable single alarms by setting its severity to no_alarm. If a limit is called "alarm" or "warning" implies (wrongly) that the severities are always this standard composition. But that are only "names". We say "names are noise and smoke" (or so..).*5. get_alarm_double should not return unused limits *This has to be explained: When a display widget is coming up, it may need some values from the record, like display limits, control limits and alarm limits. Alarm limits are needed on a bargraph widget to mark some positions with arows or lines. If the corresponding alarm is not used, it's severity is set to "NO_ALARM". This means, crossing this limit does nothing! Specially when the EGU-range includes zero (EGUL < 0, EGUF > 0) then the arrows are missleading. The solution: If the alarm is not used, the records function "get_alarm_double" should return "NaN" for this limit. In this way the client knows, not to display the limit. The direct access to the limit fields is not affected.I agree the current requests for compound types that return alarm information are of little practical use to a display widget because they don't account for the severity that applies to each alarm level. However I'd like to know what should be returned if I set HSV to INVALID_ALARM, or if I set both HSV and HHSV to MINOR_ALARM? Also the use of NaN values doesn't solve what should happen with the DBR_GR_LONG and analogous CA types that have integer warning levels — get_alarm_double() requests the values from the record as doubles, but dbAccess subsequently converts them to integers if necessary.It may be my fault, but I don't understand the first problem. I don't care of the severities except checking for beeing NO_ALARM. The "arrows" in the display widget is useless if the corresponding severity is NO_ALARM because the code of the record (ai, longin,..) does not compare the value with the limits if the severity is 0 (NO_ALARM). HIHI and LOLO ist alway compared prior to HIGH and LOW and the function returns if one of it applies.Most record types have code like this in their get_alarm_double() routine, conditional on the field being VAL: pad->upper_alarm_limit = prec->hihi; pad->upper_warning_limit = prec->high; pad->lower_warning_limit = prec->low; pad->lower_alarm_limit = prec->lolo; My point is what does "warning" vs "alarm" mean in those names? To me it would make more sense if the "warning" limits get set by whichever alarm limit is configured to be MINOR_ALARM and the "alarm" limits by the limit set to MAJOR_ALARM, but then what should we do if HHSV is INVALID_ALARM rather than MAJOR_ALARM? The CA structures don't transport enough information for the display widget to indicate the alarm severity that the limit relates to, thus I'm generalizing your problem to say that we need to handle more than just NO_ALARM severity. Using a NaN value only solves a part of the larger problem. In our (commercial) D/3 control system (Bob knows it very well) the hihi and lolo alarms always have "critical" severity. For low and high it is possible to choose beteen "warning" and "critical". In this way the freedom of the user is limited. Back to EPICS: Its not forbidden to set the value of hihi lower than that of high. But then the high alarm will never become active. For strange settings strange behaviors will happen. Using NaN for no_alarm-severity-alarm-limits in analog records wich have floating point values would not solve all the problems, but a lot, those of users which uses the limits "the normal way". OK.For the second problem (dbAccess converts back to INT)... - well, no idea. Anyone uses bargraphs of integer values?CA supports versions of those structures with char, short or long for the limit values. I doubt if anyone actually uses a struct dbr_gr_char anywhere in real life, but they might and we would have to decide what its behavior should be if we make this change. Good! I will bring it with me.*9. Epics General Time: Allow more than one NTP Server* It can be, that this is not related to Epics-base. epicsGeneralTime facility is using os-depending services. I think osdNTPGet is the place were an extension would be necessary, if alternative NTP servers are needed. But nevertheless I mention it here. If the desired server (or the network path to it) fails, a second server would be better. In my changes I once did for the tsDrv in 3.13.x a list of servers in the environment variable was foreseen. Perhaps this is possible too now.General time allows you to register your own time providers, so it should be quite easy to add providers for additional NTP servers. The osiNTPTime.c provider in libCom can't talk to multiple servers at the moment because the NTP client code in RTEMS wasn't written with that in mind, but we'd be happy to see a better NTP time provider if someone wants to write one (preferably one with a built-in PLL for doing slow adjustments). This doesn't have to be part of Base, although eventually it could be incorporated into Base.I did once write an improved NTP support including PLL with multiple server support for the old tsDrv. Perhaps we could use parts of this code. Matthias held a talk about it on the EPICS meeting in june 2006. I just found my presentation.That would certainly be an interesting addition and definitely appropriate to work on at the Codeathon. Another source of relevent software could be Larry Doolittle's 'ntpclient' package which he has told me he might be willing to re-license for use with EPICS (it's currently GPLv2, so couldn't be shipped with Base). Isn't that criminal, to use a field which is "reserved for furure use"? ;-) But I had that thought, too.10. Make "Smoothing" in aiRecord independent of Conversion The SMOO field in the aiRecord is evaluated in the convert function, which is not executed if the device support read function returns 2 (don't convert). If the device delivers a float value directly, I do not see a reason not to smooth it. Can we take the smoothing code out of convert()?That's a good question: Is smoothing part of the analog to digital conversion process, or should we make it more general. I think you're probably right and that we should make that change (Eric agrees), but it does have the capability to break existing databases that might have SMOO set when they're not actually using it, or where someone is using that field for a completely unrelated purpose (since it's not used by their record at the moment). Thanks again, -Bernd |