Re: [foxboro] STATE block
- From: "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 23 Mar 2009 18:27:50 -0400
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
Other related posts:
