Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0

Re: Actually sampling theory, ie. Nyquist, says that you should sample at
least twice as fast as the fastest frequency that is present in the data.


I knew when I wrote that I should have said that this is an approximation of
the theory. I actually wrote that, but decided that it was distracting.
Sigh...


It is hard to know how much detail to provide sometimes.


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:   AWeldon@xxxxxxxxxxxxxxxx [SMTP:AWeldon@xxxxxxxxxxxxxxxx]
        Sent:   Wednesday, December 11, 2002 9:30 AM
        To:     foxboro@xxxxxxxxxxxxx
        Subject:        Re: [foxboro] FOXAPI  Configuration for Foxhistory
Ver 2.0


        Actually sampling theory, ie. Nyquist, says that you should sample
at least
        twice as fast as the fastest frequency that is present in the data.
Doing
        otherwise opens you up to the possiblity of aliasing.  Care should
be used
        when using sampled data for troubleshooting unless you are sure that
the
        proper anti-aliasing has been done of the front end.

        Alan D. Weldon
        Sr. Process Control Engineer
        Hunt Refining Company



        -----Original Message-----
        From: Johnson, Alex (Foxboro) [mailto:ajohnson@xxxxxxxxxxx]
        Sent: Wednesday, December 11, 2002 8:48 AM
        To: foxboro@xxxxxxxxxxxxx
        Subject: Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0



        The fastest_rsr value controls the period that is used by the OM in
the
        remote station. The period controls how often the OM checks a list
for
        changes. So, a 10s fastest_rsr will cause the CP to report changes
on the
        list once every 10 seconds.


        The historian will record the value it receives based on the
recording
        period of the point.


        Sampling theory says that you want to sample your data at least
twice as
        often as you want to record it.


        If FoxHistory is recording data at 30s intervals a 10s fastest_rsr
is
        appropriate. If you have FoxHistory configured to record values
every 0.5s,
        obviously a 10s fastest_rsr is in appropriate.


        If you are really interested in recording spikes that last 2 seconds
you
        would need to configure FoxHistory for 1 and should set the
fastest_rsr to
        0.5. (A case could be made for 2s in FoxHistory and 1.0 as
fastest_rsr; it
        sort of depends on how important the problem is.)



        Also, please note, that the fastest_rsr setting applies to all
FoxAPI using
        applications on the machine, e.g., APC packages and PI.


        You can also tune your change deltas so that insignificant changes
are not
        reported.




        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:   F.Foxreseng@xxxxxxxxxxxxxxxx
        [SMTP:F.Foxreseng@xxxxxxxxxxxxxxxx]
                Sent:   Tuesday, December 10, 2002 10:53 PM
                To:     foxboro@xxxxxxxxxxxxx
                Subject:        [foxboro] FOXAPI  Configuration for
Foxhistory Ver
        2.0


                Dear All

                We have IA series 4.3 System having three nodes.
                The nodebus traffic of two nodes are very high (800
Packets/Sec).
                We have Foxhistory  Ver 2.0 having around 4000 points
configured on
        each
                node.
                Now during analysis of nodebus traffic, I found that
foxhistory is
        major
                contributor.

                I checked FOXAPI configuration as Foxapi is used by
Foxhistory to
        get real
                time data.(What I understand).
                I found that in foxapi.cfg file ,fastest_rsr (read scan
rate) is not
                configured so foxapi is reading all the points at 0.5 Sec
regardless
        of
                foxhistory configuration.

                One more point ,In foxhistory all points have fast freq=20
Sec and
        Read
                delta as per process requirement.

                Now suppose I put fastest_rsr = 20 (10 Sec) ,Now FoxAPI
update table
        at
                every 10 Sec for foxhistory points ,

                *       Will it affect foxhistory data collection ?
                *       suppose one point change it's value more than define
read
        delta in 2
                Sec, will get updated in foxhistory ?
                *       what other thing I have to do ?

                Because above exercise help me to reduce node bus traffic .

                If somebody know other way to reduce traffic,Please also
suggest.

                Regards
                Foxboro System Engineer
                SASREF


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