Richard,=20 Sorry for the confusion. Yes, we are using the mapping function for the bulk of the control. We just have one little piece of logic that DMCplus can't handle that we are using IND blocks for. We think we found the solution. We were running the IND block with a PERIOD of 30 seconds. The block had a "WAIT 60" statement inside of a do-loop, which we thought would take precedence over the block scan period. When we set the PERIOD parameter to 0.5 seconds, the block behaved as we wanted it to with no latency. Apparently, IND blocks run only when their scan periods tell them to run, regardless of any do-loops and WAIT statements inside the code. I supposed we should have assumed that to be true, but for some reason we thought the do-loop inside the code took precedence. Another lesson learned. Thanks for the responses. Tim Lowell Control Systems Engineer ConocoPhillips Trainer Refinery (610) 364-8362 tim.c.lowell@xxxxxxxxxxxxxxxxxx -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Wetton, Richard J Sent: Wednesday, November 17, 2004 5:38 PM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] Setting Application Objects from IND blocks Tim, I can not explain the latency, but have you tried using the map file instead of the IND block's connectionless connection? I would normally try to use the aos mapping function in preference to the IND block, because the IND block connection creates broadcast messages on every read or write. The mapping function is looked after by foxapi and is far more reliable than an IND block. Richard Wetton..... -----Original Message----- From: Lowell, Tim: [mailto:Tim.C.Lowell@xxxxxxxxxxxxxxxxxx]=3D20 Sent: Thursday, 18 November 2004 5:44 AM To: foxboro@xxxxxxxxxxxxx Subject: [foxboro] Setting Application Objects from IND blocks We are working on a DMCplus application where we have to set the values of Application Objects, which were generated by DMCBridge, using an IND sequence block. We are noticing a great deal of latency, upwards of 1 or 2 minutes, between the time the IND sequence code runs and when the Application Object value gets set. Here is an example bit of IND HLBL code: =3D20 IF value1 > value2 :APP_OBJ_CMPND:APP_OBJ.PARAM :=3D3D value3; ENDIF =3D20 Is this fairly typical of IND sequence code performance? Is there something special about Application Objects vs. regular CP blocks that might cause this? Is there a setting somewhere that maybe we have left at the default that governs how fast AO's can be written to? =3D20 Any ideas would be appreciated. =3D20 Thanks, =3D20 Tim Lowell Control Systems Engineer ConocoPhillips Trainer Refinery (610) 364-8362 tim.c.lowell@xxxxxxxxxxxxxxxxxx =3D20 =3D20 =3D20 _______________________________________________________________________ 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 =3D20 foxboro mailing list: http://www.freelists.org/list/foxboro to subscribe: =3D mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin to unsubscribe: =3D mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave =3D20 =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: http://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: http://www.freelists.org/list/foxboro to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave