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

Other related posts: