Thanks Alex, Might have been related to a phone call I had with Winston yesterday on this subject. We have him here in Foxboro today. Useful to know that AIM*API can write to "valstat" although I'm sure that I have to write to an unsecured block input. In which case I'd have to toggle the IOMOPT. Still quite workable. I did however try a few things with setpars. Cannot change IOM_ID as it is a "string". But I did try to set the PERIOD=13 (50ms scan) and it would have worked except my compound was at PERIOD=0 (100ms). setpars made the change to a CIN block, but the block took it without complaint. I was expecting INVALID PERIOD/PHASE. The BPC is 100ms, but it happily allowed a CIN block that thought is was at 50ms. So I set PERIOD=100 and the CIN block finally went OOS. Not sure what the scan time of 100 will be if Invensys ever gets there, but let us just assume 1 pico-second. Thanks, Rick Rys On Thu, July 19, 2012 1:18 pm, Johnson, Alex P (IOM) wrote: > I got a similar question from Winston Jenks. > > If you want to write a program using AIM*API (not too hard) that program > can set the bits on the status word of the target parameter, e.g., MEAS. > The bits are: > > BAD > OOS > ACK > > There are two calls: > an_write_valstat - for write (buffered) lists > am_write_value_status - for one-shot (unbuffered) values > > The manual is B0193YN. > > From the banks of the Guadelouple River and NOT on-line. :) > > > Regards, > > Alex Johnson > Invensys Operations Management > 10900 Equity Drive > Houston, TX 77041 > +1 713 329 8472 (desk) > +1 713 329 1600 (operator) > +1 713 329 1700 (Central Fax) > alex.johnson@xxxxxxxxxxxx > > > -----Original Message----- > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] > On Behalf Of rys > Sent: Wednesday, July 18, 2012 7:00 AM > To: foxboro > Subject: [foxboro] Testing with..BODE > > > Dear esteemed list, > > The applications that have been developed > on my projects are often using logic based on ..BODE to determine signal > quality. We have logic like toggling to a fallback value or setting > the output of a calculation to BAD. As these are bits in the value > parameter record they are not easily settable. Only CALC(A)/LOGIC > blocks can set these directly. In the past we wrote iccdrvr scripts > to: > *Toggle IOMOPT to simulation mode, > *Connect .IN (CIN) or .MEAS (AIN) to a single > test CALCA block > *Build the CALCA block to allow > BI's to set ..B, ..O, and ..E in BO01 and RO01. No one I know has > ever figured out how to set ..D. > *Build test > displays > *Test the logic > > *Reload the CP with the original SaveAll or maybe run an undo script. > > What I want is a simpler method to do this for 1 IO block at a > time. I only need to make ..BODE go TRUE (BAD) so setting any one of > these can work. As we are testing with a cabinet that has all the > FBM's wired up and operational. I was thinking that maybe I could > build a FoxView display where the user types in a C:B and clicks a > button. The button launches a script that uses "getpars" > to obtain the IOM_ID of that C:B. It then uses "setpars" > to write a new non-existent IOM_ID. The resulting block then goes to > OOS, I.e. sets the ..O bit. Now I check the logic works > correctly. A second button puts back the original IOM_ID to return > the C:B to the good state. > > Has anyone ever built something like > this? > > Rick Rys > > > > > > _______________________________________________________________________ > 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 > > > > *** Confidentiality Notice: This e-mail, including any associated or > attached files, is intended solely for the individual or entity to which > it is addressed. This e-mail is confidential and may well also be legally > privileged. If you have received it in error, you are on notice of its > status. Please notify the sender immediately by reply e-mail and then > delete this message from your system. Please do not copy it or use it for > any purposes, or disclose its contents to any other person. This email > comes from a division of the Invensys Group, owned by Invensys plc, which > is a company registered in England and Wales with its registered office at > 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number > 166023). For a list of European legal entities within the Invensys Group, > please go to http://www.invensys.com/en/legal/default.aspx. > > You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail > reception@xxxxxxxxxxxxx This e-mail and any attachments thereto may be > subject to the terms of any agreements between Invensys (and/or its > subsidiaries and affiliates) and the recipient (and/or its subsidiaries > and affiliates). > > > > > _______________________________________________________________________ > 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