Re: [foxboro] system error in sequences
- From: dirk.pauwels@xxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 30 Aug 2010 17:14:14 +0200
Hi Jerry,
I've been changing some sequence code today, building user labels where
possible and using new "local" blocks, connected to the off station CP
and declared as variables in case I've used up all the user labels. I'm
also paying attention to the wait's, we have quite a few seq's which can
do with some extra "wait's"
I still have to check a lot of sequences, for most of them we use define
files (each unit has it's define file), so we can work with include
sequence files, rather than having to write the code for each unit.
Unfortunately a #define is nothing but an "alias", the code interpretes
this as a C:B (network call)....So I'll probalby use the defines to create
variables instead of using the define names in the code directly (except
for ain's, cause i need updated values for this, so when possible I'll use
labels here)
So I'll be seeing a lot of HLBL for the next weeks ;-)
We've had to build in "wait" statements also after we changed from CP60's
to CP270's. Steps that executed fine before the upgrade were skipped after
the CP upgrade, I now use plenty of wait's in the newer stuff.
Many thanks to everone who contributed for the good advice
Rgds,
Dirk
Jerry Hidahl <Jerry_Hidahl@xxxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
30/08/2010 15:49
Please respond to
foxboro@xxxxxxxxxxxxx
To
foxboro@xxxxxxxxxxxxx
cc
Subject
Re: [foxboro] system error in sequences
Dirk,
The next best thing to connecting your off-station references to a
parameter in your sequence block is to use a parameter in a different
block
in the same compound. The next best thing after that is a parameter in a
different compound, but in the same station. It could be another sequence
block or a calc-type block.
The key factor is when the value is updated within the station where your
block is running. Connections are updated every time before a block is
executed, but C:P.B references to different stations are only updated when
a line of code is executed. Whenever an off station reference occurs, the
code execution is suspended until the answer returns. If a reference is in
the same station, the value is just fetched or stored to a memory
location,
and the code drives on.
When we upgraded our kettles last year to FCP270s and consolidated some
CPs
we had to add a WAIT statement for a sequence to work correctly.
Previously, a key handshake reference was in a different CP, so the
execution always suspended. After we consolidated, the handshake stopped
working until we forced the sequence to wait.
Adding connections to off station parameters won't always be the best
solution. You have to weigh the cost of the added overhead of updating
connections every scan, versus slowing the HLBL execution down with C:P.B
references.
Jerry Hidahl
Process Control Engineer
Port Neches Performance Products
Huntsman Corporation
In reference to:
Hi Chuck,
Thanks for the advice, For these (small) sequences I already changed the
code using user labels, but I have many sequences where there are too many
C:B.P references to use user labels, I'll go through the sequences and
change the network calls using variables where needed.
Rgds,
Dirk
_______________________________________________________________________
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
Other related posts:
