Darryl,
Are you really saving a pointer to the memory location? or the PSAP address
of the variable?
I'd be pretty interested if you are actually accessing the OM's shared
memory segment directly. If so, I hope you are very, very careful about how
you access it to ensure that someone is not writing to your value when you
are reading it and that other equally bad things don't happen.
On the assumption you are using global_find and getting the PSAP from it.
Then you can indeed eliminate the broadcast message generated by some of the
get/set calls by specifying the PSAP address.
An easier way to eliminate the broadcasts is to simply set the import flag
on the getval/setval call. The system will do the same thing for you.
However, the import table has a limited size. It will hold one entry for
each Top Level Name (Compound name, SV name, or Application name, if you
have AOS). So, if you have large number of TLNs, you may need to resize the
OM to support it.
The command show_params will show you how full the table is.
Resizing instructions are in B0193MJ.
If one wanted to, one could write a version of omget/omset that had the
import flag set and use it to eliminate the broadcasts while still retaining
the scripting approach to the problem as a whole.
One caution though, even optimized one-shots use a full message slot per
get/set and the CP buffer is only 50 entries deep. You could easily fill the
buffer temporarily if an AW50 box is requesting lots of values from the same
station.
Regards,
Alex Johnson
The Foxboro Company
10707 Haddington
Houston, TX 77043
713.722.2859 (v)
713.722.2700 (sb)
713.932.0222 (f)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: Darryl Bond [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, March 14, 2000 5:05 PM
To: [EMAIL PROTECTED]
Subject: RE: Browser access to Foxboro graphics.
Some years ago I had to send and receive data from a linux box to
Foxboro object manager variables. The program was done as an RPC
client/server program and could handle 100 points at a time.
I also ran into the number of broadcasts generated so I used a system
that keeps an in-memory database of the pointers to the actual OM
variables.
If the point is not in the in-memory database then it broadcasts for it
and puts the pointer into the database. The size of the database is
configurable at startup and uses shared memory.
I did not want to use OM lists as some of our CP's are heavily loaded
with regard to this.
The code works for Linux->Foxboro Sun, Sun->Foxboro Sun.
I have also used it for out Intranet to display variables as well.
The code is not particularly pretty and could use a bit of a tidy up. I
don't believe that my organisation would mind releasing it if somebody
else wanted it.
There is also a program to retrieve historian data from a shell script.
I also use this for Intranet access to historian data.
--
Darryl Bond
NRG Gladstone Operating Services Pty Ltd ( Gladstone Power Station )
[email: [EMAIL PROTECTED]] [voice: (07) 49 765756] [fax: (07) 49
765100]
snail: PO Box 5046 Gladstone 4680 Queensland , Australia
>----------
>From: Murray, Steve[SMTP:[EMAIL PROTECTED]]
>Reply To: Foxboro DCS Mail List
>Sent: Wednesday, 15 March 2000 5:30
>To: 'Foxboro DCS Mail List'
>Subject: RE: Browser access to Foxboro graphics.
>Hi Alex,
> Thanks for the additional information on broadcasts. I guess the
reason it works ok on my system is >that I have only one node, three CP40s,
and two gateways.
>Stephen Murray
> -----Original Message-----
> From: Johnson,Alex [ mailto:[EMAIL PROTECTED]]
> So, in a nutshell, be cautious in the use of 'omget' and
> 'omset' and do not
> assume that they will meet the need in all cases on all systems (esp.
> multi-node systems).
>
-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.
To be removed from this list, send mail to [EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]
