John Kilbornn
|
PPS object attribute order
|
John Kilbornn
08/31/2011 6:23 PM
post88562
|
PPS object attribute order
My software writes the following string to an "HR" PPS object:
"is_valid::TRUE\nHR::0\n"
When I subsequently read from the object, I get the following string:
"@HR\nHR::0\nis_valid::TRUE\n"
Obviously, the order of the attributes in my read result is not what I expected. Is the first string above the correct
way to write multiple attributes to a PPS object?
Thanks,
Chris
|
|
|
Elena Laskavaia
|
Re: PPS object attribute order
|
Elena Laskavaia
09/01/2011 9:05 AM
post88578
|
Re: PPS object attribute order
It is up the server that manages this object to print it in whatever way it likes
On 08/31/2011 06:23 PM, John Kilbornn wrote:
> My software writes the following string to an "HR" PPS object:
>
> "is_valid::TRUE\nHR::0\n"
>
> When I subsequently read from the object, I get the following string:
>
> "@HR\nHR::0\nis_valid::TRUE\n"
>
> Obviously, the order of the attributes in my read result is not what I expected. Is the first string above the correct
way to write multiple attributes to a PPS object?
>
> Thanks,
> Chris
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88562
>
|
|
|
John Kilbornn
|
RE: PPS object attribute order
|
John Kilbornn
09/01/2011 12:20 PM
post88587
|
RE: PPS object attribute order
So it appears that PPS alphabetizes attributes in the PPS object,
inserting uppercase attributes before lowercase attributes. Correct?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 8:05 AM
To: general-community
Subject: Re: PPS object attribute order
It is up the server that manages this object to print it in whatever way
it likes
On 08/31/2011 06:23 PM, John Kilbornn wrote:
> My software writes the following string to an "HR" PPS object:
>
> "is_valid::TRUE\nHR::0\n"
>
> When I subsequently read from the object, I get the following string:
>
> "@HR\nHR::0\nis_valid::TRUE\n"
>
> Obviously, the order of the attributes in my read result is not what I
expected. Is the first string above the correct way to write multiple
attributes to a PPS object?
>
> Thanks,
> Chris
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88562
>
_______________________________________________
General
http://community.qnx.com/sf/go/post88578
|
|
|
Max Feil
|
RE: PPS object attribute order
|
Max Feil
09/01/2011 1:37 PM
post88594
|
RE: PPS object attribute order
Alphabetic order has been my experience in the past, but this is
something that should not be relied upon as this may change in the
future. It is not difficult to manipulate PPS objects and attributes in
a way that is not dependent on read order.
-----Original Message-----
From: John Kilbornn [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:21 PM
To: general-community
Subject: RE: PPS object attribute order
So it appears that PPS alphabetizes attributes in the PPS object,
inserting uppercase attributes before lowercase attributes. Correct?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 8:05 AM
To: general-community
Subject: Re: PPS object attribute order
It is up the server that manages this object to print it in whatever way
it likes
On 08/31/2011 06:23 PM, John Kilbornn wrote:
> My software writes the following string to an "HR" PPS object:
>
> "is_valid::TRUE\nHR::0\n"
>
> When I subsequently read from the object, I get the following string:
>
> "@HR\nHR::0\nis_valid::TRUE\n"
>
> Obviously, the order of the attributes in my read result is not what I
expected. Is the first string above the correct way to write multiple
attributes to a PPS object?
>
> Thanks,
> Chris
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88562
>
_______________________________________________
General
http://community.qnx.com/sf/go/post88578
_______________________________________________
General
http://community.qnx.com/sf/go/post88587
|
|
|
John Kilbornn
|
RE: PPS object attribute order
|
John Kilbornn
09/01/2011 1:53 PM
post88596
|
RE: PPS object attribute order
Thanks. I'm not counting on it; I'm trying to work around it.
I rather not do string compares on just-read attribute names to
associate them with the appropriate area on our GUI, since string
compares are time-consuming as the number of attributes in the PPS
object increases. I'm planning on alphabetizing my GUI update routines
in an array at startup so they align with the PPS-alphabetized
attributes in the PPS objects (i.e., so they appear in the same order in
the array as the attributes do in my PPS read buffer), thus eliminating
the need for lots of string compares. Obviously, this isn't a good idea
if the PPS-alphabetizing will change in the future. Do you have any
other suggestions?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Max Feil [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:37 PM
To: general-community
Subject: RE: PPS object attribute order
Alphabetic order has been my experience in the past, but this is
something that should not be relied upon as this may change in the
future. It is not difficult to manipulate PPS objects and attributes in
a way that is not dependent on read order.
-----Original Message-----
From: John Kilbornn [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:21 PM
To: general-community
Subject: RE: PPS object attribute order
So it appears that PPS alphabetizes attributes in the PPS object,
inserting uppercase attributes before lowercase attributes. Correct?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 8:05 AM
To: general-community
Subject: Re: PPS object attribute order
It is up the server that manages this object to print it in whatever way
it likes
On 08/31/2011 06:23 PM, John Kilbornn wrote:
> My software writes the following string to an "HR" PPS object:
>
> "is_valid::TRUE\nHR::0\n"
>
> When I subsequently read from the object, I get the following string:
>
> "@HR\nHR::0\nis_valid::TRUE\n"
>
> Obviously, the order of the attributes in my read result is not what I
expected. Is the first string above the correct way to write multiple
attributes to a PPS object?
>
> Thanks,
> Chris
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88562
>
_______________________________________________
General
http://community.qnx.com/sf/go/post88578
_______________________________________________
General
http://community.qnx.com/sf/go/post88587
_______________________________________________
General
http://community.qnx.com/sf/go/post88594
|
|
|
Elena Laskavaia
|
Re: PPS object attribute order
|
Elena Laskavaia
09/01/2011 1:57 PM
post88597
|
Re: PPS object attribute order
How many times per second it will read this object? I doubt string comparison would a bottleneck of you application
On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it.
>
> I rather not do string compares on just-read attribute names to
> associate them with the appropriate area on our GUI, since string
> compares are time-consuming as the number of attributes in the PPS
> object increases. I'm planning on alphabetizing my GUI update routines
> in an array at startup so they align with the PPS-alphabetized
> attributes in the PPS objects (i.e., so they appear in the same order in
> the array as the attributes do in my PPS read buffer), thus eliminating
> the need for lots of string compares. Obviously, this isn't a good idea
> if the PPS-alphabetizing will change in the future. Do you have any
> other suggestions?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Max Feil [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:37 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> Alphabetic order has been my experience in the past, but this is
> something that should not be relied upon as this may change in the
> future. It is not difficult to manipulate PPS objects and attributes in
> a way that is not dependent on read order.
>
> -----Original Message-----
> From: John Kilbornn [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:21 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> So it appears that PPS alphabetizes attributes in the PPS object,
> inserting uppercase attributes before lowercase attributes. Correct?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Elena Laskavaia [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 8:05 AM
> To: general-community
> Subject: Re: PPS object attribute order
>
> It is up the server that manages this object to print it in whatever way
> it likes
>
> On 08/31/2011 06:23 PM, John Kilbornn wrote:
>> My software writes the following string to an "HR" PPS object:
>>
>> "is_valid::TRUE\nHR::0\n"
>>
>> When I subsequently read from the object, I get the following string:
>>
>> "@HR\nHR::0\nis_valid::TRUE\n"
>>
>> Obviously, the order of the attributes in my read result is not what I
> expected. Is the first string above the correct way to write multiple
> attributes to a PPS object?
>>
>> Thanks,
>> Chris
>>
>>
>>
>> _______________________________________________
>>
>> General
>> http://community.qnx.com/sf/go/post88562
>>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88578
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88587
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88594
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post88596
>
|
|
|
John Kilbornn
|
RE: PPS object attribute order
|
John Kilbornn
09/01/2011 2:06 PM
post88598
|
RE: PPS object attribute order
Maximum would be reading 8 different PPS objects 250 times a second;
each of these would have only 2 attributes, so only one 2 string
compares. We have PPS Objects with many more attributes (> 10), but
reads will be much more infrequent on these.
I can probably get by with string comparisons, but it feels very
inefficient for an embedded, real-time system. I assume there's no way
to specify the order that attributes appear in the read buffer using the
file descriptor argument of the read() routine?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:58 PM
To: general-community
Subject: Re: PPS object attribute order
How many times per second it will read this object? I doubt string
comparison would a bottleneck of you application
On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it.
>
> I rather not do string compares on just-read attribute names to
> associate them with the appropriate area on our GUI, since string
> compares are time-consuming as the number of attributes in the PPS
> object increases. I'm planning on alphabetizing my GUI update routines
> in an array at startup so they align with the PPS-alphabetized
> attributes in the PPS objects (i.e., so they appear in the same order
in
> the array as the attributes do in my PPS read buffer), thus
eliminating
> the need for lots of string compares. Obviously, this isn't a good
idea
> if the PPS-alphabetizing will change in the future. Do you have any
> other suggestions?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Max Feil [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:37 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> Alphabetic order has been my experience in the past, but this is
> something that should not be relied upon as this may change in the
> future. It is not difficult to manipulate PPS objects and attributes
in
> a way that is not dependent on read order.
>
> -----Original Message-----
> From: John Kilbornn [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:21 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> So it appears that PPS alphabetizes attributes in the PPS object,
> inserting uppercase attributes before lowercase attributes. Correct?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Elena Laskavaia [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 8:05 AM
> To: general-community
> Subject: Re: PPS object attribute order
>
> It is up the server that manages this object to print it in whatever
way
> it likes
>
> On 08/31/2011 06:23 PM, John Kilbornn wrote:
>> My software writes the following string to an "HR" PPS object:
>>
>> "is_valid::TRUE\nHR::0\n"
>>
>> When I subsequently read from the object, I get the following string:
>>
>> "@HR\nHR::0\nis_valid::TRUE\n"
>>
>> Obviously, the order of the attributes in my read result is not what
I
> expected. Is the first string...
View Full Message
|
|
|
Mario Charest
|
RE: PPS object attribute order
|
Mario Charest
09/01/2011 2:16 PM
post88599
|
RE: PPS object attribute order
Couldn't you cache them, register for notification if the entries changed, and update the cache as needed. Then use
whatever method you like to arrange the cache in the most efficient way, using the string as a hash key for example.
-----Message d'origine-----
De : John Kilbornn [mailto:community-noreply@qnx.com]
Envoyé : 1 septembre 2011 15:06
À : general-community
Objet : RE: PPS object attribute order
Maximum would be reading 8 different PPS objects 250 times a second; each of these would have only 2 attributes, so only
one 2 string compares. We have PPS Objects with many more attributes (> 10), but reads will be much more infrequent on
these.
I can probably get by with string comparisons, but it feels very inefficient for an embedded, real-time system. I assume
there's no way to specify the order that attributes appear in the read buffer using the file descriptor argument of the
read() routine?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:58 PM
To: general-community
Subject: Re: PPS object attribute order
How many times per second it will read this object? I doubt string comparison would a bottleneck of you application
On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it.
>
> I rather not do string compares on just-read attribute names to
> associate them with the appropriate area on our GUI, since string
> compares are time-consuming as the number of attributes in the PPS
> object increases. I'm planning on alphabetizing my GUI update routines
> in an array at startup so they align with the PPS-alphabetized
> attributes in the PPS objects (i.e., so they appear in the same order
in
> the array as the attributes do in my PPS read buffer), thus
eliminating
> the need for lots of string compares. Obviously, this isn't a good
idea
> if the PPS-alphabetizing will change in the future. Do you have any
> other suggestions?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Max Feil [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:37 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> Alphabetic order has been my experience in the past, but this is
> something that should not be relied upon as this may change in the
> future. It is not difficult to manipulate PPS objects and attributes
in
> a way that is not dependent on read order.
>
> -----Original Message-----
> From: John Kilbornn [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:21 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> So it appears that PPS alphabetizes attributes in the PPS object,
> inserting uppercase attributes before lowercase attributes. Correct?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Elena Laskavaia [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 8:05 AM
> To: general-community
> Subject: Re: PPS object attribute order
>
> It is up the server that manages this object to print it in whatever
way
> it likes
>
> On 08/31/2011...
View Full Message
|
|
|
John Kilbornn
|
RE: PPS object attribute order
|
John Kilbornn
09/01/2011 2:24 PM
post88600
|
RE: PPS object attribute order
That would work, but I was hoping for a simpler, generic way of handling it (i.e., it would have been nice if the order
of attributes in the read buffer mirrored the order of attributes in the original write buffer -- seems logical!). Most
of the PPS objects in our system have only a few attributes, so hash tables would be overkill for all but a few PPS
objects. I'll probably just do string compares.
Thanks for the suggestion!
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 1:17 PM
To: general-community
Subject: RE: PPS object attribute order
Couldn't you cache them, register for notification if the entries changed, and update the cache as needed. Then use
whatever method you like to arrange the cache in the most efficient way, using the string as a hash key for example.
-----Message d'origine-----
De : John Kilbornn [mailto:community-noreply@qnx.com]
Envoyé : 1 septembre 2011 15:06
À : general-community
Objet : RE: PPS object attribute order
Maximum would be reading 8 different PPS objects 250 times a second; each of these would have only 2 attributes, so only
one 2 string compares. We have PPS Objects with many more attributes (> 10), but reads will be much more infrequent on
these.
I can probably get by with string comparisons, but it feels very inefficient for an embedded, real-time system. I assume
there's no way to specify the order that attributes appear in the read buffer using the file descriptor argument of the
read() routine?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:58 PM
To: general-community
Subject: Re: PPS object attribute order
How many times per second it will read this object? I doubt string comparison would a bottleneck of you application
On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it.
>
> I rather not do string compares on just-read attribute names to
> associate them with the appropriate area on our GUI, since string
> compares are time-consuming as the number of attributes in the PPS
> object increases. I'm planning on alphabetizing my GUI update routines
> in an array at startup so they align with the PPS-alphabetized
> attributes in the PPS objects (i.e., so they appear in the same order
in
> the array as the attributes do in my PPS read buffer), thus
eliminating
> the need for lots of string compares. Obviously, this isn't a good
idea
> if the PPS-alphabetizing will change in the future. Do you have any
> other suggestions?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c: 312.287.5201 v1: 224.216.2141
> v2: 913.385.5700x307 f: 913.385.5701
>
> Engage Success
>
> -----Original Message-----
> From: Max Feil [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:37 PM
> To: general-community
> Subject: RE: PPS object attribute order
>
> Alphabetic order has been my experience in the past, but this is
> something that should not be relied upon as this may change in the
> future. It is not difficult to manipulate PPS objects and attributes
in
> a way that is not dependent on read order.
>
> -----Original Message-----
> From: John Kilbornn [mailto:community-noreply@qnx.com]
> Sent: Thursday, September 01, 2011 12:21...
View Full Message
|
|
|
Douglas Bailey
|
RE: PPS object attribute order
|
Douglas Bailey
09/01/2011 6:47 PM
post88609
|
RE: PPS object attribute order
Keep in mind that PPS is not intended as a high performance data channel. Unless your attribute values are changing
frequently, what you are suggesting is a really bad design. All of those PPS reads will most likely be very inefficient
. You should take Mario's suggestion and open the objects with ?delta and cache the values. Use a second thread to do
this reading if necessary. Then you can order them in your own data structures however you like, and your 250hz read
loop need only read the values from your own data structures -- much more efficient.
-----Original Message-----
From: John Kilbornn [mailto:community-noreply@qnx.com]
Sent: Thu 9/1/2011 14:24
To: general-community
Subject: RE: PPS object attribute order
That would work, but I was hoping for a simpler, generic way of handling it (i.e., it would have been nice if the order
of attributes in the read buffer mirrored the order of attributes in the original write buffer -- seems logical!). Most
of the PPS objects in our system have only a few attributes, so hash tables would be overkill for all but a few PPS
objects. I'll probably just do string compares.
Thanks for the suggestion!
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 1:17 PM
To: general-community
Subject: RE: PPS object attribute order
Couldn't you cache them, register for notification if the entries changed, and update the cache as needed. Then use
whatever method you like to arrange the cache in the most efficient way, using the string as a hash key for example.
-----Message d'origine-----
De�: John Kilbornn [mailto:community-noreply@qnx.com]
Envoy��: 1 septembre 2011 15:06
��: general-community
Objet�: RE: PPS object attribute order
Maximum would be reading 8 different PPS objects 250 times a second; each of these would have only 2 attributes, so only
one 2 string compares. We have PPS Objects with many more attributes (> 10), but reads will be much more infrequent on
these.
I can probably get by with string comparisons, but it feels very inefficient for an embedded, real-time system. I assume
there's no way to specify the order that attributes appear in the read buffer using the file descriptor argument of the
read() routine?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:58 PM
To: general-community
Subject: Re: PPS object attribute order
How many times per second it will read this object? I doubt string comparison would a bottleneck of you application
On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it.
>
> I rather not do string compares on just-read attribute names to
> associate them with the appropriate area on our GUI, since string
> compares are time-consuming as the number of attributes in the PPS
> object increases. I'm planning on alphabetizing my GUI update routines
> in an array at startup so they align with the PPS-alphabetized
> attributes in the PPS objects (i.e., so they appear in the same order
in
> the array as the attributes do in my PPS read buffer), thus
eliminating
> the need for lots of string compares. Obviously, this isn't a good
idea
> if the PPS-alphabetizing will change in the future. Do you have any
> other suggestions?
>
> Chris Kilborn
> RBC MEDICAL INNOVATIONS
> http://www.rbccorp.com
> mailto: ckilborn@rbccorp.com
> c:...
View Full Message
|
|
|
John Kilbornn
|
RE: PPS object attribute order
|
John Kilbornn
09/02/2011 8:09 PM
post88626
|
RE: PPS object attribute order
My apologies, I meant 250 times per minute, not per second, for the high read-rate PPS objects. I'm already caching the
PPS data. I believe the ?delta option is of marginal benefit for these ~4Hz PPS objects since they only have 2
attributes. The other PPS objects are updated very infrequently - typically once a day.
Thanks for your help.
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Douglas Bailey [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 5:47 PM
To: general-community
Subject: RE: PPS object attribute order
Keep in mind that PPS is not intended as a high performance data channel. Unless your attribute values are changing
frequently, what you are suggesting is a really bad design. All of those PPS reads will most likely be very inefficient
. You should take Mario's suggestion and open the objects with ?delta and cache the values. Use a second thread to do
this reading if necessary. Then you can order them in your own data structures however you like, and your 250hz read
loop need only read the values from your own data structures -- much more efficient.
-----Original Message-----
From: John Kilbornn [mailto:community-noreply@qnx.com]
Sent: Thu 9/1/2011 14:24
To: general-community
Subject: RE: PPS object attribute order
That would work, but I was hoping for a simpler, generic way of handling it (i.e., it would have been nice if the order
of attributes in the read buffer mirrored the order of attributes in the original write buffer -- seems logical!). Most
of the PPS objects in our system have only a few attributes, so hash tables would be overkill for all but a few PPS
objects. I'll probably just do string compares.
Thanks for the suggestion!
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 1:17 PM
To: general-community
Subject: RE: PPS object attribute order
Couldn't you cache them, register for notification if the entries changed, and update the cache as needed. Then use
whatever method you like to arrange the cache in the most efficient way, using the string as a hash key for example.
-----Message d'origine-----
De�: John Kilbornn [mailto:community-noreply@qnx.com]
Envoy��: 1 septembre 2011 15:06
��: general-community
Objet�: RE: PPS object attribute order
Maximum would be reading 8 different PPS objects 250 times a second; each of these would have only 2 attributes, so only
one 2 string compares. We have PPS Objects with many more attributes (> 10), but reads will be much more infrequent on
these.
I can probably get by with string comparisons, but it feels very inefficient for an embedded, real-time system. I assume
there's no way to specify the order that attributes appear in the read buffer using the file descriptor argument of the
read() routine?
Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201 v1: 224.216.2141
v2: 913.385.5700x307 f: 913.385.5701
Engage Success
-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:58 PM
To: general-community
Subject: Re: PPS object attribute order
How many times per second it will read this object? I doubt string comparison would a bottleneck of you application
On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it.
>
> I rather not do string compares on just-read attribute names to
> associate them with...
View Full Message
|
|
|
|