Alex - Thank you for the detailed response. I am very familiar with B0193AX and the parameter tables. I will tape a printout of your e-mail inside the front cover of my copy and then I will be able to consider this behavior as properly documented. :) >[Note: It doesn't have to be complicated. A <source options>/<sink >options> nomenclature would have used less space and been more accurate. >For example: >g-/s- would mean gettable, settable without connected reads or writes. >gr/s- would mean gettable, settable, connected reads, no connected >writes. >Simple and elegant.] Yes, this would have been very nice. But I'm not complaining too loudly since B0193AX in general is a very good document and usually answers all of my questions. Sean Redmond has proposed a workaround for a single button that will toggle the bit and force a display refresh; if I can get this to work it should be fine for my application. These are not parameters that are going to be changed very frequently, so it's OK if the solution is a little clunky. I'll let everyone know how it turns out. Greg Hurwitt "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx> Sent by: foxboro-bounce@xxxxxxxxxxxxx 03/23/2009 05:27 PM Please respond to foxboro@xxxxxxxxxxxxx To <foxboro@xxxxxxxxxxxxx> cc Subject Re: [foxboro] STATE block Greg, B0193AX - The control blocks book - contains a Block Parameters table for every block type. One column of that table is 'Accessibility.' The options for accessibility are: 1) Available for one-shot get 2) Available for one-shot set 3) Available for connected reads 4) Available for connected writes They are shown as: <connected access>/<one-shot access>. The <connected access> field may read: con or no-con. The <one-shot access> field may read: set or no-set. I can hear you asking, "Why don't I see get/no-get on that list and why don't con/no-con reflect the type of access (read or write) being used?" That's a very astute question. The answer gets complicated. To save space, the tech writers made some abbreviations that differ depending on the section of the table. [Note: It doesn't have to be complicated. A <source options>/<sink options> nomenclature would have used less space and been more accurate. For example: g-/s- would mean gettable, settable without connected reads or writes. gr/s- would mean gettable, settable, connected reads, no connected writes. Simple and elegant.] In the INPUTS section of the table, all of these access options are possible and one-shot get is always true for every parameter. Thus, you could see things like this: A) con/set - connectable for read and write and gettable and settable B) con/no-set - connectable for read and write and gettable, but not settable C) no-con/set - not connectable for read or write and gettable and settable D) no-con/no-set - not connectable for read or write and gettable, but not settable I can't think of an example of B - it's a possible combination, but not a rational one for an INPUT. Why would you want only a connected write and not a set? I can't think of an example of D - it's a possible combination, but useless for an INPUT. You couldn't change the parameter. So, A and C are the ones you find. In the DATA STORES location, the block owns the value and it can't be changed; it's a read-only parameter. So, even though it says "con", you are expected to understand that "con" here means for read access. They all show no-set though. In this section, it's "con" or "no-con" and always "no-set" with the implied limitation of no connections for writes. (Yes, I know about LOCKRQ and OWNER being "set", but those are really INPUTs. They are listed here because the block doesn't actually use them; hey are for the user's applications. I think they are improperly grouped.) In the OUTPUTS section of the table like the DATA STORES section, connected writes are never available since the list would fight the block for permission to write to the value. Therefore, these parameters are implicitly no-con for write. They might be settable (in certain modes) though, like PNT or OUT. In this section, it's "con" or "no-con" with connectable for write never being an option. Settable can be an option in certain modes, e.g., Manual mode allows sets to the primary output of the block. Now, for your example. Here's what the table says about the STATxx parameters: Name : STAT01 to STAT16 Description : states 1 to 16 patts Type : pack_b Accessibility: no-con/set Default : 0x0000 Units/Range : 0x0000 to 0xFFFF Since this is an INPUT, you can see that the table is telling you that these are not connectable for read (or write) (no-con). Since FV uses connected reads for values on the display, this one will not update. Your next question is going to be, "Why?" That's easy, the CP10 didn't have enough RAM to provide an OM value record (something required for change driven access) for each parameter. Though newer controllers have more RAM, we haven't gone through and changed the code to enable "con" on all parameters. There are a variety of reasons ranging from back compatibility (same parameter should have the same behavior on all systems) to cost/value of the change I know that this does not solve your problem, but at least you should understand the behavior after reading this and know that it is documented (if you know how to read the document). BTW, "no-con" applies to any read list - FV feads, Historian feeds, peer-to-peer, inter-block, etc. As for workarounds, FoxView doesn't poll. There's a kind of polling mechanism for string parameters, but not for non-string ones. The only workaround that I know is a gross one of using a Sequence block to read and copy the parameter. Regards, Alex Johnson Invensys Process Systems 10900 Equity Drive Houston, TX 77041 713 329 8472 (desk) 713 329 1600 (operator) 713 329 1944 (SSC Fax) 713 329 1700 (Central Fax) alex.johnson@xxxxxxxxxxxxxxxx -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory A Hurwitt Sent: Monday, March 23, 2009 4:41 PM To: foxboro@xxxxxxxxxxxxx Subject: [foxboro] STATE block (I/A Version 8.2, Foxdraw Version 10.0.2) I am developing a small application that will be using a STATE block. There will be a graphic that allows the Operations Engineer to change bits in the STATxx (state pattern) parameters. Unfortunately, when reading these parameters back to the graphic, the displayed bits do not update unless the graphic is reloaded. I imagine many of you have not worked with STATE blocks, however, you may have seen the identical behavior with the Mxx (memory) parameters of a CALCA block. The displayed information does not update when the value changes; when the display is reloaded then the current value is displayed properly. For both the STATE.STATxx and CALCA.Mxx parameters, this behavior is observed on both user-generated graphics and the default block detail display These are parameters that in many applications might not be updating frequently (as opposed to say the .PNT of an AIN block), so I can kind of see why they behave differently from other parameters. But I've never seen anything in the documentation that labels these somehow as "static" parameters not subject to display updates. Have I missed something in the docs? More importantly, is there a way to configure my FoxDraw graphic to force the display of these parameters to update on change or on say an every-5-second basis? Greg Hurwitt E-Mail: gregory.hurwitt@xxxxxxxx BASF Corporation Freeport, TX 77541 _______________________________________________________________________ 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 is from the Invensys Process Systems business unit of the Invensys Group, a group of companies owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77 . You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpdesk@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