Re: [foxboro] Change delta/peer-to-peer questions

Re: DELTOy

This beast is used indirectly (through ROy) on faceplates. I suspect it is
used elsewhere as well.


Re: Delta usage documentation

Not that I know of, but I'm adding it to my book. Now, if I could ever
finish and publish that beast.


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:   Tom VandeWater [SMTP:tom@xxxxxxxxxxxxxx]
        Sent:   Wednesday, June 12, 2002 7:31 AM
        To:     foxboro@xxxxxxxxxxxxx
        Subject:        Re: [foxboro] Change delta/peer-to-peer questions


            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
        >
        >
        >
        >
_______________________________________________________________________
        > 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
         
 
 
_______________________________________________________________________
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

Other related posts: