Re: [foxboro] Change delta/peer-to-peer questions
- From: Martin Theobald <m.theobald@xxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 17 Jun 2002 21:50:06 +0100
If I remember rightly, when you use the Wizard to add a parameter to the
AIM* historian, it takes the value from the relvant DELTxy parameter and
uses it directly in Engineering Unit delta rather than c onverting if
from % of span!
Regards,
Martin Theobald
Application Engineer
http://www.cytek.co.uk
Tom VandeWater wrote:
>
> 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: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
- References:
- Re: [foxboro] Change delta/peer-to-peer questions
- From: Johnson, Alex (Foxboro)
- Re: [foxboro] Change delta/peer-to-peer questions
- From: Tom VandeWater
Other related posts:
- » Re: [foxboro] Change delta/peer-to-peer questions
- » Re: [foxboro] Change delta/peer-to-peer questions
- » Re: [foxboro] Change delta/peer-to-peer questions
- » Re: [foxboro] Change delta/peer-to-peer questions
- » Re: [foxboro] Change delta/peer-to-peer questions
- Re: [foxboro] Change delta/peer-to-peer questions
- From: Johnson, Alex (Foxboro)
- Re: [foxboro] Change delta/peer-to-peer questions
- From: Tom VandeWater