Your primary assumption on the operation of the OM is wrong. The cycle is more or less as follows: * Client application specifies a list of tags that it wants updates on and hands the list to the OM. * The OM in the client station puts the list on the wire as a broadcast. * The OM in EVERY I/A Series station receives the broadcasted list and reviews it for tags that it owns. * If the OM that receives the broadcast owns some of the tags on the list, it establishes a point-to-point communication channel (IPC Channel/OM Channel) to the requesting station. * The OM that owns the data then sends updates to the requesting station and only the requesting station on a periodic basis. A message may be generated on the period, but will be sent if and only if there are actual changes. * The requesting station's OM gets the updates and passes them back to the original client. As you can see, a broadcast is used only for location of the data. The owner of the data never broadcasts requested values. There is a 2s heartbeat on the link so that slowly changing data can be discriminated from a broken link. Does this help? Regards, Alex Johnson Invensys 10707 Haddington Houston, TX 77063 713.722.2859 (office) 713.722.2700 (switchboard) 713.932.0222 (fax) ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx> For the latest information on ArchestrA, go to www.invensys.com/Archestra.html <http://www.invensys.com/divisions/Archestra.html> . -----Original Message----- From: stan [SMTP:stanb@xxxxxxxx] Sent: Wednesday, December 11, 2002 10:51 AM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0 On Wed, Dec 11, 2002 at 10:34:10AM -0500, Johnson, Alex (Foxboro) wrote: > > Re: Now, I'm wondering if this was a waste of time? It appears that the > fastest_rsr parameter will override anything we do. Is this correct? > > Thanks for all the useful information. If you don't mind, in the interest of further educating myself, I'd like to pursue this a bit further. It appears that I have a basic misunderstanding of how this whole thing works. let me describe how _I thought_ it worked, and you can use that as a basis for correcting my misconception(s0. I thought that a given data object (C:B:P) was "owned" by a piece of hardware (typically a CP for instance). Then this "owner" would broadcast the value of this data object, based upon the delta from the last time it was broadcast. In other words if the configuration called for a delta of 1% and the object's scale was, say 0 ->100, and the last broadcast value was 56%, then a new broadcast would be sent when the value changed beyond 55% or 57%. Then I thought that various "data consumers" (for example FoxAPI, simply listened for these broadcasts. In the case of FoxAPI these changes would be used to update a shared memory copy of tag/value pairs. Other "downstream data consumers", such as PI could then poll FoxAPI at whatever rate they wanted to, and get the these value from the shared memory copy. Having said all of the above, there is no place in such a design for a parameter such as fastest_rsr to impact anything. Where am I going wrong? -- "They that would give up essential liberty for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin _______________________________________________________________________ This mailing list is neither sponsored nor endorsed by Invensys Process Systems (formerly The Foxboro Company). Use the info you obtain here at your own risks. Read http://www.thecassandraproject.org/disclaimer.html foxboro mailing list: http://www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave _______________________________________________________________________ This mailing list is neither sponsored nor endorsed by Invensys Process Systems (formerly The Foxboro Company). Use the info you obtain here at your own risks. Read http://www.thecassandraproject.org/disclaimer.html foxboro mailing list: http://www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave