Rick,
Sounds clever enough :-)
I'll check it, but it certainly sounds/looks promising.
Tanks & Rgds,
Dirk
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of rick.mol@xxxxxxxxxxxxxxx
Sent: Thursday, April 25, 2019 3:26 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] IND question
****EXTERNAL EMAIL - Exercise caution, this email originated from outside of
the company. DO NOT reply to, open attachments or click links if the email
looks suspicious or is from an unknown sender.****
________________________________
Dirk,
I cooked this up a few years ago for a similar tank farm application. It uses
an array to determine valve desired statuses and compares those to the actual
valve state.
The code has been sanitized, but should give you an idea of what the design
thoughts were.
The operator selects the desired lineup and then sets the valves to match.
I used an overlay that looks at the strings (invis if na) and array output bits
to let them know what valves need to be set.
The actual code is fairly straightforward (I'm a simple guy at heart), it just
compares arrays and complains if not the same.
This was my workaround for the 16 bit problem. One of the sequences uses 24
valves.
Note there is a max limit for sequence code lines, forget what it is , but I've
run into it for other applications.
Sorry about the formatting. The file didn't copy well. It looks way nicer on
the system.
Hopefully this meets the clever requirement...
Regards,
Rick Mol
Coyote Technologies
Rick.Mol@xxxxxxxxxxxxxxx
************
INDEPENDENT_SEQUENCE
/*
Originator:
Company:
Location:
Purpose: Lineup control
Conventions: Preface B_ -block name. C_ -compound name. BP_ -block parameter
P_ -parameter. c_ -constant. a_ -array. v_ variable.
Usage: Checks lineup for movement. Verifies and monitors valve
position
and sets lineup specific pump usage using IO0004.
Calc block
uses bit level from the IO with an AND function to
determine hold.
Valve name and required state is defined for each
lineup number-set from
button on movement lineup overlay. If the lineup is
correct,a lineup
OK bit is set for the logic. The loop resets Lineup_OK
flag if a valve
is not in the correct state. STAIND is used 1-closed,
2-open to determine
valve state.
Revision History:
INITIALS DATE REVISION DESCRIPTION
-------- ---- --------------------
*/
{ Compound Names }
{Use for any specific instructions if needed}
#define C_Move C1
#define C_Equip E1
/* String Block Definition */
#define sName :LINEUP_NAME
#define sValve_1 :VALVE_S1
#define sValve_2 :VALVE_S2
CONSTANTS {****************************************}
cArraySize = 16; { Maximum number of devices in
lineup-define the size of the array here}
cOpen = 2; { used for compare array opened
valve,.STAIND = 2 }
cClosed = 1; { used for compare array closed
valve,.STAIND = 1 }
VARIABLES {****************************************}
Seq_Name : S12; { Block name for SBX usage }
RETRY_CNT : I; { SBX: INDIVIDUAL STATEMENT RETRY
COUNTER }
SAVED_STMNO : I; { SBX: STATEMENT OF DEATH }
i : I; { Temp integer for traversing array }
aValveDsr : I[16]; { Valve desired state .STAIND
1-closed 2-open }
aValveAct : I[16]; { Valve actual state .STAIND
1-closed 2-open }
aValveStateMatch : B[16]; { Valve status to graphic.IO0001 to
indicate lineup position }
aValveStateCompare : B[16]; { Array used for compare. Element is set to 1 if
used.}
aValveStateDsr : B[16]; { Array used for movement desired state graphic
display. 0-closed, 1-open }
aValveName : S[16]; { String array for valve names.Used
to allow traverse of for-next loop }
vValve : S;
vLineup : I; { Store lineup. Use for lineup
change test }
USER_LABELS {**************************************}
{ Standard block I/O }
RunOvr :BI0024; { Override TO_MANUAL SBX }
MESSAGE :SN0010; { SBX status message }
{ Specific block I/O }
Lineup_Check :BI0001; { Start checking lineup-from movement
sequence }
Lineup_OK :BO0001; { Lineup OK to run }
Lineup_Number :II0001; { Lineup number from graphic }
Lineup_Status :IO0001; { Lineup status to overlay }
Lineup_Desired :IO0002; { Lineup bool_desired state to overlay}
Lineup_Actual :IO0003; { Lineup bool actual state for compare}
Pump_Lineup :IO0004; { Pump lineup for start/stop logic }
Lineup_Used :IO0005; { Bit pattern for overlay element
visibility }
{ SUBROUTINES **************************************}
{STANDARD BLOCK EXCEPTION HANDLERS *****************}
Block exception log here:
/***************************************************************************
*/
STATEMENTS
$$INIT$$
Seq_Name := BLOCK_NAME;
{ Initialize valve strings }
:sValve_1.VALUE := "na";
:sValve_2.VALUE := "na";
Lineup_OK := FALSE;
Lineup_Status := 0;
Lineup_Desired := 0;
Lineup_Actual := 0;
{ initialize arrays }
aValveDsr := SET_ARRAY(0);
aValveAct := SET_ARRAY(0);
aValveStateMatch := SET_ARRAY(FALSE);
aValveStateCompare := SET_ARRAY(FALSE);
aValveStateDsr := SET_ARRAY(FALSE);
aValveName := SET_ARRAY("");
{ define the lineup selection from the graphic-1,2,4,8, etc.} WAIT UNTIL
Lineup_Number > 0
AND Lineup_Check;
IF (Lineup_Number = 1)
THEN
:sName.VALUE := "Lineup 1 Name";
:sValve_1.VALUE := " COMPOUND:XV0101"; { Valve 1 C:B tagname}
aValveDsr[1] := cOpen;
:sValve_2.VALUE := " COMPOUND:XV0102"; { Valve 2 C:B tagname}
aValveDsr[2] := cClosed;
ELSEIF (Lineup_Number = 2)
THEN
:sName.VALUE := "Lineup 2 Name";
:sValve_1.VALUE := "COMPOUND:XV0101";
aValveDsr[1] := cClosed;
:sValve_2.VALUE := " COMPOUND:XV0102";
aValveDsr[2] := cOpen;
ENDIF;
{ Set lineup status }
aValveName[1] := STRING :sValve_1.VALUE;
aValveName[2] := STRING :sValve_2.VALUE;
vLineup := Lineup_Number; { Use to test if lineup has
changed }
{ Here's the cool bit-the code basically compares the line and sets an OK bit
if lineup is good} WHILE TRUE DO;
{ determine valve state. Set array element TRUE if act and dsr match } FOR i :=
cArraySize DOWNTO 1 DO
IF aValveName[i] <> "na"
THEN
aValveStateCompare[i] := TRUE; { array element in use }
vValve := aValveName[i];
aValveAct[i] := (:'vValve'.STAIND);
aValveStateMatch[i] := aValveAct[i] = aValveDsr[i];
IF aValveDsr[i] = cOpen
THEN
aValveStateDsr[i] := TRUE;
ELSE
aValveStateDsr[i] := FALSE;
ENDIF;
ENDIF;
ENDFOR;
WAIT 0.1;
{ Output lineup status to graphic }
Lineup_Status := BIT_PATTERN(aValveStateMatch);
{ convert array to integer for comparison }
Lineup_Desired := BIT_PATTERN(aValveStateDsr);
Lineup_Actual := BIT_PATTERN(aValveStateMatch);
Pump_Lineup := BIT_PATTERN(aPump);
Lineup_Used := BIT_PATTERN(aValveStateCompare);
WAIT 0.1;
{ If lineup and field status match,set permissive } IF Lineup_Actual -
Lineup_Used = 0 THEN
Lineup_OK := TRUE;
ELSE
Lineup_OK := FALSE;
ENDIF;
IF Lineup_Number <> vLineup
OR NOT Lineup_Check
THEN
GOTO INIT;
ENDIF;
ENDWHILE;
ENDSEQUENCE
********************
*************
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> On Behalf Of
Dirk Pauwels
Sent: Thursday, April 25, 2019 4:27 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] IND question
Hi gents,
One of our older sequences handles an addition from 6 prod units to 6 storage
tanks, any unit can go to any of the tanks, so 36 possibilities.
Also there are 48 valves involved for which we also check the status (64
states) and compare it to the desired status. (yes I know, ridiculous, but
we're a batch plant and someone tried to stuff as much units and tanks on a
small surface as possible using a "spaghetti" layout and a lot of tie in's in
the headers.... :)) I have a valve matrix for this addition and it's about 24"
x24" wide and long.... :) This sequence uses a lot of external references and
a lot of WAIT UNTIL statements. It works, but uses a lot of lines and it takes
some time to go through the code because of the WAIT UNTIL statements.
Also it's not the preferred way off course.
For other sequences I often use MCOUT's containing valve states and PATT's
containing the selection masks, but that won't work in this case. Too much
valve states (64).
I'm looking for a clever way to clean up the sequence, shorten it, speed it up
without using tons of extra blocks.
It's a pity MCOUT and PATT only have 16 inputs.... :)
Thanks for sharing your ideas....
Rgds,
Dirk
________________________________
Lawter Notice: The information (including any attachments) contained in this
communication is confidential, private and proprietary, may be privileged or
otherwise protected by applicable law or legal rule, and is intended only for
the use of the addressee(s). Unauthorized use, disclosure, distribution or
copying is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately by reply e-mail,
or by calling the sender, and then delete it completely from your system.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
________________________________
Lawter Notice: The information (including any attachments) contained in this
communication is confidential, private and proprietary, may be privileged or
otherwise protected by applicable law or legal rule, and is intended only for
the use of the addressee(s). Unauthorized use, disclosure, distribution or
copying is strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately by reply e-mail,
or by calling the sender, and then delete it completely from your system.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
