I posted my response not to get you to change what you are doing, but to
warn others that their systems behavior may be different and that the
difference can cause trouble.
There is no hard limit. Basically, there is a 50 entry queue in the CP for
incoming IPC messages. If the queue is full, messages are dropped. If the
dropped message is on a connected communication, the software will retry. If
however the message is a one-shot, the message is lost.
The impact of a lost message varies. If one is using 'set_confirm' the
read-back will flag the fact that the value did not change. If one is using
'setval', the application had better let the user know from its GUI, e.g.,
by not setting the value.
However, if the dropped message is a broadcast, it is really lost and the
application that made the call will just assume that it is looking for a tag
that does not exist.
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).
BTW. A FoxWatch report on the average number of packets on your nodebus is a
real good indication of how close you are to being in trouble. Anything less
than 300 packets/sec is great. Anything more than 600 packets/second is
probably going to lead to trouble eventually.
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: Stephen Murray [SMTP:[EMAIL PROTECTED]]
Sent: Monday, March 13, 2000 8:07 PM
To: Foxboro DCS Mail List
Subject: Re: Browser access to Foxboro graphics.
Hi Alex,
I agree that omget is not the best way to get data but it works and the
scripts are easy to alter. When I first cooked up this scheme two years ago
I could not get any Foxboro people to commit to what a "reasonable" number
of omgets were and how far apart they should be spaced.. At one time I had
a script that called omget three times, with about 25 values per omget. I
slept 2 seconds between calls, and the best advice from Foxboro was "see if
it causes a problem". I never saw any problems, and no perceptible loading
on the system.
My current script still calls omget three times, but only reads 14, 22,
and 12 values. I still sleep 2 seconds between omgets, and this has been
running every two minutes for the last few years.
I am using the regular Historian Report Scheduler to run a report after
shift changes, and every morning to pick up the shift & daily numbers.
These values are basically "static", so omgetting them would be a waste.
These static values are in a separate text file & get mixed in with the live
values when my perl script generates a new html document.
I really should write a program to read the live data, but it always seems
to get pushed to the back burner.
Stephen Murray
Original Message -----
From: Johnson,Alex <[EMAIL PROTECTED]>
To: Foxboro DCS Mail List <[EMAIL PROTECTED]>
Sent: Monday, March 13, 2000 12:27 PM
Subject: RE: Browser access to Foxboro graphics.
>Re: a simple script to "omget" about a hundred key values and write them to
>a text file
>
>I would not recommend the use of "omget" for this type of service as a
>general solution. Omget uses unoptimized getval calls to retrieve the data
>from the process.
>
>These calls generate a broadcast message for each value. Broadcast messages
>of this sort can cause significant performance problems in larger systems.
>One more than one large system, I've seen significant problems due to high
>and generally unnecessary broadcast traffic.
-----------------------------------------------------------------------
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]
