Alex, I believe that Sylvain Nadeau has a package that looks after=20 grouping your FoxAPI lists on a station basis so that the Object Manager is optimized, yet the comms is throttled=20 so that you do not bog down the node. Terry -----Message d'origine----- De=A0: foxboro-bounce@xxxxxxxxxxxxx = [mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de Johnson, Alex P = (IPS) Envoy=E9=A0: March 24, 2006 12:06 PM =C0=A0: foxboro@xxxxxxxxxxxxx Objet=A0: Re: [foxboro] Foxapi question Re: Someone just mentioned that with Foxapi 4.3.1 these issues go away = and we don't need to worry about how we group tags. Is this true? I am not aware of any changes in FoxAPI V4.3.1 that would change it = behavior in this regard. For sometime, FoxAPI has had an option to optimize lists by CP, but = there is a trade-off when that feature is used. To do the optimization, the OM = list is built tag by tag. This results in quite a bit of traffic while the = lists are being built up. In many cases, so much traffic is generated during = the creation of the lists that system performance is degraded. I had to fly to a refinery in France to track down this issue. As a = result of that trip an option was added to disable the feature (nocsaonread). I believe that the feature was added in FoxAPI V4.2.something with the nocsaonread being added in the next minor release (V4.2.something+1) release. Re: CIMIO settings There were other changes made later that can have a negative impact on CIMIO, PI API, and other applications. In one release or another, we = changed the status value that is returned when a tag does not connect. The = change was for the better, but did cause programs that were not written for the change to have issues. These changes were made in V4.2.6. I believe the two of interest should be set as follows in /usr/fox/ais/bin/foxapi.cfg: ia_badstat=3D0 skip_omread=3D0 I believe that ia_badstat=3D1 caused CIMIO a little heartburn and so it = should be set to 0. The skip_omread option is probably less important. A third option was added at that time (protect_index), but I'd leave it = at the default. These options can be found in the FoxAPI User's manual - B0193UD Rev D = or later. Hope this helps. Regards, =20 Alex Johnson Invensys Systems, Inc. 10900 Equity Drive Houston, TX 77041 713.329.8472 (voice) 713.329.1700 (fax) 713.329.1600 (switchboard) alex.johnson@xxxxxxxxxxxxxxxx -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] = On Behalf Of Neil Martin Sent: Friday, March 24, 2006 10:39 AM To: foxboro@xxxxxxxxxxxxx Subject: [foxboro] Foxapi question Alex, In the past to maintain efficiency on the DCS, we have needed to pay attention to how we group ASPEN IP 21 or PI tags in lists - i.e. group = the lists by CPs/Gateways. In fact before my time here at this plant, the ASPEN configuration was not handled properly and they greatly loaded = down the DCS system. Someone just mentioned that with Foxapi 4.3.1 these = issues go away and we don't need to worry about how we group tags. Is this = true? On another note, concerning the interface of Aspen IP 21 to Foxboro DCS, are there any recommended DCS/Foxapi settings or other guidelines that = we should be aware of for DCS performance efficiency? We currently use = V6.5.X and V7.1 AW51s for interface to IP21 and also for DMC Bridge. Neil Martin, P.E. Huntsman Polymers Corporation 2505 South Grandview Odessa, TX. 79766 ph) 432-640-8436 pager)432-742-4289 email page)4327424289@xxxxxxxxxxxxx =20 =20 _______________________________________________________________________ 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 =20 foxboro mailing list: //www.freelists.org/list/foxboro to subscribe: = mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin to unsubscribe: = mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave =20 =20 =20 _______________________________________________________________________ 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 =20 foxboro mailing list: //www.freelists.org/list/foxboro to subscribe: = mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin to unsubscribe: = mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave =20 _______________________________________________________________________ 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