pvmanager-devel Mailing List for PV Manager (Page 3)
Brought to you by:
carcassi,
epics-jenkins
Menu
▾
▴
pvmanager-devel — Development discussion
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(16) |
Aug
(28) |
Sep
(38) |
Oct
(2) |
Nov
(1) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
|
Oct
|
Nov
(5) |
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ralph L. <Ral...@be...> - 2010-09-02 14:06:38
|
On 02.09.2010 05:56, Marty Kraimer wrote: > [...] > But for many devices it may not be useful of if a site has only one or > two devices of a particular type may not be worthwhile configuring. > Perhaps this is better handled via an additional structure field > besides alarm perhaps deviceStatus. A site could have template > structures for each of the devices they want to configure. > A record instance of the device would have a field like: > > <structure name = "deviceStatus" extends = "deviceXYZ" /> > > [...] I think we should figure out what we want first (spec), and have a general idea about how we want it (design), before thinking about implementation. I would say that ease of implementation is a valid argument when finalizing a design, but should not be taken into account earlier. Ralph |
|
From: Ralph L. <Ral...@be...> - 2010-09-02 14:00:22
|
On 01.09.2010 14:23, Andrew Johnson wrote: > On Wednesday 01 September 2010 12:45:10 you wrote: >>> I agree with *most* of that, but my ideal would still be a string. >> I think that the string makes life easier for the generator of alarms. I >> think it makes the clients that would use it much more complicated. > What clients are going to make use of this? As I said yesterday (and Marty > confirmed this morning) we only know of one client (ALH) that uses the V3 > status enum, and all it really does with it is add it to the alarm log-file. > It can log a string just as easily as an enum, and the result would be much > easier for operational staff to use to track down the problem. I have the impression that this argumentation is not valid. I think we all agree that the V3 numerical status enum was way too restrictive, and hardly usable in a reasonable way. That insufficient implementation was the main cause for almost no application using the alarm status. Now you're arguing that since no application is using the alarm status reasonably, we should keep the design insufficient. (Oversimplification, yes, but you get the idea.) I think this argumentation pattern is counter-progressive. Also, there are more clients: * The CA command line tools show alarm severity and status. * At BESSY and the MLS, most readback values (e.g. all power supply readbacks) show alarm severity and status. (The clients being dm2k and edm.) * Most importantly, the archiver is archiving severity and status for every update of every channel. Needless to say, that enums can be very efficiently archived, while arbitrary strings are very unefficient wrt archive storage. Add a general remark: The APS is one of the oldest EPICS installations. Many, if not most of its applications are of the first generation (alh, medm, ...), others are very non-standard (SDDS, SDDS-based archiver). Thus, while always being an excellent example and reference for scalability issues and clever V3 database use, it would not the first address I would turn to when looking for requirements of future, innovative clients. I think we have been making the mistake of assuming too much by simply extrapolating the limited scope of our existing framework and tool set. We should not repeat that mistake by introducing limitations in the V4 design justified by "I don't think anyone will ever need that". >> It does give ultimate flexibility. OTOH, it sends a lot more over the >> network. > .. for those clients that request the string. If the only client requesting > alarm message strings is the one that is responsible for logging the alarm > status messages, I think that's appropriate use of bandwidth and not going to > be a major drain on resources. Sending arbitrary messages as text to a logging client is perfectly appropriate. (Bob already pointed that out in one of his mails.) Our topic is status strings though, which I would see as a separate issue. > It /would/ be a mistake to insist (by the way the protocol and APIs are > designed) that every client that asks for the alarm severity has to get the > status message strings as well. Agreed, but I don't think anyone was considering this. Severity and status should be separate, clients can ask for either one (or both). >> It >> also requires all clients to have to parse the strings. The number of enums >> for status would be a limited set. The enum also gives an idea of what >> COULD go wrong. I can show the possible alarms and indicate which are true. >> Knowing the possible alarms also gives you some information that a NULL >> string does not. >> >> strings as alarms seem to me more appropriate for error logs, not alarm >> systems. > Will somebody please name/describe the client(s) that will have to ask for and > parse the alarm status information. There seems to be some unspoken > requirement that neither Marty nor I know about. We started working on a spec and a design. We will post it as soon as possible. Cheers, Ralph |
|
From: Marty K. <mrk...@co...> - 2010-09-02 09:52:48
|
On 09/01/2010 03:01 PM, Dalesio, Leo wrote: > > >In a different part of the thread I argued that the V3 alarm status > isn't used > >in practice because it doesn't contain enough information. > Agreed. > > > >I don't think we're that far apart, I just haven't persuaded you that > we can > >discard the alarm status yet... > I think this makes us diametrically opposed. We're trying to make it > useful and you're trying to remove it. > Given that it is not used at all, a string would be better than what > we have now. I think the string enum with the ability to set multiple > alarms states is useful. The first implementation was useless as it > only allowed one alarm state to be true and only one menu for the > entire system. As Benjamin pointed out - this was terribly > restrictive. Using it was painful to the point that only a few alarm > states had any real meaning. The string enum being proposed, gets > around this by allowing device support and record support to create > some fixed set of these that are tailored to the device support and > record support at a given facility. If I understand the mechanism that > Marty has in PVData and the implementation in PVAccess, we can send > some limited set of these and only send them when we have a unique > one. I am not clear on how this is implemented (Marty or Matej?). I > was trying to compute the total number of unique string enums needed > to do this in an earlier email. I don't think it comes to more than 60 > or so. > I think I start seeing what you want. Since a facility might have 100s or even 1000s of instances of a particular device it can be very useful. But for many devices it may not be useful of if a site has only one or two devices of a particular type may not be worthwhile configuring. Perhaps this is better handled via an additional structure field besides alarm perhaps deviceStatus. A site could have template structures for each of the devices they want to configure. A record instance of the device would have a field like: <structure name = "deviceStatus" extends = "deviceXYZ" /> In most cases this will not need configuration in the record instance because structure deviceXYZ does all the configuration. Let alarm just be severity and message for use by most clients. Clients that want to get/monitor the deviceStatus can get/monitor the deviceStatus field. Note that since get and monitor both only send changed data, deviceStatus will not cause excessive network traffic. The same goes for alarm,message. It is only sent when the message changes. If this is done the details of deviceStatus can be thought about without somehow making it compatible with the alarm structure. Marty |
|
From: Dalesio, L. <da...@bn...> - 2010-09-01 19:01:36
|
>In a different part of the thread I argued that the V3 alarm status isn't used >in practice because it doesn't contain enough information. Agreed. >I don't think we're that far apart, I just haven't persuaded you that we can >discard the alarm status yet... I think this makes us diametrically opposed. We're trying to make it useful and you're trying to remove it. Given that it is not used at all, a string would be better than what we have now. I think the string enum with the ability to set multiple alarms states is useful. The first implementation was useless as it only allowed one alarm state to be true and only one menu for the entire system. As Benjamin pointed out - this was terribly restrictive. Using it was painful to the point that only a few alarm states had any real meaning. The string enum being proposed, gets around this by allowing device support and record support to create some fixed set of these that are tailored to the device support and record support at a given facility. If I understand the mechanism that Marty has in PVData and the implementation in PVAccess, we can send some limited set of these and only send them when we have a unique one. I am not clear on how this is implemented (Marty or Matej?). I was trying to compute the total number of unique string enums needed to do this in an earlier email. I don't think it comes to more than 60 or so. >BTW, I know nothing about the PV Manager, I'm still mostly out in the cold as >regards that tool. The PV Manager is intended as a service for clients that takes care of the queueing/cacheing/connection management that each client now writes. Additionally, we are using it to handle the data silo-ing needed to create multi-channel arrays (that is a vector created from like scalars i.e. bpms, vacuum readings, temperatures). This will be presented at the upcoming meeting. It was also presented in Aix - right? It is useful to have a large group looking it over. (See the article earlier referenced). |
|
From: Marty K. <mrk...@co...> - 2010-09-01 18:33:29
|
On 09/01/2010 02:23 PM, Andrew Johnson wrote: > > It /would/ be a mistake to insist (by the way the protocol and APIs are > designed) that every client that asks for the alarm severity has to get the > status message strings as well. > For the javaIOC the client can ask for alarm or just alarm.severity. Note, however, that pvManager does not allow this option. The client gets it all if the client asks for alarm. Marty |
|
From: Andrew J. <an...@ap...> - 2010-09-01 18:23:24
|
On Wednesday 01 September 2010 12:45:10 you wrote: > >I agree with *most* of that, but my ideal would still be a string. > > I think that the string makes life easier for the generator of alarms. I > think it makes the clients that would use it much more complicated. What clients are going to make use of this? As I said yesterday (and Marty confirmed this morning) we only know of one client (ALH) that uses the V3 status enum, and all it really does with it is add it to the alarm log-file. It can log a string just as easily as an enum, and the result would be much easier for operational staff to use to track down the problem. > It does give ultimate flexibility. OTOH, it sends a lot more over the > network. .. for those clients that request the string. If the only client requesting alarm message strings is the one that is responsible for logging the alarm status messages, I think that's appropriate use of bandwidth and not going to be a major drain on resources. It /would/ be a mistake to insist (by the way the protocol and APIs are designed) that every client that asks for the alarm severity has to get the status message strings as well. > It > also requires all clients to have to parse the strings. The number of enums > for status would be a limited set. The enum also gives an idea of what > COULD go wrong. I can show the possible alarms and indicate which are true. > Knowing the possible alarms also gives you some information that a NULL > string does not. > > strings as alarms seem to me more appropriate for error logs, not alarm > systems. Will somebody please name/describe the client(s) that will have to ask for and parse the alarm status information. There seems to be some unspoken requirement that neither Marty nor I know about. - Andrew -- The best FOSS code is written to be read by other humans -- Harald Welte |
|
From: Ralph L. <Ral...@be...> - 2010-09-01 17:56:19
|
On 01.09.2010 13:14, Marty Kraimer wrote: > On 09/01/2010 10:39 AM, Dalesio, Leo wrote: >> We are making an alarm system. >> What we have now: >> 1 alarm severity and the 1 alarm status that caused that severity. >> >> Proposal 2 >> send strings >> - argument - any device may send any random string >> - counter argument - any random strings should be handled as an error >> log, not as an alarm system. Alarms are well defined conditions that >> have been designed into the system that we may want to react to. Any >> error string (it would be helpful to have a use case here), is not a >> known condition that we can configure any reasonable response to. >> Putting in this mechanism will take care of some small case that we >> have not identified at the cost of giving useful structure that can >> be handled in a well defined way at the client side. We could send >> self describing alarms too - and that would handle anything that may >> occur - but it does not make for well behaved client development > > Let me make an argument for why the message should be part of the > alarm rather than going to the error logger: > > Lets say the message is > PLCSector1Rack3Slot2 error Off Line > > If instead the status is something like READ_ALARM and the message > goes to the error log file then consider: We are talking about a string enum here, not a classical enum. The device support for the PLC knows all possible messages beforehand and adds them to the status string enum. As the record name will adhere to a naming convention, it will contain the PLC and the signal information. With the string enum choice being "error Off Line", a client that shows "<record name> <status string>" will show: PLCSector1Rack3Slot2 error Off Line which is exactly what you want. Andrew's argument is that he is expecting devices, where the set of possible status strings is not limited or not known beforehand. If such a device would send a string like "value 12.76545 exceeds the limit of 10.0", it could not be expressed as a status string enum choice. I would expect the device support in such cases to parse the message and map the status to one of the known set, while Andrew wants to send the string over the wire and push parsing the message to the client. Ralph |
|
From: Dalesio, L. <da...@bn...> - 2010-09-01 17:45:19
|
>I agree with *most* of that, but my ideal would still be a string. I think that the string makes life easier for the generator of alarms. I think it makes the clients that would use it much more complicated. It does give ultimate flexibility. OTOH, it sends a lot more over the network. It also requires all clients to have to parse the strings. The number of enums for status would be a limited set. The enum also gives an idea of what COULD go wrong. I can show the possible alarms and indicate which are true. Knowing the possible alarms also gives you some information that a NULL string does not. strings as alarms seem to me more appropriate for error logs, not alarm systems. |
|
From: Andrew J. <an...@ap...> - 2010-09-01 17:33:52
|
On Wednesday 01 September 2010 11:33:39 Ralph Lange wrote:
> On 01.09.2010 11:55, Benjamin Franksen wrote:
> >
> > A fixed set of choices for severity is good. When writing support for
> > devices (whether at the device support level or, for more complex
> > devices, at the database level) I never had any problem deciding which
> > severity to assign to the several possible alarm states(*). In fact, I
> > find the limitation to a small number of fixed choices actually helps, as
> > it makes you think harder about what exactly the different alarm states
> > mean for the user.
>
> I think only Andrew has a different opinion about severity, because his
> idea drops status completely and merges the information into severity.
Ahh, no, I wasn't proposing merging status into severity at all (I might have
written status when I meant severity or vice versa at some point though).
In its simplest form I would accept keeping the V3 4-value severity int/enum
(No alarm, Minor, Major, Invalid) and replacing the V3 status enum with a
string.
My more complex proposal was to replace the V3 severity enum with a bitset
with one bit each for Minor, Major and Invalid severities. The V3 status enum
would then become either a single string, an array of 3 strings, or an array
of 3 arrays of strings, depending on how you want to combine and transmit the
individual alarm messages. I admit this proposal is probably too far of a
stretch, but it would allow more and better error information to be collected
and associated with each record.
> > Things are quite different for alarm status. Fitting the alarm states of
> > a device into the pre-defined set of choices always feels like forcing it
> > into a straigh-jacket. It never feels like it fits right. Having more
> > freedom here would be very valuable. The question is how much freedom we
> > want. An arbitrary string value for the alarm status would be maximum
> > freedom, but imposes no structure at all. Maybe we want to impose *some*
> > structure. Ideally, I would want an enumeration type, but one I can
> > define myself. I also want to define it at several different levels.
>
> Completely agree with that.
I agree with *most* of that, but my ideal would still be a string. This
information is going to be logged and read by a human (who is also given the
record's name, time-stamp and alarm severity), and I often want to give them
additional information such as the actual input character I received that
doesn't match the protocol I understand, or the reading I was given which is
out of the legal range. I can't sensibly include those kinds of things in an
enum, even if I do get to define it myself.
> I would also say that each of the enum choices should have a severity
> linked to it (the severity that this choice would pull the record to).
Don't like, for the reasons you already expressed. Some statuses should
always map to a particular severity, but many don't, so I don't like the idea
of automatically linking the two.
> > For instance, a driver or device support could define a set of choices
> > for the alarm states of a certain ('atomic') device. However, such a
> > device is often just a small part of some larger (logical) device, which
> > one programs at the database level. In that case I want to be able to
> > define my own set of choices for the alarm states of the complex device
> > at the database level.
>
> The record support will also want to add its choices to the enum, for
> all generic conditions that may occur while it processes.
Hence a string makes life much easier.
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
|
|
From: Dalesio, L. <da...@bn...> - 2010-09-01 17:30:12
|
>The record support will also want to add its choices to the enum, for >all generic conditions that may occur while it processes. We are all in violent agreement. There will be some standard set of status enums that is the product of record type status enum x device type enums Ralph would like to add the severity for each of these status. That is one to one except for the configurable ones. Those will multiply the total enums by 2 (minor and major) for each one that can be configured. The only ones that are configures are limit, state and change of state (that I can remember. That means that binary inputs would have 4 x record type statuses x device type statuses. This may not be a big deal. |
|
From: Marty K. <mrk...@co...> - 2010-09-01 17:10:08
|
On 09/01/2010 10:39 AM, Dalesio, Leo wrote: > We are making an alarm system. > What we have now: > 1 alarm severity and the 1 alarm status that caused that severity. > > Proposal 2 > send strings > - argument - any device may send any random string > - counter argument - any random strings should be handled as an error > log, not as an alarm system. Alarms are well defined conditions that > have been designed into the system that we may want to react to. Any > error string (it would be helpful to have a use case here), is not a > known condition that we can configure any reasonable response to. > Putting in this mechanism will take care of some small case that we > have not identified at the cost of giving useful structure that can be > handled in a well defined way at the client side. We could send self > describing alarms too - and that would handle anything that may occur > - but it does not make for well behaved client development Let me make an argument for why the message should be part of the alarm rather than going to the error logger: Lets say the message is PLCSector1Rack3Slot2 error Off Line If instead the status is something like READ_ALARM and the message goes to the error log file then consider: 1) on an operator display the message READ_ALARM appears instead of "PLCSector1Rack3Slot2 error Off Line" Now the operator has to search the error log file and somehow see that the message "PLCSector1Rack3 Slot2error Off Line" is related to the READ_ALARM message. 2) The archiver has a message READ_ALARM instead of "PLCSector1Rack3Slot2 error Off Line". In order to see what READ_ALARM means a search must again be made in the error log file and somehow determine that the two are related. To the best of my knowledge no one has ever implemented any tool based on the status values as defined by alarm.h. My guess is the only use is to show the status string value. Does anyone know of such a tool? |
|
From: Ralph L. <Ral...@be...> - 2010-09-01 16:33:52
|
On 01.09.2010 11:55, Benjamin Franksen wrote:
> On Mittwoch, 1. September 2010, Dalesio, Leo wrote:
>> What we want -
>> something that gives more information than that.
> I disagree. We need not more, merely more specific information.
>
> A fixed set of choices for severity is good. When writing support for
> devices (whether at the device support level or, for more complex devices,
> at the database level) I never had any problem deciding which severity to
> assign to the several possible alarm states(*). In fact, I find the
> limitation to a small number of fixed choices actually helps, as it makes
> you think harder about what exactly the different alarm states mean for the
> user.
I think only Andrew has a different opinion about severity, because his
idea drops status completely and merges the information into severity.
I would say enum or int with enum usage is a minor issue.
> Things are quite different for alarm status. Fitting the alarm states of a
> device into the pre-defined set of choices always feels like forcing it
> into a straigh-jacket. It never feels like it fits right. Having more
> freedom here would be very valuable. The question is how much freedom we
> want. An arbitrary string value for the alarm status would be maximum
> freedom, but imposes no structure at all. Maybe we want to impose *some*
> structure. Ideally, I would want an enumeration type, but one I can define
> myself. I also want o define it at several different levels.
Completely agree with that.
I would also say that each of the enum choices should have a severity
linked to it (the severity that this choice would pull the record to).
The problem with that: record instances can differ in the severity they
attach to the enum choice. (As records can be configured wrt severities
for level alarms, disable status, simulation mode etc.)
So separating the array of status choice severities from the string enum
would allow a higher degree of sharing immutable string enums between
record instances with the same combination of record type and device
support. (Or would that be premature optimization?)
> For instance, a driver or device support could define a set of choices for
> the alarm states of a certain ('atomic') device. However, such a device is
> often just a small part of some larger (logical) device, which one programs
> at the database level. In that case I want to be able to define my own set
> of choices for the alarm states of the complex device at the database
> level.
The record support will also want to add its choices to the enum, for
all generic conditions that may occur while it processes.
~Ralph
> (*) What is the plural of 'alarm status' (in English)?
alarm statuses
|
|
From: Benjamin F. <ben...@be...> - 2010-09-01 16:08:55
|
On Mittwoch, 1. September 2010, Dalesio, Leo wrote:
> We are making an alarm system.
>
> What we have now:
> 1 alarm severity and the 1 alarm status that caused that severity.
And both have to be one of a *statically fixed* set of choices.
> What we want -
> something that gives more information than that.
I disagree. We need not more, merely more specific information.
A fixed set of choices for severity is good. When writing support for
devices (whether at the device support level or, for more complex devices,
at the database level) I never had any problem deciding which severity to
assign to the several possible alarm states(*). In fact, I find the
limitation to a small number of fixed choices actually helps, as it makes
you think harder about what exactly the different alarm states mean for the
user.
Things are quite different for alarm status. Fitting the alarm states of a
device into the pre-defined set of choices always feels like forcing it
into a straigh-jacket. It never feels like it fits right. Having more
freedom here would be very valuable. The question is how much freedom we
want. An arbitrary string value for the alarm status would be maximum
freedom, but imposes no structure at all. Maybe we want to impose *some*
structure. Ideally, I would want an enumeration type, but one I can define
myself. I also want o define it at several different levels.
For instance, a driver or device support could define a set of choices for
the alarm states of a certain ('atomic') device. However, such a device is
often just a small part of some larger (logical) device, which one programs
at the database level. In that case I want to be able to define my own set
of choices for the alarm states of the complex device at the database
level.
Cheers
Ben
(*) What is the plural of 'alarm status' (in English)?
|
|
From: Dalesio, L. <da...@bn...> - 2010-09-01 14:39:18
|
We are making an alarm system.
What we have now:
1 alarm severity and the 1 alarm status that caused that severity.
What we want -
something that gives more information than that.
Proposal 1
bit set on status... multiple status true at the same time.
this looses the clarity about which status caused the severity while giving all of the status that are currently true.
-- addendum 1 - send as a separate enum or array what severity is caused by each status
- argument - you see what each status contributed to the severity
- issue - you have this new data thingy that can change by changing the severity of crossing a limt from minor to major.
- there is a limited set of configurable alarm statuses - so maybe this is a small thing
-- addendum 2 - only send the index of the status that represents the current severity.
- argument - you have a net gain on information sent - same as V3 + all statuses that are true.
- no new data types
Proposal 2
send strings
- argument - any device may send any random string
- counter argument - any random strings should be handled as an error log, not as an alarm system. Alarms are well defined conditions that have been designed into the system that we may want to react to. Any error string (it would be helpful to have a use case here), is not a known condition that we can configure any reasonable response to. Putting in this mechanism will take care of some small case that we have not identified at the cost of giving useful structure that can be handled in a well defined way at the client side. We could send self describing alarms too - and that would handle anything that may occur - but it does not make for well behaved client development.
It would be useful to get just this part of the argument to an end before we come up with the most efficient way to implement either. Implementation of the communication mechanism is not implementation of useful clients - so it is not enough that we can easily implement the mechanism. CORBA can easily implement any communication.
Let's continue on email. Otherwise, we should try to plan a time during the upcoming meeting to resolve this.
|
|
From: Carcassi, G. <car...@bn...> - 2010-09-01 14:30:57
|
BTW: when exactly UNDEFINED has become UNKNOWN? >I am advocating adding UNKNOWN as an extra choice *in the client >library* to make connection handling easier. The only case where it's needed on the server is when constructing aggregated data. If I am constructing on the server an array of values from different PV (such as multi channel array of bpm positions), the alarm of the array cannot be UNDEFINED (same argument above) but the data, the payload, may contain UNDEFINED elements as the server might have not been able to get the reading from one BPM. Again, in this case the alarmSeverity is in the "data" part, not in the actual alarmSeverity of what you are reading from the server. Gabriele -----Original Message----- From: Ralph Lange [mailto:Ral...@be...] Sent: Wednesday, September 01, 2010 10:14 AM To: pvm...@li...; epi...@li... Subject: Re: [Pvmanager-devel] alarm (severity UNKNOWN) On 01.09.2010 09:25, Marty Kraimer wrote: > 3)<structure structureName = "alarmSeverity" extends = "enumerated"> > <array name = "choices" immutable = "true"> > [none,minor,major,invalid]</array> > </structure> > > OR > <structure structureName = "alarmSeverity" extends = "enumerated"> > <array name = "choices" immutable = "true"> > [none,minor,major,invalid,unknown]</array> > </structure> > > Note that Ralph is advocating the extra choice "unknown". Andrew makes > the case that it is not needed. Not true. I am advocating adding UNKNOWN as an extra choice *in the client library* to make connection handling easier. *Not* on the server. So: First option. ------------------------------------------------------------------------ ------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Pvmanager-devel mailing list Pvm...@li... https://lists.sourceforge.net/lists/listinfo/pvmanager-devel |
|
From: Ralph L. <Ral...@be...> - 2010-09-01 14:13:47
|
On 01.09.2010 09:25, Marty Kraimer wrote: > 3)<structure structureName = "alarmSeverity" extends = "enumerated"> > <array name = "choices" immutable = "true"> > [none,minor,major,invalid]</array> > </structure> > > OR > <structure structureName = "alarmSeverity" extends = "enumerated"> > <array name = "choices" immutable = "true"> > [none,minor,major,invalid,unknown]</array> > </structure> > > Note that Ralph is advocating the extra choice "unknown". Andrew makes > the case that it is not needed. Not true. I am advocating adding UNKNOWN as an extra choice *in the client library* to make connection handling easier. *Not* on the server. So: First option. |
|
From: Marty K. <mrk...@co...> - 2010-09-01 13:21:12
|
I have read all the messages from Bob, Ralph, Andrew, and Benjamin.
I think I can safely say: THERE IS NO CONSENSUS
There is no consensus on either severity or on status/message.
Andrew and Benjamin discussed how to share constant strings. Mainly on
the server. Since this is primarily a pvAccess rather than a pvData or
javaIOC issue I will leave this discussion for Matej. But again, as
Ralph reminded me, Matej does have a scheme to "cache" immutable strings
on the server.
Thus the following only discusses the definition of alarm.
I think we agree on the following:
<structure structureName = "alarm">
<?type? name = "severity" ?details? />
<-- either -->
<scalar name = "message" scalarType = "string" />
<!-- or -->
<?type? name = "status" ?details? />
</structure>
But what is ?type? and ?details?
For each, selecting one of the following four alternatives should
satisfy must of what has appeared in the discussion.
1) <scalar name = "xxx" scalarType = "int" />
This is basically what V3 does. In this case an interface (for V3
alarm.h) is provided that allow the int value to be treated like an
enum, i.e. a fixed set of strings are defined.
2) <scalar name = "xxx" scalarType = "string" />
A string value is passed.
3) <structure name = "xxx" extends = "enumerated" />
An enumerated structure is passed where an enumerated structure is
defined as:
<structure structureName = "enumerated" >
<scalar name = "index" scalarType = "int" />
<array name = "choices" scalarType = "string" />
</structure>
This an array of string choices is provided and a index selects one of
the choices.
4) <structure name = "xxx" extends = "multiChoice" />
A multiChoice array is passed where a multiChoice structure is defined as:
<structure structureName = "multiChoice">
<array name = "bitMask" scalarType = "byte" />
<array name = "choices" scalarType = "string" />
</structure>
An interface is provided that makes it easy to access a multiChoice array.
This allows a set of the string choices to be specified. If the array of
choices is declared immutable then it is a fixed set of strings.
I claim that selecting one of four choices could implement everything
that was said in the discussion.
Now lets consider severity and status/message separately.
First severity:
1) <scalar name = "severity" scalarType = "int" />
Again this is what V3 uses. If this is chosen than an interface will be
provided that allows the int to be interpreted as an enum.
Consider uses:
Synoptic display widgets: Can directly use the int for color coding.
Use the interface to get associated string value.
Archiver: Use the interface to get associated string value.
This has the advantage of very low overhead. String values are
automatically shared via the interface.
2) <scalar name = "severity" scalarType = "string" />
Advantage is that archiver and other clients do not do have to know
about a separate interface for getting the string value. To do things
like color coding an interface could be provided.
Since, without a helper interface, it does not satisfy even common uses
it offers no real advantage over 1) and requires passing strings.
3) <structure structureName = "alarmSeverity" extends = "enumerated" >
<array name = "choices" immutable = "true" >
[none,minor,major,invalid]</array>
</structure>
OR
<structure structureName = "alarmSeverity" extends = "enumerated" >
<array name = "choices" immutable = "true" >
[none,minor,major,invalid,unknown]</array>
</structure>
Note that Ralph is advocating the extra choice "unknown". Andrew makes
the case that it is not needed.
and in alarm definition
<structure name = "alarmSeverity" extends = "alarmSeverity" />
This allows a single choice. Since the choices are immutable the choice
strings can be shared.
But why is this better than 1) with an associated interface to allow the
int value to be treated as an enum?
4) <structure structureName = "alarmSeverity" extends = "multiChoice" >
<array name = "choices" immutable = "true" >
[none,minor,major,invalid]</array>
</structure>
OR
<structure structureName = "alarmSeverity" extends = "multiChoice" >
<array name = "choices" immutable = "true" >
[none,minor,major,invalid,unknown]</array>
</structure>
and in alarm definition
<structure name = "alarmSeverity" extends = "alarmSeverity" />
Andrew is advocating that this be chosen or that somehow multiple alarms
can be reported together rather than just maximize severity.
But this certainly makes things more complicated for user code for both
color coding and string values.
Also with regards to multiple alarms from a single record. This sounds
like it is to be used for diagnostic purposes. For on-line diagnosis,
with the swtshell the entire record can be displayed, which will show
every alarm field. Thus if a record goes into alarm and you want to find
out more just display the record.
Now for the hard part: status (or message)
1) <scalar name = "status" scalarType = "int" />
Again this is what V3 uses. If this is chosen than an interface will be
provided that allows the int to be interpreted as an enum. Like V3 it
means a fixed set of status values. Since no one is advocating this it
will not be discussed further.
2) <scalar name = "message" scalarType = "string" />
This is what I am advocating. Andrew also gave some arguments for it. It
allows meaningful messages to be generated.
Bob and Ralph think this is not the correct solution.
Bob uses examples like:
From the PLC
Open circuit detect
Over range
Perhaps out of software range
violates interlock limit
From the driver
No communication
No connection for this tag (point)
Loop time limit violated
But How are these messages obtained?
Consider the PLC. The device support somehow sends a command to and gets
a response from the PLC. There is some serial or network protocol used
for the communication. Any decent protocol allows the PLC to send error
and/or warning messages. The device support usually does nothing with
the messages except use them to raise alarms. If the device support can
just issue an alarm message then it can set a string like:
PLCSector1Rack3 warning Perhaps out of software range.
Note that the device support does NOT know about "Perhaps out of
software range." until the PLC sends it.
Ralph makes the argument:
>
> I agree there will be devices that need complex and maybe run-time
> changing sets of error strings, but I would think these will be few.
>
> Is there a way to treat these special devices special, and still have
> the efficient implementation for the 98% regular devices with a fixed
> set of status strings?
For such devices create a multiChoice structure as a field separate
from the alarm field.
Why complicate what 98% of device support must do.
Note that an archiver could be configured to monitor this field as well
as the value and alarm.
3) <structure structureName = "alarmStatus" extends = "enumerated" >
....
This again just allows a single choice from a set of choice strings. If
they are immutable than pvAccess could share them. It is like V3 except
that each record could have a different set of choices.
4) <structure name = "alarmStatus" extends = "multiChoice" />
This could be done so that the choices are different for each record or
chosen from some small set of different choices.
This is what Bob and I think Ralph are advocating. If for each record
instance the set of choices are immutable than it will satisfy
pvManager, i.e. the method:
List<String> getPossibleAlarms();
But this really puts a real burden on support code like device support.
The support must know during initialization all possible status
messages. From the PLC example above this is not really possible.
Thus I still advocate:
<structure structureName = "alarm">
<scalar name = "severity" scalarType = "int" />
<scalar name = "message" scalarType = "string" />
</structure>
And an interface that allows severity to be treated as an enum.
Marty
|
|
From: Andrew J. <an...@ap...> - 2010-08-31 22:20:52
|
On Tuesday 31 August 2010 16:12:10 Ralph Lange wrote: > > There's still the performance issue that concatenating the strings would > always be on-the-fly = strings on the wire, while the status bitset > would in most cases refer to an inmutable string enum = int on the wire. I agree that strings will be significantly slower than a single status value. That's why I've suggested only those clients that want the strings should be sent them, they should not be always sent along with the alarm severity like the v3 DBR_STS_* types are. I suspect that in practice there will be few clients wanting them. It might improve performance to delay string concatenation until it's needed, i.e. store each severity's set of messages within the record as a list of strings and only join them into one if a client requests them; actually you could just send the client the list of strings without joining them at all, if the wire protocol could be designed to do that. > Especially for a large number of simple devices (for NSLS-II we're > talking about ~900 PS using the same controller, and ~15,000 instances > of the same temperature sensor) the string enum sounds like the far more > efficient option. > > I agree there will be devices that need complex and maybe run-time > changing sets of error strings, but I would think these will be few. > > Is there a way to treat these special devices special, and still have > the efficient implementation for the 98% regular devices with a fixed > set of status strings? Is it the length of the strings that you see as the problem, meaning the network bandwidth it takes to transfer them, or the processing of the messages and related memory management within the IOCs? If it's bandwidth, what proportion of the clients will actually be requesting the strings? - Andrew -- The best FOSS code is written to be read by other humans -- Harald Welte |
|
From: Ralph L. <Ral...@be...> - 2010-08-31 21:12:31
|
On 31.08.2010 16:36, Andrew Johnson wrote: > On Tuesday 31 August 2010 15:02:33 Ralph Lange wrote: >> I don't like the idea of alarm conditions being hidden by the projection >> onto the severity. > This approach makes the individual alarms more visible, it doesn't hide them. > Now I understand your argumentation that the client would just print the strings anyway and not be interested in the actual bitset. Hm ... I agree that we're not that far apart. ;-) There's still the performance issue that concatenating the strings would always be on-the-fly = strings on the wire, while the status bitset would in most cases refer to an inmutable string enum = int on the wire. Especially for a large number of simple devices (for NSLS-II we're talking about ~900 PS using the same controller, and ~15,000 instances of the same temperature sensor) the string enum sounds like the far more efficient option. I agree there will be devices that need complex and maybe run-time changing sets of error strings, but I would think these will be few. Is there a way to treat these special devices special, and still have the efficient implementation for the 98% regular devices with a fixed set of status strings? ~Ralph |
|
From: Andrew J. <an...@ap...> - 2010-08-31 20:36:44
|
On Tuesday 31 August 2010 15:02:33 Ralph Lange wrote: > > In your severity-only model: what happens if two alarm conditions > (possible status options) are true, that both cause MINOR severity? > Your array has to chose one, right? What is the criteria? No, the error strings from the different alarm sources would get concatenated onto the relevant array element, with a separator (probably \n). Assuming the record always tests the different conditions in the same order when it processes, the messages will always appear in the string in that order too. > I don't like the idea of alarm conditions being hidden by the projection > onto the severity. This approach makes the individual alarms more visible, it doesn't hide them. > If a complex device has 10 conditions that cause a MAJOR severity, and 5 > of them are true, the client should be able to see all five, not just one. Agreed, this supports that. - Andrew -- The best FOSS code is written to be read by other humans -- Harald Welte |
|
From: Ralph L. <Ral...@be...> - 2010-08-31 20:02:42
|
On 31.08.2010 15:51, Andrew Johnson wrote: > In a different part of the thread I argued that the V3 alarm status isn't used > in practice because it doesn't contain enough information. If I was going to > implement alarm severities as a bitset I would probably provide alarm status > messages as an array of 3 strings, one for each severity minor/major/invalid. > A client like MEDM should be able to get the severities without the alarm > messages (it isn't going to display messages very often if ever, and will > usually just use the highest severity in a colour rule), but an alarm manager/ > error logger will want as much information as possible. > >> If you really want to implement something that complex, do it correctly: >> every status should has a severity enum connected to it. The more >> capable client can then create the severity set of the record by ORing >> the severities of the active status set. > I don't think we're that far apart, I just haven't persuaded you that we can > discard the alarm status yet... In your severity-only model: what happens if two alarm conditions (possible status options) are true, that both cause MINOR severity? Your array has to chose one, right? What is the criteria? If later the chosen condition is taken back, but the other condition stays, will the record post the same severity with a different string? I don't like the idea of alarm conditions being hidden by the projection onto the severity. If a complex device has 10 conditions that cause a MAJOR severity, and 5 of them are true, the client should be able to see all five, not just one. ~Ralph |
|
From: Andrew J. <an...@ap...> - 2010-08-31 19:51:51
|
On Tuesday 31 August 2010 14:19:49 Ralph Lange wrote: > > A generic application that can only display one severity (or a V3 one > > through a Gateway) would use the maximum severity bit reported, in your > > case INVALID (NO_ALARM is not a bit, it's defined as the value zero, > > meaning the complete absence of any set bits). However a more capable > > application might show that the record is currently reporting MINOR, > > MAJOR and INVALID alarms. > > Nah... > In that case you would have a bitset that shows the severities, and > another bitset that shows the set of status messages, but no clue which > status caused which severity. In a different part of the thread I argued that the V3 alarm status isn't used in practice because it doesn't contain enough information. If I was going to implement alarm severities as a bitset I would probably provide alarm status messages as an array of 3 strings, one for each severity minor/major/invalid. A client like MEDM should be able to get the severities without the alarm messages (it isn't going to display messages very often if ever, and will usually just use the highest severity in a colour rule), but an alarm manager/ error logger will want as much information as possible. > If you really want to implement something that complex, do it correctly: > every status should has a severity enum connected to it. The more > capable client can then create the severity set of the record by ORing > the severities of the active status set. I don't think we're that far apart, I just haven't persuaded you that we can discard the alarm status yet... BTW, I know nothing about the PV Manager, I'm still mostly out in the cold as regards that tool. - Andrew -- The best FOSS code is written to be read by other humans -- Harald Welte |
|
From: Shen, G. <sh...@bn...> - 2010-08-31 19:51:22
|
It is a good suggestion. Considering our attendees, it would be better to have it during the workshop days. Guobao Ralph Lange wrote: > All, > > I think we could use a day to get a few V4 related things discussed and > agreed upon at the October meeting. (Thinking alarms, redundancy > support, ...) > > Looking at the agenda, I would say this might work on one of the two > pre-meeting training days (Thursday Oct 7 / Friday Oct 8) or during the > workshop days (Thursday Oct 14 / Friday Oct 15), probably more > afternoonish (depending on which workshops you will attend). > > How are your plans? > > Ralph > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Pvmanager-devel mailing list > Pvm...@li... > https://lists.sourceforge.net/lists/listinfo/pvmanager-devel > > |
|
From: Ralph L. <Ral...@be...> - 2010-08-31 19:47:08
|
All, I think we could use a day to get a few V4 related things discussed and agreed upon at the October meeting. (Thinking alarms, redundancy support, ...) Looking at the agenda, I would say this might work on one of the two pre-meeting training days (Thursday Oct 7 / Friday Oct 8) or during the workshop days (Thursday Oct 14 / Friday Oct 15), probably more afternoonish (depending on which workshops you will attend). How are your plans? Ralph |
|
From: Ralph L. <Ral...@be...> - 2010-08-31 19:19:59
|
On 31.08.2010 13:28, Andrew Johnson wrote: > On Tuesday 31 August 2010 11:29:57 Ralph Lange wrote: >> One more point for UNDEFINED: the Gateway. >> If an IOC goes away, all direct clients would lose connection and thus >> change the severity to UNDEFINED. >> A client behind a Gateway does not lose the connection, but the Gateway >> would simply forward the UNDEFINED severity, and thus act transparently. > It is a mistake to confuse the meta-data about the state of the connection > with the alarm severity from the device. If a record is allowed to put itself > in UNDEFINED severity (because its serial connection to the PLC is dead say) I think UNDEFINED was just meant for CA connections. Note that the pvManager classes (that all this originates from) are meant to be the *client* interface. So the additional severity merged the connection status for ease of use. I don't think UNDEFINED was ever meant to be used on the server. (Again: existing real world applications like the alarm handler are adding this severity level, so we might see this as a hint that it is a) needed, and b) a resonable approach for a simplified handling of the connection status.) > a > client connected through a Gateway would have no way to distinguish between > the IOC being down and the PLC's serial cable having been cut. > > I think the Gateway needs a way to pass on its 'disconnected' status to the > client (but without triggering another search), which should cause the > connection callback to be run just as if the client were not using a Gateway > at all. I don't think you can use the alarm severity of the channel for > reporting the connection status since the client may not even be monitoring > channel alarms. True. And - as stated above - if UNDEFINED is not used on the server, there's even no way to use it. So behavior (direct and Gateway) would be: if the immediate CA connection (client or through Gateway) breaks down, the channel is disconnected (connection callbacks being called). For V3 there is no way to stop the client from searching for a disconnected channel, and I don't know if this would make sense. If a lower connection (serial link to PLC or CA link between IOCs) is down, the record is INVALID with "link error" (or hopefully something more specific in V4). >> "Maximize severity" is a well-established and widely used concept in >> EPICS 3. >> Moving that to the client will not work. In that case every client would >> have to know that a certain calc record is combining redundant signals >> and another one is a controller - that would replicate that information >> and allow for greatly inconsistent views of the system. >> How will a generic application (panel/alarm color mode) show a value >> that has (NO_ALARM& MINOR& MAJOR& INVALID)? > A generic application that can only display one severity (or a V3 one through > a Gateway) would use the maximum severity bit reported, in your case INVALID > (NO_ALARM is not a bit, it's defined as the value zero, meaning the complete > absence of any set bits). However a more capable application might show that > the record is currently reporting MINOR, MAJOR and INVALID alarms. Nah... In that case you would have a bitset that shows the severities, and another bitset that shows the set of status messages, but no clue which status caused which severity. If you really want to implement something that complex, do it correctly: every status should has a severity enum connected to it. The more capable client can then create the severity set of the record by ORing the severities of the active status set. And have the record's severity still be one enum value (defaulting to the highest severity of the active status set). ~Ralph |
1 message has been excluded from this view by a project administrator.
