Re: [foxboro] Change delta/peer-to-peer questions
- From: "Tom VandeWater" <tom@xxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 12 Jun 2002 07:30:41 -0500
As usual, Alex has the full scoop on the questions. Alex, is there a
single document that contains all of this information on change deltas or is
this a brain dump of your personal "upstairs" archive. Like Corey, I'd like
to be able to find it in a .pdf document, just in case Foxboro tries to put
a muzzle on you. That's not likely since you problably are keeping the lines
at the CSC, from being overloaded more than they already are. Thanks for
continuing to share. If that isn't a part of your job description, it
should be. I've learned several of the lessons you talk about through
experience, (not all good)!! There are some "new" learnings notably:
>You are incorrect that DELTOx is not used. It can be used by applications
> like the DM/FV.
Can you expound on that statement a little. I wasn't aware that the DELTOx
had any play in display call-up. Is it only used when invoked by a custom
DM/FV command? Or used commonly by Foxboro to limit communication traffic?
Thanks for the insights!
Tom VandeWater
Dow Corning Corp.
Carrollton, KY
----- Original Message -----
From: "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Tuesday, June 11, 2002 6:11 PM
Subject: Re: [foxboro] Change delta/peer-to-peer questions
>
> Rules on Change Deltas:
>
>
> 1) The consumer/sink of the data sets the delta.
> 2) The OM uses deltas in engineering units not percent of span.
>
>
>
> Rules of DELTxy in Control Stations where x=[I|O] and y=[1|2|3]
>
>
> 1. The DELTxy parameters are in % NOT engineering units.
> 2. Generally, there is a DELTxy parameter for each set of different
> engineering units that a block may have to deal with, e.g., MEAS in gpm
and
> OUT in %.
> 3. Not all blocks have a DELTxy parameter for each input/output that
> may have different engineering units, e.g., CALCA block.
> 4. The DELTxy parameters are used to
> a. Support the display of the block parameter on a detail display
> either directly or indirectly through Rxy.
> b. Support peer-to-peer communications over the I/A Series Control
> Network
> 5. The DELTxy parameters are NOT used in intra-Control Station
> communication.
> 6. The HSCxy, LSCxy, and DELTxy are also found in the parameter Rxy.
> a. The Rxy parameter is an array of three floating point values.
> b. The first value is the HSC, the second the LSC, and the third is the
> DELT.
> c. The Rxy parameter is maintained by the Control Station.
> d. The association of a given parameter with a particular Range
> Variable (Rxy) is implied by its assocation with a given
HSCxy/LSCxy/DELTxy
> set. For example, .SPT is associated with HSCO1/LSCO1/DELTO1 and therefore
> RO1.
> e. The FoxDoc documentation for the control blocks lists these
> associations.
> 7. When Control Station opens the OM lists to implement peer-to-peer,
> it converts the DELTxy associated with the sink parameter into engineering
> units.
>
>
>
> Rules of deltas in displays
>
>
> 1. Displays have deltas for all change driven connections as part of
> the connection configuration.
> 2. The default delta is 0.5 which is not 0.5% of span, but 0.5
> engineering units.
> 3. The connection notation C:B.P|RI1 tells the DM to get the scaling
> information from the RI1 attribute of C:B and used it to set the delta to
> the source of the data and to scale the value. It can also be used to
limit
> the change to a values.
>
>
> Now, let's look at your questions.
>
>
>
> Re: DELTIx: change delta in % of range. Only used with peer-to-peer
> connections: not applicable in intra-CP links. DELTOx: Not currently used.
> Are these correct?
>
>
> You are correct that parameters associated with DELTIx will use this value
> to calculate the change delta used to read the source value.
>
>
> You are incorrect that DELTOx is not use. It can be used by applications
> like the DM/FV.
>
>
>
> Re: Also, let's say I have multiple connections from different blocks (or
> maybe the same block, but this would not often be the case) in CP1 to a
> single C:B:P in CP2. Will CP1 optimize these and make only one connection
> to CP1, from which it distributes the value to all the destination points
it
> contains?
>
>
> Optimization is always a function of the consumer of the data. The OM does
> not optimize. FoxAPI/AIM*API optimizes for its clients, e.g., AIM* with
the
> right setting, OSI PI, IP.21. The DM/FV optimize within a given graphic,
but
> not across graphics on the same WP. The Control Stations are no different.
>
>
> The Control Station that is receiving the data will optimize its lists to
> ask the source Control Station for the value once. The change delta is the
> smallest one requested. Please note that this is not the original behavior
> of the Control Station. Originally, it opened a separate 1 point list for
> each remote piece of data. This quickly became multiple points on a list.
> Less quickly, it became an optimized list. You can see this with rsom if
you
> feel adventurous.
>
>
> By the way, the DM/FV originally did not optimize either. So a display
with
> the same point on it 100 times put the same load on the Control Station as
> 100 different points. This too has been changed.
>
>
> The legacy historian does not optimize at all.
>
>
> AIM*HIstorian lets AIM*API optimize for it.
>
>
> AIM*API and FoxAPI can share OM lists which can result in multiple
> applications (historians) accessing shared points with no increase in load
> on the Control Station or the Control Network.
>
>
>
> Re: If CP1 does optimize, will it still do so if the blocks are in
different
> compounds, or process at different periods/phases?
>
>
> The OM is asynchronous with the Block Processor so periods and phases have
> no direct impact. The OM checks every 0.5 seconds (regardless of BPC) for
> changes at the source Control Station and reports those values to the sink
> application (CS, historian, DM/FV, etc.)
>
>
> Compounds make no difference at all.
>
>
>
> 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>
> Come to the Invensys Showcase: http://www.invensysshowcase.com/
> <http://www.invensysshowcase.com/>
>
>
> -----Original Message-----
> From: Corey R Clingo [SMTP:clingoc@xxxxxxxxxxxxx]
> Sent: Tuesday, June 11, 2002 5:30 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Change delta/peer-to-peer questions
>
>
>
> Hello all,
>
> I have a couple of questions about change deltas and peer-to-peer
> connections that maybe some of you who can draw a CP's PCB from
> memory can
> help me with :)
>
> It seems that all the I/A points have some kind of DELTIx and DELTOx
> parameters. The documentation is not completely consistent about
> these,
> but I've made a few assumptions based on the majority of the
> documentation
> and, in some cases, some experimentation.
>
> DELTIx: change delta in % of range. Only used with peer-to-peer
> connections: not applicable in intra-CP links.
> DELTOx: Not currently used.
>
> Are these correct?
>
> Also, let's say I have multiple connections from different blocks
> (or maybe
> the same block, but this would not often be the case) in CP1 to a
> single
> C:B:P in CP2. Will CP1 optimize these and make only one connection
> to CP1,
> from which it distributes the value to all the destination points it
> contains? Or will it make one connection for each link? If CP1
> does
> optimize, will it still do so if the blocks are in different
> compounds, or
> process at different periods/phases?
>
> As a final note, we did a 6.2.1 to 6.3 upgrade recently, and so I
> took a
> look at the 6.3 docs. I appreciate the PDF format, as it is much
> easier to
> print out (yes, I still like books). I looked at the docs for the
> PIDA
> block specifically, and noticed that it finally includes a full
> block
> diagram, algorithm equations and a few examples of how to use it.
> Outstanding! I criticize Invensys a lot, and I feel documentation
> is one
> of their weak spots, so I want to compliment them on this effort,
> and hope
> to see more in the future. Thanks, guys (and gals)!
>
> Corey Clingo
> Sr. Engineer
> BASF Corp.
>
>
>
>
> _______________________________________________________________________
> 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:
> //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: //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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
