pvmanager-devel Mailing List for PV Manager (Page 2)
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: Marty K. <mrk...@co...> - 2010-12-07 17:50:37
|
On 12/07/2010 10:53 AM, Carcassi, Gabriele wrote: > > Hi all, > > Since Epics3 does not distinguish between scalars and array, PVManager > does and PVAcces does/will, I am wondering whether we should support > (or not) automatic conversion between them. That is: if I ask for a > VDouble, but the native type is an array VDoubleArray, should I > automatically return a VDouble with the first element or return a type > mismatch error? If I ask for a VDoubleArray, but the native type is a > VDouble, should I return a VDoubleArray with an array of size 1 or > return a type mismatch error? > > My hunch is to not make these conversions by default, but to provide > (if needed), an operation that does such conversion... this way the > user can do it but it's an explicit operation. > > Agree? Disagree? > I vote for type mismatch error. Marty > > Gabriele > > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > > > _______________________________________________ > Pvmanager-devel mailing list > Pvm...@li... > https://lists.sourceforge.net/lists/listinfo/pvmanager-devel |
|
From: Carcassi, G. <car...@bn...> - 2010-12-07 15:53:29
|
Hi all, Since Epics3 does not distinguish between scalars and array, PVManager does and PVAcces does/will, I am wondering whether we should support (or not) automatic conversion between them. That is: if I ask for a VDouble, but the native type is an array VDoubleArray, should I automatically return a VDouble with the first element or return a type mismatch error? If I ask for a VDoubleArray, but the native type is a VDouble, should I return a VDoubleArray with an array of size 1 or return a type mismatch error? My hunch is to not make these conversions by default, but to provide (if needed), an operation that does such conversion... this way the user can do it but it's an explicit operation. Agree? Disagree? Gabriele |
|
From: Carcassi, G. <car...@bn...> - 2010-11-18 20:01:44
|
Hi all, PVManager 0.2 released. Here is a brief list of the changes: DataTypes: changing status to an element in a statically defined enum (as per discussions during the Epics meeting) DataTypes: finalizing array types (added the ones missing) PVManager: moved EPICS specific from TimeStamp to JCADataSource SimulationDataSource: added the ability to "replay" a channel from an XML file (useful for unit testing) JCADataSource: added support for array (float, double, byte, short, int, String) JCADataSource: internal refactoring to streamline implementation CSS integration: epics data source now respect the JCA/CAJ setting (was only using JCA) For CSS, changes will be pushed in the main repository as soon as Kunal is back and reviewed them (to make sure I didn't screw anything up...) Thanks! Gabriele |
|
From: White, G. <gr...@sl...> - 2010-10-19 23:44:13
|
Hey, this is going to be cool Gabriele. I'm looking forward to using it. Greg On Oct 19, 2010, at 1:45 PM, Carcassi, Gabriele wrote: > Hi all, > > Finally time to take what I have and call it 0.1. > > http://epics.sourceforge.net/maven2/epics/PVManager/0.1/ > > The main part of the framework is stable enough. Minor touches will be probably still be needed, but most of them should not impact normal usage that much. Partial support for Epics 3 through JCA is there (only scalar types). Simulated data is there too. I am also putting together some “how to use” here: > https://sourceforge.net/apps/trac/pvmanager/ > > Gabriele > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev_______________________________________________ > Pvmanager-devel mailing list > Pvm...@li... > https://lists.sourceforge.net/lists/listinfo/pvmanager-devel |
|
From: Carcassi, G. <car...@bn...> - 2010-10-19 20:45:11
|
Hi all, Finally time to take what I have and call it 0.1. http://epics.sourceforge.net/maven2/epics/PVManager/0.1/ The main part of the framework is stable enough. Minor touches will be probably still be needed, but most of them should not impact normal usage that much. Partial support for Epics 3 through JCA is there (only scalar types). Simulated data is there too. I am also putting together some "how to use" here: https://sourceforge.net/apps/trac/pvmanager/ Gabriele |
|
From: Carcassi, G. <car...@bn...> - 2010-09-22 15:30:41
|
>1) A richer set of data types and a finer resolution of properties
than
>pvManager currently supports.
If you mean having separate data types for all the alarm/type/display...
combination: no, we don't want that. We'll have one, with partial
implementation. In the same that there is no ReadOnlyList in Java,
Collections.unmodifiableList(list).remove(10) throws an
UnsupportedOperationException. That's what we should do.
>2) An interface for creating the data containers, Each data source can
>provide a factory that implements the data source.
It does not work like that, and it can't even since I'll have multiple
data sources _at the same time_. Each data source will create the
implementation of the types however they like. The different pieces of
the stack are not going to use the same implementation of the data types
that the data source have.
There is a static factory class with the types, that's what everything
else will use. Those are simple pojos, with no reference to anything
else.
>Calls JCA to connect to mypv.
>Either creates a subscription to mypv or is prepared to issue a get
>request every second.
I have been repeating this over and over: right now, it just does
monitors. It can't really do puts: it's about consolidating data on
higher level structure, how can you write back on a calculation?!? Even
supporting a get means doing something totally different: there is no
rate mismatch, what does it mean having a cache in between? It would be
a different pipeline.
Let me stress it again, for the things we do in PVManager: get, monitor,
put REQUIRE DIFFERENT PIPELINES. Right now we are implementing the
monitor because it's the most complicated (and the most needed). The
other pieces we'll add as needed during the CSS integration. The puts
are simple wrappers, and the gets are expressions that do not include
aggregation, and are readed only once. I don't know:
PVManager.readOnce(....);
And maybe one for synch and another one for asynch calls... I don't even
know what we are really going to need!
>A client wants to implement a feedback algorithm that reads a set on
>sensors, computes some algorithm, and puts values to a set of
correctors.
Remember no puts right now, and assuming you have integrated the
computation my implementing a Function<MyNewValues>:
PV<MyNewValues> pv =
PVManager.read(myComputation(pvDoubles(sensors),
pvDoubles(correctors)).andNotify(onTimerThread).atHz(1);
pv.addPVValueChangeListener(new PVValueChangeListener() {
@Override
public void pvValueChanged() {
// Do the puts
}
});
My feeling is that you are jumping ahead too fast... For example, I am
not even going to care about puts right now: we already have a decent
way to do puts, they are not hard, we can create a simple wrapper around
that if we need... there is not logic. Why should I take time to spec
that out when I am not still sure that what I have is going to work well
with, say, archived data, which I need to support? Why should I care
about optimizing the types when I still worry about correctness in the
connection and disconnection, leaking memory and so on? If I fail to
provide a system that works correctly, who cares that it is efficient on
the network!
Right now, PVManager is about monitor of higher level structures, coming
from multiple data source, and decoupling the data rate. PVManager is
NOT an epics client.
Gabriele
|
|
From: Marty K. <mrk...@co...> - 2010-09-22 10:57:38
|
On 09/20/2010 07:00 PM, Carcassi, Gabriele wrote:
>> I am responding from the point of view of the "data source", i. e.
> the
>> source that provides actual data rather than other data like averaged,
>> etc. Thus I mean a source like EPICS V3 or pvAccess or a relational
>> database.
> Then you already have the spec. It's the DataSource object in PVManager.
> There is an implementation with the SimulationDataSource. I will provide
> the implementation epics 3. The data interfaces are the one defined.
>
> What are you missing?
>
For data I want:
1) A richer set of data types and a finer resolution of properties than
pvManager currently supports.
Look at the first message from this thread on 09/07/2010 07:32 AM.
NPTE: It was from Benjamin because when I sent the message I did not
start a new thread.
2) An interface for creating the data containers, Each data source can
provide a factory that implements the data source.
3) Interfaces for connection, get, put, monitor. Again these are
implemented by the data source.
In your example:
PVManager.read(pvDouble("epics://mypv")).withMetadata(Alarm.class,
Time.class).atHz(1);
PVManager.read(sumOf(pvDouble("epics://mypv1"),
pvDouble("epics://mypv2")).withMetadata(Alarm.class,
Time.class).atHz(1);
What does pvManager do and what does data source do?
I assume it is as follows:
For read(pvDouble("epics://mypv)).withMetaData(Alarm.class,Time.class)
pvManager does the following:
Calls JCA to connect to mypv.
Either creates a subscription to mypv or is prepared to issue a get
request every second.
For the second example I assume that pvManager just does the previous twice.
Is this what you envision?
Let me give an important application.
A client wants to implement a feedback algorithm that reads a set on
sensors, computes some algorithm, and puts values to a set of correctors.
Thus it wants to:
1) Create a connection to the set of sensors.
2) Create a connection to the set of correctors.
3) repeatedly execute the steps:
a) read sensors
b) compute algorithm
c) put correctors.
How is this expressed to pvManager?
|
|
From: Carcassi, G. <car...@bn...> - 2010-09-20 23:00:40
|
> I am responding from the point of view of the "data source", i. e.
the
>source that provides actual data rather than other data like averaged,
>etc. Thus I mean a source like EPICS V3 or pvAccess or a relational
>database.
Then you already have the spec. It's the DataSource object in PVManager.
There is an implementation with the SimulationDataSource. I will provide
the implementation epics 3. The data interfaces are the one defined.
What are you missing?
Gabriele
-----Original Message-----
From: Marty Kraimer [mailto:mrk...@co...]
Sent: Monday, September 20, 2010 7:53 AM
To: epi...@li...;
pvm...@li...
Subject: Re: [Pvmanager-devel] user data interface: Single complex
interface vsmultiple simple interfaces
I am responding from the point of view of the "data source", i. e. the
source that provides actual data rather than other data like averaged,
etc. Thus I mean a source like EPICS V3 or pvAccess or a relational
database.
I want to see Java interface definitions that must be implemented by the
data source.
What should appear in these interfaces?
There could be something like:
connect(String pvName, String properties, ConnectCallback
connectCallback, ExceptionCallback exceptionCalllback);
and also
connect(String[] pvnames,String properties, ConnectCallback
connectCallback, ExceptionCallback exceptionCalllback);
What is properties? This is some combination of things like
"value,alarmSeverity,alarm???,display,controlLimits,alarmLevels"
The data source should be responsible for creating a container for
holding the data.
There must be methods to get/put/monitor data.
For a put pvManager puts data into the data container and calls a put
method.
For get and monitor the data source puts data into the data container
and delivers it to pvManager.
For a connect instance only a single get or put or monitor can be active
at the same time.
I DO want a complete spec of the interfaces that must be implemented by
a data source. The pvManager client may not (perhaps should not) be
aware of these interfaces but pvManager must be able to call these
interfaces based on what the client requests.
On 09/19/2010 01:51 PM, Carcassi, Gabriele wrote:
> Back from vacation.
>
>>> Right now, we are assuming to have the whole thing, because most of
> the
>>> time that's what we are going to use for display.
>> IMHO that design has the wrong default.
> This triggers a more general discussion of the purpose of PVManager.
>
> One of the reason I am writing PVManager is to be able to prepare
higher
> level structures. So:
>
> PVManager.read(tableOf(column("BPMS", pvDoubles(bpms)), column("Magnet
> current", pvDouble(pwrSplyRB)).atHz(1)
>
> Would get all the values of the bpms and the power supply, put them in
a
> table, and give me the table at 1 Hz. Now, assume that when I assemble
> the table, I only care about the value. So all those pv doubles should
> be value only, and we can optimize by only reading the value.
>
> Here is the thing: I don't want the user to have to specify _over_ and
> _over_ that those variables can be value only. It should be up to
> whoever provides the 'column' operator to specify what type it needs.
So
> parent operator must be able to set a hint to its arguments.
>
> What we actually want is to specify the metadata on the final
> expression, for example, we may have:
>
> PVManager.read(pvDouble("epics://mypv")).withMetadata(Alarm.class,
> Time.class).atHz(1); PVManager.read(sumOf(pvDouble("epics://mypv1"),
> pvDouble("epics://mypv2")).withMetadata(Alarm.class,
> Time.class).atHz(1);
>
> Now we have that the client simply specifies what bits and pieces he
> needs. In the first case, what happens is that the datasource just
> connects to the bits and pieces it needs, optimizing network traffic.
> But the second case does more: it tells the sumOf operator that it
does
> not need the display ranges, so it can tell the arguments not to get
> them but also it knows not to compute them. Using the class tokens we
> can enforce that the final type implements those metadata interfaces.
>
> The reason we need something like this is because the relationship
> between the metadata of the computation and the metadata of the
> arguments can be complicated. For example, let's say I have an average
> operator, and I want to redefine the minor/major alarm based on the
> expected sigma calculated from the individual ranges. In this case,
even
> if I just want the alarm of the average, I will need to get the alarm
> ranges of all the elements.
>
> Ok, so I hope this at least gives an understanding of the problem
space
> I am trying to solve. I am actually deliberately _not_ trying to solve
> this particular problem _now_: it's an optimization. I first want to
> make sure that the basic elements of the infrastructure are there,
that
> the API is easy to use and reliable (connections are closed, things
> don't hang, memory is de-allocated as soon as possible, reasonable
> performance in the worst case, ...). I think I have enough places to
add
> those kind of performance tuning later (the pvManager always gets and
> expression, so there is plenty of ways those expressions can be
> enriched).
>
> But, I understand that people might not be satisfied with a simple
"I'll
> get there when I get there"... and maybe that's the problem? Is it
that
> you guys want to at least have a full spec on paper (even if it's not
> what I currently distribute as the working code in pvManager) so that
> you get a sense of how all the pieces that you are working on are
going
> to fit in the future?
>
> Gabriele
>
------------------------------------------------------------------------
------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Pvmanager-devel mailing list
Pvm...@li...
https://lists.sourceforge.net/lists/listinfo/pvmanager-devel
|
|
From: Marty K. <mrk...@co...> - 2010-09-20 14:48:13
|
I am responding from the point of view of the "data source", i. e. the
source that provides actual data rather than other data like averaged,
etc. Thus I mean a source like EPICS V3 or pvAccess or a relational
database.
I want to see Java interface definitions that must be implemented by the
data source.
What should appear in these interfaces?
There could be something like:
connect(String pvName, String properties, ConnectCallback
connectCallback, ExceptionCallback exceptionCalllback);
and also
connect(String[] pvnames,String properties, ConnectCallback
connectCallback, ExceptionCallback exceptionCalllback);
What is properties? This is some combination of things like
"value,alarmSeverity,alarm???,display,controlLimits,alarmLevels"
The data source should be responsible for creating a container for
holding the data.
There must be methods to get/put/monitor data.
For a put pvManager puts data into the data container and calls a put
method.
For get and monitor the data source puts data into the data container
and delivers it to pvManager.
For a connect instance only a single get or put or monitor can be active
at the same time.
I DO want a complete spec of the interfaces that must be implemented by
a data source. The pvManager client may not (perhaps should not) be
aware of these interfaces but pvManager must be able to call these
interfaces based on what the client requests.
On 09/19/2010 01:51 PM, Carcassi, Gabriele wrote:
> Back from vacation.
>
>>> Right now, we are assuming to have the whole thing, because most of
> the
>>> time that's what we are going to use for display.
>> IMHO that design has the wrong default.
> This triggers a more general discussion of the purpose of PVManager.
>
> One of the reason I am writing PVManager is to be able to prepare higher
> level structures. So:
>
> PVManager.read(tableOf(column("BPMS", pvDoubles(bpms)), column("Magnet
> current", pvDouble(pwrSplyRB)).atHz(1)
>
> Would get all the values of the bpms and the power supply, put them in a
> table, and give me the table at 1 Hz. Now, assume that when I assemble
> the table, I only care about the value. So all those pv doubles should
> be value only, and we can optimize by only reading the value.
>
> Here is the thing: I don't want the user to have to specify _over_ and
> _over_ that those variables can be value only. It should be up to
> whoever provides the 'column' operator to specify what type it needs. So
> parent operator must be able to set a hint to its arguments.
>
> What we actually want is to specify the metadata on the final
> expression, for example, we may have:
>
> PVManager.read(pvDouble("epics://mypv")).withMetadata(Alarm.class,
> Time.class).atHz(1); PVManager.read(sumOf(pvDouble("epics://mypv1"),
> pvDouble("epics://mypv2")).withMetadata(Alarm.class,
> Time.class).atHz(1);
>
> Now we have that the client simply specifies what bits and pieces he
> needs. In the first case, what happens is that the datasource just
> connects to the bits and pieces it needs, optimizing network traffic.
> But the second case does more: it tells the sumOf operator that it does
> not need the display ranges, so it can tell the arguments not to get
> them but also it knows not to compute them. Using the class tokens we
> can enforce that the final type implements those metadata interfaces.
>
> The reason we need something like this is because the relationship
> between the metadata of the computation and the metadata of the
> arguments can be complicated. For example, let's say I have an average
> operator, and I want to redefine the minor/major alarm based on the
> expected sigma calculated from the individual ranges. In this case, even
> if I just want the alarm of the average, I will need to get the alarm
> ranges of all the elements.
>
> Ok, so I hope this at least gives an understanding of the problem space
> I am trying to solve. I am actually deliberately _not_ trying to solve
> this particular problem _now_: it's an optimization. I first want to
> make sure that the basic elements of the infrastructure are there, that
> the API is easy to use and reliable (connections are closed, things
> don't hang, memory is de-allocated as soon as possible, reasonable
> performance in the worst case, ...). I think I have enough places to add
> those kind of performance tuning later (the pvManager always gets and
> expression, so there is plenty of ways those expressions can be
> enriched).
>
> But, I understand that people might not be satisfied with a simple "I'll
> get there when I get there"... and maybe that's the problem? Is it that
> you guys want to at least have a full spec on paper (even if it's not
> what I currently distribute as the working code in pvManager) so that
> you get a sense of how all the pieces that you are working on are going
> to fit in the future?
>
> Gabriele
>
|
|
From: Carcassi, G. <car...@bn...> - 2010-09-19 17:51:23
|
Back from vacation.
>> Right now, we are assuming to have the whole thing, because most of
the
>> time that's what we are going to use for display.
>IMHO that design has the wrong default.
This triggers a more general discussion of the purpose of PVManager.
One of the reason I am writing PVManager is to be able to prepare higher
level structures. So:
PVManager.read(tableOf(column("BPMS", pvDoubles(bpms)), column("Magnet
current", pvDouble(pwrSplyRB)).atHz(1)
Would get all the values of the bpms and the power supply, put them in a
table, and give me the table at 1 Hz. Now, assume that when I assemble
the table, I only care about the value. So all those pv doubles should
be value only, and we can optimize by only reading the value.
Here is the thing: I don't want the user to have to specify _over_ and
_over_ that those variables can be value only. It should be up to
whoever provides the 'column' operator to specify what type it needs. So
parent operator must be able to set a hint to its arguments.
What we actually want is to specify the metadata on the final
expression, for example, we may have:
PVManager.read(pvDouble("epics://mypv")).withMetadata(Alarm.class,
Time.class).atHz(1); PVManager.read(sumOf(pvDouble("epics://mypv1"),
pvDouble("epics://mypv2")).withMetadata(Alarm.class,
Time.class).atHz(1);
Now we have that the client simply specifies what bits and pieces he
needs. In the first case, what happens is that the datasource just
connects to the bits and pieces it needs, optimizing network traffic.
But the second case does more: it tells the sumOf operator that it does
not need the display ranges, so it can tell the arguments not to get
them but also it knows not to compute them. Using the class tokens we
can enforce that the final type implements those metadata interfaces.
The reason we need something like this is because the relationship
between the metadata of the computation and the metadata of the
arguments can be complicated. For example, let's say I have an average
operator, and I want to redefine the minor/major alarm based on the
expected sigma calculated from the individual ranges. In this case, even
if I just want the alarm of the average, I will need to get the alarm
ranges of all the elements.
Ok, so I hope this at least gives an understanding of the problem space
I am trying to solve. I am actually deliberately _not_ trying to solve
this particular problem _now_: it's an optimization. I first want to
make sure that the basic elements of the infrastructure are there, that
the API is easy to use and reliable (connections are closed, things
don't hang, memory is de-allocated as soon as possible, reasonable
performance in the worst case, ...). I think I have enough places to add
those kind of performance tuning later (the pvManager always gets and
expression, so there is plenty of ways those expressions can be
enriched).
But, I understand that people might not be satisfied with a simple "I'll
get there when I get there"... and maybe that's the problem? Is it that
you guys want to at least have a full spec on paper (even if it's not
what I currently distribute as the working code in pvManager) so that
you get a sense of how all the pieces that you are working on are going
to fit in the future?
Gabriele
|
|
From: Andrew J. <an...@ap...> - 2010-09-16 16:46:17
|
I have just noticed that the following example request is not possible using a single CA monitor or get request in CAv3: > "epics3://mypv?alarm+time+limits" There is no DBR-type that contains both the time-stamp and a limit range of any kind, so you would have to create this by combining two monitors with different types. It is now possible for the record to reprocess in between fetching the two objects, even though they're both kicked off by the same db_post_event() inside the IOC. I guess you can detect that by comparing the value fields you receive, but you'll have to decide what to do if they differ. - Andrew -- The best FOSS code is written to be read by other humans -- Harald Welte |
|
From: Andrew J. <an...@ap...> - 2010-09-15 15:49:45
|
On Friday 10 September 2010 05:06:26 Marty Kraimer wrote: > Without knowing the severities and algorithm for computing value alarms > a client can not handle all possibilities. > > A simple example is: > > record A gives values to none of the value alarm fields, i.e. it does > not raise value alarms > > record B requires that the value be positive or it raises a major alarm. > It only sets LLSV=MAJOR_ALARM. Think is a pipe with a check valve. A > negative flow indicates a broken check valve. > > record C requires that the value be negative. It sets HHSV=MAJOR_ALARM > > A caV3 client can not distinguish between these cases. Note that in R3.14.11 we changed the get_alarm_double() routines of most of the analog record types (ai, ao, calc, calcout, dfanout, sel, sub) to return NAN for the relevent level when the associated xxSV field is NO_ALARM. This doesn't solve the whole problem, but it allows a V3 client to distinguish between /some/ of the cases (we obviously decided this was better than doing nothing at all). - Andrew -- The best FOSS code is written to be read by other humans -- Harald Welte |
|
From: Dalesio, L. <da...@bn...> - 2010-09-10 14:41:44
|
Got it - yeah - that was why that one option existed. Bob -----Original Message----- From: Ralph Lange [mailto:Ral...@be...] Sent: Fri 9/10/2010 10:09 AM To: epi...@li... Cc: pvm...@li... Subject: Re: alarm limits will not always work On 10.09.2010 08:25, Dalesio, Leo wrote: > > It doesn't have to in any cases I can think of. > The configuration of alarm conditions is the job of the engineer that > configures the alarms. > The alarm clients only need to decide - > --- what and how to display > --- who to notify in that condition > --- is there any action to take on that alarm condition and severity. > > The client is not checking for alarm. The client is handling alarm > conditions. > Hi Bob, You didn't get Marty's point. (I didn't get it either, until microseconds before I hit the send button.) What he tries to say is: The dbr_gr_xxx limits structure does not have the complete information, as it only contains the alarm levels, but not the severities that are connected to them. These are configured separately in the record, and a client must access separate fields to get the whole picture. E.g.: If a client wants to put alarm markers on a scale widget for an analog value, getting the dbr_gr_xxx tells it *where* to put the marker, but not the *color* that the marker should have. This is why - in our suggestion to handle alarm status with a immutable string enum - there should be an array of severities related to the strings, that shows which alarm condition causes which severity value. The severities should probably be separate from the immutable enum, since the relation of alarm condition and severity is configurable per record instance, and coding the severity into the immutable enum would create a large number of slightly different enums, destroying the efficiency advantage of sharing the immutable enums between connections (sending the strings once, using the enum ID in the updates). Ralph |
|
From: Ralph L. <Ral...@be...> - 2010-09-10 14:09:26
|
On 10.09.2010 08:25, Dalesio, Leo wrote: > > It doesn't have to in any cases I can think of. > The configuration of alarm conditions is the job of the engineer that > configures the alarms. > The alarm clients only need to decide - > --- what and how to display > --- who to notify in that condition > --- is there any action to take on that alarm condition and severity. > > The client is not checking for alarm. The client is handling alarm > conditions. > Hi Bob, You didn't get Marty's point. (I didn't get it either, until microseconds before I hit the send button.) What he tries to say is: The dbr_gr_xxx limits structure does not have the complete information, as it only contains the alarm levels, but not the severities that are connected to them. These are configured separately in the record, and a client must access separate fields to get the whole picture. E.g.: If a client wants to put alarm markers on a scale widget for an analog value, getting the dbr_gr_xxx tells it *where* to put the marker, but not the *color* that the marker should have. This is why - in our suggestion to handle alarm status with a immutable string enum - there should be an array of severities related to the strings, that shows which alarm condition causes which severity value. The severities should probably be separate from the immutable enum, since the relation of alarm condition and severity is configurable per record instance, and coding the severity into the immutable enum would create a large number of slightly different enums, destroying the efficiency advantage of sharing the immutable enums between connections (sending the strings once, using the enum ID in the updates). Ralph |
|
From: Dalesio, L. <da...@bn...> - 2010-09-10 12:29:05
|
It doesn't have to in any cases I can think of. The configuration of alarm conditions is the job of the engineer that configures the alarms. The alarm clients only need to decide - --- what and how to display --- who to notify in that condition --- is there any action to take on that alarm condition and severity. The client is not checking for alarm. The client is handling alarm conditions. -----Original Message----- From: Marty Kraimer [mailto:mrk...@co...] Sent: Fri 9/10/2010 6:06 AM To: pvm...@li...; epi...@li... Subject: [Pvmanager-devel] alarm limits will not always work The following problem with alarm limits is common to caV3, pvManager, and javaIOC so I will just describe it in caV3 terms. The dbr_gr_xxx struvctures have fields named upper_alarm_limit, upper_warning_limit,lower_warning_limit,upper_warning_limit. But records that have fields for value alarms have fields: HIHI,HIGH,LOW,LOLO and also HHSV,HSV,LSV,LLSV which are alarm severities for the corresponding alarm value fields. Without knowing the severities and algorithm for computing value alarms a client can not handle all possibilities. A simple example is: record A gives values to none of the value alarm fields, i.e. it does not raise value alarms record B requires that the value be positive or it raises a major alarm. It only sets LLSV=MAJOR_ALARM. Think is a pipe with a check valve. A negative flow indicates a broken check valve. record C requires that the value be negative. It sets HHSV=MAJOR_ALARM A caV3 client can not distinguish between these cases. ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Pvmanager-devel mailing list Pvm...@li... https://lists.sourceforge.net/lists/listinfo/pvmanager-devel |
|
From: Marty K. <mrk...@co...> - 2010-09-10 10:01:56
|
The following problem with alarm limits is common to caV3, pvManager, and javaIOC so I will just describe it in caV3 terms. The dbr_gr_xxx struvctures have fields named upper_alarm_limit, upper_warning_limit,lower_warning_limit,upper_warning_limit. But records that have fields for value alarms have fields: HIHI,HIGH,LOW,LOLO and also HHSV,HSV,LSV,LLSV which are alarm severities for the corresponding alarm value fields. Without knowing the severities and algorithm for computing value alarms a client can not handle all possibilities. A simple example is: record A gives values to none of the value alarm fields, i.e. it does not raise value alarms record B requires that the value be positive or it raises a major alarm. It only sets LLSV=MAJOR_ALARM. Think is a pipe with a check valve. A negative flow indicates a broken check valve. record C requires that the value be negative. It sets HHSV=MAJOR_ALARM A caV3 client can not distinguish between these cases. |
|
From: Andrew J. <an...@ap...> - 2010-09-07 21:27:30
|
On Tuesday 07 September 2010 15:09:40 Carcassi, Gabriele wrote:
> Right now, we are assuming to have the whole thing, because most of the
> time that's what we are going to use for display. So:
> PVManager.read(vDouble("epics3://mypv")).atHz(10);
> would give you everything.
>
> A way to scale back is:
> PVManager.read(vDouble("epics3://mypv?alarm+time")).atHz(10);
> which gives you the alarm and time but no display information. You still
> get a VDouble, with all the methods, but for the things you didn't
> request you would either get null or an UnsupportedOperationException
> (depending on what we think it's better, which I am not sure either).
IMHO that design has the wrong default. Requesting "epics3://mypv" should
give me just what I've asked for, i.e. the value and nothing else. If I want
the alarm severity and timestamp with it then I should have to request them
with the "epics3://mypv?alarm+time" modifiers. To add the display limits too
I'm guessing it would be something like "epics3://mypv?alarm+time+limits" (I'm
sure you've already got that much specified properly).
> The current position is that you get what you asked at connection time.
> You can't "upgrade": you have to re-ask. All pieces needed are known
> before connection time (except things like size of the array).
That seems reasonable, but I would suggest you consider the effect on your
IOCs of asking for information by default that your users are not necessarily
interested in (but they're too busy/lazy to modify the URL to request just the
parts they need).
My way if they forget or can't be bothered to add the modifiers, their code
throws an exception as soon as they try to access the attributes, causing them
to fix their request. If you do it the other way the users will continue to
request the unnecessary data until eventually the IOCs overload, and now the
problem is seen as a Controls hardware issue (IOCs not powerful enough) rather
than a user software issue (using resources unnecessarily).
$0.02
- Andrew
--
The best FOSS code is written to be read by other humans -- Harald Welte
|
|
From: Carcassi, G. <car...@bn...> - 2010-09-07 20:09:50
|
>> Didn't we already have this discussion when we were all here?
>>
>Yes and I never got anyone to understand my concern. I am trying again.
Ok, I thought we came to a good understanding at the end... my bad...
>May be true for scalars. But for megaByte arrays there is a big
>different between an int8 and an int64.
Yep: arrays we will have as many as we need. In java means byte, short,
int, long (8/16/32/64) plus float and double (32/64).
>Consider caV3. Does this mean that the implementation always ask for
>DBR_CTRL_XXX. Lets assume DOUBLE. This is really expensive. Or does the
>implementation issue DBR_DOUBLE and then the first time the client asks
>for something from alarm cancel the DBR_DOUBLE and ask for a
>DBR_STS_STRING, and so on and so on.
Right now, we are assuming to have the whole thing, because most of the
time that's what we are going to use for display. So:
PVManager.read(vDouble("epics3://mypv")).atHz(10);
would give you everything.
A way to scale back is:
PVManager.read(vDouble("epics3://mypv?alarm+time")).atHz(10);
which gives you the alarm and time but no display information. You still
get a VDouble, with all the methods, but for the things you didn't
request you would either get null or an UnsupportedOperationException
(depending on what we think it's better, which I am not sure either).
The current position is that you get what you asked at connection time.
You can't "upgrade": you have to re-ask. All pieces needed are known
before connection time (except things like size of the array).
Gabriele
|
|
From: Marty K. <mrk...@co...> - 2010-09-07 19:08:51
|
On 09/07/2010 11:15 AM, Carcassi, Gabriele wrote: > Hi Marty, > > Didn't we already have this discussion when we were all here? > Yes and I never got anyone to understand my concern. I am trying again. >> Thus pvManager present all data via a single interface. But instead of >> proving 3456 interfaces it provides just 8 interfaces. It does this by >> limiting choices are follows: >> >> The value data types supported are int32, float64, string, and enum. > I got this from both Kay and Bob independently: while there is a > difference on the wire, the client is not going to care that much about > the difference among different integers or floats. > May be true for scalars. But for megaByte arrays there is a big different between an int8 and an int64. Also you use an int32. Thus you do not support int64. >> For each a scalar or array is supported. >> For each data type all of alarm, timeStamp, and display are included. > Again, this was decided during the discussion, to keep things simple. > Right now we are shooting for getting everything, but we can always > scale back if we find problems. > This is my BIG concern. In fact it is the whole point of my message. See next. >> I believe that it will be very hard to provide an efficient >> implementations for either V3 CA or for pvAccess. > Why? Because we are limiting the options to get everything or nothing? > > Again, don't confuse the pvManager client interfaces with what goes on > the wire: these are two different things. The fact that the data type > defines all the elements does not mean that they always have to be > present and returned. You can still return null or throw an > UnsupportedOperationException. They are methods: they can do whatever we > need them to do. > Consider caV3. Does this mean that the implementation always ask for DBR_CTRL_XXX. Lets assume DOUBLE. This is really expensive. Or does the implementation issue DBR_DOUBLE and then the first time the client asks for something from alarm cancel the DBR_DOUBLE and ask for a DBR_STS_STRING, and so on and so on. This is not very nice, not very efficient, and really a mess. Marty |
|
From: Carcassi, G. <car...@bn...> - 2010-09-07 15:15:48
|
Hi Marty, Didn't we already have this discussion when we were all here? >Thus pvManager present all data via a single interface. But instead of >proving 3456 interfaces it provides just 8 interfaces. It does this by >limiting choices are follows: > >The value data types supported are int32, float64, string, and enum. I got this from both Kay and Bob independently: while there is a difference on the wire, the client is not going to care that much about the difference among different integers or floats. >For each a scalar or array is supported. >For each data type all of alarm, timeStamp, and display are included. Again, this was decided during the discussion, to keep things simple. Right now we are shooting for getting everything, but we can always scale back if we find problems. >I believe that it will be very hard to provide an efficient >implementations for either V3 CA or for pvAccess. Why? Because we are limiting the options to get everything or nothing? Again, don't confuse the pvManager client interfaces with what goes on the wire: these are two different things. The fact that the data type defines all the elements does not mean that they always have to be present and returned. You can still return null or throw an UnsupportedOperationException. They are methods: they can do whatever we need them to do. Gabriele |
|
From: Dalesio, L. <da...@bn...> - 2010-09-07 12:06:10
|
The idea of the metadata is that it provides all of the data needed to treat the thing being sent in a uniform and complete way. Do we want to archive alarm status? I would think that a useful alarm status is near as important as the alarm severity. In an alarm manager - this is more true. The status is as much a part of the alarm as the alarm severity. In other instances, like display or multi-channel arrays, I can't make a compelling argument. So how do you get the alarm severity without the alarm status. I would say that severity is a critical component and value. Along your line of argument - value, time stamp, alarm severity - is what I want most of the time. if I also want alarm status - then asking for the alarm status information seems like an improvement over V3. -- >From that perspective it seems that alarm severity either belongs to base characteristics and alarm characteristics or base characteristics only. Base characteristics include time stamp, alarm severity. Alarm characteristics include alarm statuses only. ---------------------------- The second part of the argument is stringEnum - or message. The only benefit message has over strinENum is that it can be an arbitrary string. For me, that is a logMsg utility - not an alarm system. ---------------------------- -----Original Message----- From: Marty Kraimer [mailto:mrk...@co...] Sent: Tue 9/7/2010 6:57 AM To: pvm...@li...; epi...@li... Subject: Re: [Pvmanager-devel] alarm On 09/03/2010 06:59 AM, Dalesio, Leo wrote: > > I am attaching a couple of slides that attempt to describe what is > being proposed (and I thought we had agreed to) at the meeting we had > at BNL. > It changes the alarm status to a bitset. Multiple alarm statuses are > true at the same time - which reflects real life. > I agree that being able to expose device status info to CA clients is a desirable goal. Where I have a problem is making it a required component of alarm. This is a generic issue: Should of set of components be presented as a single object or as a set of objects. For a client this means presented as a single interface or as a set of interfaces. The following are three example of where this issue has been the basis of heated arguments. 1) The javaIOC allows each field to have optional support. For example the scan field has scan support. An input field can have any of a large set of supports attached. In fact an input field could have linearConvert support attached and have a subfield named input that can again have any of a large set of different supports to get a raw value. A valueAlarm field can have valueAlarm support attached. And so on an so on. The issue is how to construct a database record. One way is the V3 way, which means that a set of basic record types, with each type having a fixed set of fields. Thus record types ai, ao, bi, bo, mbbi, etc. Another way is to construct a record based on what it does. As an example a record template can be created based on: 1) the specific device, 2) the communication bus, 3) valueLimits if they make sense, etc. 2) pvManager data, i.e. value, timeStamp, alarm, and display. How should this be presented to the client? One way is a fixed set of interfaces like DoubleTimeStampAlarmDisplay or as a set of interfaces like Double,TimeStamp,Alarm,Display. 3) Alarm. This is the issues currently being addressed. Assume there are three components severity, message, and deviceStatus. I know this is has not been agreed upon as the three components but it is details. The issue is how is the presented to a client: As a single interface named alarm that has all three components or as multiple interfaces. Thus this is really 2) appearing at a different level. I am going to start another thread giving arguments why I think a set of objects is much better than a single object. The thread will concentrate on 2) but the same arguments can be made about 1). |
|
From: Benjamin F. <ben...@be...> - 2010-09-07 11:32:44
|
Hi Marty
you said you'd create a new thread but you did not, you merely changed the
subject line. Thus I am creating a new thread, now. I hope people take the
hint and reply to this message and not to your original one.
---------- Forwarded Message ----------
The following makes the case that providing data via multiple simple
interfaces is better than a single complex interface. As an example
instead of an interface DoubleTimeStampAlarmDisplay it is better to
present the user with separate interfaces Double, TimeStamp, Alarm, Display.
This message only discusses pvManager data which consists of some
combination of value, timeStamp, alarm. and Display.
Consider the number of options for each:
value
Potential types to support consist of
primitives: boolean, int8, int16, int 32, float32, float64
string: This is treated like a primitive.
enum: This is composite but for this discussion let it also be
considered a primitive.
For all types except enum both a scalar and an array is supported. At
the present time neither CA V3 or pvAccess allows arrays of enums so the
discussion assumes that an enum can only be scalar.
There should also be a choice of no value.
For a connection a client can choose only one type. So there are 8*2 +1
+ 1 = 18 choices.
timeStamp
This is secondsSinceEpoch and nanoSeconds. Thus there are 2 components.
alarm
The definition of alarm is still under discussion so for this
discussion just assume it is severity, message, and deviceStatus.
deviceStatus is a composite but again for this discussion it is treated
like a single thing. The severity is treated as an int with an
associated enum interface and can this also be treated as a primitive.
With these assumptions an alarm has three components.
display
This consists of:
units, format
displayLow, displayHigh,
controlLow, controlHigh,
alarmMajorLowValue, alarmMajorHighValue, alarmMinorLowValue,
alarmMinorHighValue
Except for units, format, and the alarmSeverities the type could be any
of the numeric primitive types. Rather than considering this
complication just assume they are always float64. It will not
drastically change the following arguments. With this assumption display
has 10 components.
The above is what is to be made available to a client. How is the
question. The following considers two possibilities. The first allows
one value choice and for each of timeStamp, alarm, and display allow any
combination. The second picks a set of choices for each of timeStamp,
alarm, and display. The set of choices is based on how the data is
expected to be used by clients. For each possibility the total number
of interfaces is determined assuming: A) everything is presented in a
single interface, and B) separate interfaces are used for value,
timeStamp, alarm, and display.
First Possibility: one value choice and all possible combinations of
timeStamp, alarm, and display.
There are: 18 choices for value, 2 components for timeStamp, 3
components for alarm, and 10 components for display.
A: Present all data via single interfaace.
For value there are 18 choices. For each of the others there are
2**ncomponents, choices.
Thus number interfaces = 18*(2**2)*(2**3)*(2**10) = 589824 interfaces
B: Present data with separate interfaces for value, timeStamp, alarm,
and display
Now there are 18 + (2**2) + (2**3) + (2**10) = 1054.
Thus for this possibility B is really bad and A is absolutely horrible.
Thus lets limit the choices for each of timeStamp, alarm, and display.
The following attempts to choose useful subsets. It is not meant to be
the definitive subsets. Another choice changes the details but not the
conclusion.
timeStamp
For this just allow: 1) no timeStamp or 2) full timeStamp. Thus 2 choices.
alarm
Break this into two separate things: 1) alarm, which consists of
severity and message, and 2) deviceStatus. For alarm three choices will
be allowed: 1) no alarm,
2) severity only, and 3) severity and message. For deviceStatus there
are two choices: 1) no deviceStatus and 2) full deviceStatus.
display
allow any combination of unitsFormat, displayLimits, controlLimits, and
alarmLimits. Mapping of complete set of display fields to these should
be obvious.
Thus there are 2**4 = 16 choices.
A) Present all data via single interface
Number interfaces = 18*2*3*2*16 = 3456.
B) Present all data via separate interfaces:
Number interfaces = 18 + 2 + 3 + 2 + 16 = 41 interfaces.
I claim that B) is quite manageable. A) is horrible.
So what does the current definition of pvManager provide since providing
3456 interfaces is not really feasible.
NOTE: pvmanager is a lot more than data but I am only discussing the
data interfaces that must be implemented by some data source like V3 CA
or pvAccess.
I may not be looking correctly but I think the following is the complete
set of data interfaces that are presented to clients and must be
implemented by the data source. I suspect that the rest of the VXXX
interfaces can be or are already implemented by pvManager itself.
VDouble, VDoubleArray, VEnum,VEnumArray,VInt,VIntArray,VStriing,VStringArray
All are somewhat similar except for the value data type so let's
consider just one.
public interface VDouble extends Scalar<Double>, Alarm, Time,
Display<Double> {}
Thus pvManager present all data via a single interface. But instead of
proving 3456 interfaces it provides just 8 interfaces. It does this by
limiting choices are follows:
The value data types supported are int32, float64, string, and enum.
For each a scalar or array is supported.
For each data type all of alarm, timeStamp, and display are included.
I believe that it will be very hard to provide an efficient
implementations for either V3 CA or for pvAccess.
Marty
------------------------------------------------------------------------------
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
-------------------------------------------------------
|
|
From: Marty K. <mrk...@co...> - 2010-09-07 10:59:13
|
The following makes the case that providing data via multiple simple
interfaces is better than a single complex interface. As an example
instead of an interface DoubleTimeStampAlarmDisplay it is better to
present the user with separate interfaces Double, TimeStamp, Alarm, Display.
This message only discusses pvManager data which consists of some
combination of value, timeStamp, alarm. and Display.
Consider the number of options for each:
value
Potential types to support consist of
primitives: boolean, int8, int16, int 32, float32, float64
string: This is treated like a primitive.
enum: This is composite but for this discussion let it also be
considered a primitive.
For all types except enum both a scalar and an array is supported. At
the present time neither CA V3 or pvAccess allows arrays of enums so the
discussion assumes that an enum can only be scalar.
There should also be a choice of no value.
For a connection a client can choose only one type. So there are 8*2 +1
+ 1 = 18 choices.
timeStamp
This is secondsSinceEpoch and nanoSeconds. Thus there are 2 components.
alarm
The definition of alarm is still under discussion so for this
discussion just assume it is severity, message, and deviceStatus.
deviceStatus is a composite but again for this discussion it is treated
like a single thing. The severity is treated as an int with an
associated enum interface and can this also be treated as a primitive.
With these assumptions an alarm has three components.
display
This consists of:
units, format
displayLow, displayHigh,
controlLow, controlHigh,
alarmMajorLowValue, alarmMajorHighValue, alarmMinorLowValue,
alarmMinorHighValue
Except for units, format, and the alarmSeverities the type could be any
of the numeric primitive types. Rather than considering this
complication just assume they are always float64. It will not
drastically change the following arguments. With this assumption display
has 10 components.
The above is what is to be made available to a client. How is the
question. The following considers two possibilities. The first allows
one value choice and for each of timeStamp, alarm, and display allow any
combination. The second picks a set of choices for each of timeStamp,
alarm, and display. The set of choices is based on how the data is
expected to be used by clients. For each possibility the total number
of interfaces is determined assuming: A) everything is presented in a
single interface, and B) separate interfaces are used for value,
timeStamp, alarm, and display.
First Possibility: one value choice and all possible combinations of
timeStamp, alarm, and display.
There are: 18 choices for value, 2 components for timeStamp, 3
components for alarm, and 10 components for display.
A: Present all data via single interfaace.
For value there are 18 choices. For each of the others there are
2**ncomponents, choices.
Thus number interfaces = 18*(2**2)*(2**3)*(2**10) = 589824 interfaces
B: Present data with separate interfaces for value, timeStamp, alarm,
and display
Now there are 18 + (2**2) + (2**3) + (2**10) = 1054.
Thus for this possibility B is really bad and A is absolutely horrible.
Thus lets limit the choices for each of timeStamp, alarm, and display.
The following attempts to choose useful subsets. It is not meant to be
the definitive subsets. Another choice changes the details but not the
conclusion.
timeStamp
For this just allow: 1) no timeStamp or 2) full timeStamp. Thus 2 choices.
alarm
Break this into two separate things: 1) alarm, which consists of
severity and message, and 2) deviceStatus. For alarm three choices will
be allowed: 1) no alarm,
2) severity only, and 3) severity and message. For deviceStatus there
are two choices: 1) no deviceStatus and 2) full deviceStatus.
display
allow any combination of unitsFormat, displayLimits, controlLimits, and
alarmLimits. Mapping of complete set of display fields to these should
be obvious.
Thus there are 2**4 = 16 choices.
A) Present all data via single interface
Number interfaces = 18*2*3*2*16 = 3456.
B) Present all data via separate interfaces:
Number interfaces = 18 + 2 + 3 + 2 + 16 = 41 interfaces.
I claim that B) is quite manageable. A) is horrible.
So what does the current definition of pvManager provide since providing
3456 interfaces is not really feasible.
NOTE: pvmanager is a lot more than data but I am only discussing the
data interfaces that must be implemented by some data source like V3 CA
or pvAccess.
I may not be looking correctly but I think the following is the complete
set of data interfaces that are presented to clients and must be
implemented by the data source. I suspect that the rest of the VXXX
interfaces can be or are already implemented by pvManager itself.
VDouble, VDoubleArray, VEnum,VEnumArray,VInt,VIntArray,VStriing,VStringArray
All are somewhat similar except for the value data type so let's
consider just one.
public interface VDouble extends Scalar<Double>, Alarm, Time,
Display<Double> {}
Thus pvManager present all data via a single interface. But instead of
proving 3456 interfaces it provides just 8 interfaces. It does this by
limiting choices are follows:
The value data types supported are int32, float64, string, and enum.
For each a scalar or array is supported.
For each data type all of alarm, timeStamp, and display are included.
I believe that it will be very hard to provide an efficient
implementations for either V3 CA or for pvAccess.
Marty
|
|
From: Marty K. <mrk...@co...> - 2010-09-07 10:52:46
|
On 09/03/2010 06:59 AM, Dalesio, Leo wrote: > > I am attaching a couple of slides that attempt to describe what is > being proposed (and I thought we had agreed to) at the meeting we had > at BNL. > It changes the alarm status to a bitset. Multiple alarm statuses are > true at the same time - which reflects real life. > I agree that being able to expose device status info to CA clients is a desirable goal. Where I have a problem is making it a required component of alarm. This is a generic issue: Should of set of components be presented as a single object or as a set of objects. For a client this means presented as a single interface or as a set of interfaces. The following are three example of where this issue has been the basis of heated arguments. 1) The javaIOC allows each field to have optional support. For example the scan field has scan support. An input field can have any of a large set of supports attached. In fact an input field could have linearConvert support attached and have a subfield named input that can again have any of a large set of different supports to get a raw value. A valueAlarm field can have valueAlarm support attached. And so on an so on. The issue is how to construct a database record. One way is the V3 way, which means that a set of basic record types, with each type having a fixed set of fields. Thus record types ai, ao, bi, bo, mbbi, etc. Another way is to construct a record based on what it does. As an example a record template can be created based on: 1) the specific device, 2) the communication bus, 3) valueLimits if they make sense, etc. 2) pvManager data, i.e. value, timeStamp, alarm, and display. How should this be presented to the client? One way is a fixed set of interfaces like DoubleTimeStampAlarmDisplay or as a set of interfaces like Double,TimeStamp,Alarm,Display. 3) Alarm. This is the issues currently being addressed. Assume there are three components severity, message, and deviceStatus. I know this is has not been agreed upon as the three components but it is details. The issue is how is the presented to a client: As a single interface named alarm that has all three components or as multiple interfaces. Thus this is really 2) appearing at a different level. I am going to start another thread giving arguments why I think a set of objects is much better than a single object. The thread will concentrate on 2) but the same arguments can be made about 1). |
|
From: Marty K. <mrk...@co...> - 2010-09-03 09:22:18
|
On 09/02/2010 10:06 AM, Ralph Lange wrote: > 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. > Since I did not describe what structure deviceStatus contains, there is no specification. I only suggested that deviceStatus should not be part of alarm. > I would say that ease of implementation is a valid argument when > finalizing a design, but should not be taken into account earlier. > If the requirements are to apply to many different types of client and many different types of servers than ease of implementation should be thought about early. Marty |
1 message has been excluded from this view by a project administrator.
