Re: [foxboro] OM scan load
- From: Terry Doucet <doucet427@xxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 12 Jul 2012 12:00:44 -0400
Alex has noted a number of items for you to check. The om tools are covered
(perhaps a bit thinly) in B0193JB. Check EDOC for a later version. The most
useful tool is rsom.
The application may be the user that kicks you over the limit. Check to see
what scan (update) time it is demanding from the CP's. If it is zero or 1/2
second, that is normally too fast in the process world. We used to try for 10
seconds or slower. Check the CP station display and the OM overview which
shows the OM load per BPC. If it is spiking rather than balanced, perhaps
there is some change you can make that will result in a more balanced load.
As Alex suggested, reboot stations that receive data from your CP's if you can.
The easiest are usually WP's, then AW's but the toughest and maybe not
possible are the CP's as both sides of FT have to be rebooted together so you
lose control and view of the process for the reboot time. Then peer connections
(between) CP's need to remake.
Terry
> From: dmancl@xxxxxxxxxxxxxxxxxxxxx
> To: foxboro@xxxxxxxxxxxxx
> Date: Thu, 12 Jul 2012 09:12:22 -0500
> Subject: Re: [foxboro] OM scan load
>
> The historian has been restarted. I did not notice any significant drop in
> OM scan load with the historian stopped. There is a third party application
> that pulls information via OPC. When that application is stopped their is a
> drop in OM scan load. That application has been in place for sometime
> without any changes. They have 5 stations displaying data from the CPs.
> Unfortunately I am not familiar with the OM tools. One of the FCPs I didn't
> make any changes on and the OM scan load has still been going up. Total
> connections , tlcons is 0.
> Sent from my Verizon Wireless Droid
> -----Original message-----
> From: Terry Doucet <doucet427@xxxxxxxxxxx>
> To: foxboro@xxxxxxxxxxxxx
> Sent: Thu, Jul 12, 2012 13:55:21 GMT+00:00
> Subject: Re: [foxboro] OM scan load
>
> I hope this is not a silly question but did you stop and restart the
> historian? Scan changes are only made on restart.
> When you stop the historian does the OM load go down?
> Is there any other application running? Can you turn it off briefly and see
> if the OM load on the CP's goes down?
> Howmany WP's are displaying data from the CP's? Can you place them all on
> their Initial_Display, even briefly and check the OM load to see if it goes
> down? Also check the Station display to see if the number of OM connections
> goes down. If you know how to use the OM tools, they could help evaluate to
> see if some "old" connections are hanging around when they should be
> deleted. With all WP's on Initial Display, you should not see the WP
> letterbugs in the list from the OM tools.
> Terry
>
> > From: dmancl@xxxxxxxxxxxxxxxxxxxxx
> > To: foxboro@xxxxxxxxxxxxx
> > Date: Thu, 12 Jul 2012 08:00:57 -0500
> > Subject: [foxboro] OM scan load
> >
> > Hoping someone one the list can help.
> > I have several FCP270s that are showing a high OM scan load %. I recently
>
> > went in and changed the history scan rate on multiple items from 1000 ms
> to
> > 5000 ms thinking that may help but the OM scan load only went up. Now the
>
> > data collector will lose communications with just one FCP and will not
> > re-establish communications until it is rebooted.
> >
> > Any help is greatly appreciated.
> >
> > Dominic Mancl
> >
> > Sent from my Verizon Wireless Droid
> >
> >
> >
> >
> >
> > _______________________________________________________________________
> > 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
>
_______________________________________________________________________
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:
