List,
There are generally two rules of thumb that help making sequence code more
effective:
* put repeatedly used code in subroutines. This helps saving code space in one
program.
* try to modularize sequence applications into more programs running in a
coordinated fashion in parallel. This helps on two fronts:
A) a single SEQ block is always only executing code in a serial fashion, no
parallel execution, with several blocks things can be run in parallel - this
brings execution speed and can lower response times from operator actions.
B) the sequence code limit applies always per block. So, splitting an
application on several blocks often removes code size limits totally per block.
I've personally built larger sequence applications e.g. for driving a complex
industrial waste burning site between different operating states (e.g. with
different fuels that require different control philosophies when switched) and
the successful approach was to modularize the application and work with simple,
clear interfaces including handshaking between modules. Applications built like
that are also often much easier to troubleshoot as problems can be usually
localized quickly. For that I built a quick simulator that could establish
arbitrary commands to those interfaces and allowed easy testing of modules.
[sigh, that were fun times...] :-)
Hope that helps.
Liebe Grüße -
Marcel Rameil
Global Offer Manager Control Software
Product Marketing
Industry Business, Process Automation
Schneider Electric Systems Germany GmbH
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> On Behalf Of
Dirk Pauwels
Sent: Thursday, April 25, 2019 11:27 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] IND question
[External email: Use caution with links and attachments]
________________________________
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
https://eur02.safelinks.protection.outlook.com/?url=www.thecassandraproject.org%2Fdisclaimer.html&data=02%7C01%7CMarcel.Rameil%40se.com%7Cb3177b0ce3654489834a08d6c9604dbc%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C1%7C636917812799326452&sdata=6Yc7i%2Bh5vRoHHa3vQ5gWXfdKsrRHXHew7K0CBS4Kki0%3D&reserved=0
foxboro mailing list:
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freelists.org%2Flist%2Ffoxboro&data=02%7C01%7CMarcel.Rameil%40se.com%7Cb3177b0ce3654489834a08d6c9604dbc%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C1%7C636917812799326452&sdata=M%2B0GRkkarqeCQron%2BCdwnNy0g%2B76wA%2FIk52KBI58rIs%3D&reserved=0
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
_________________________________________________________________________
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
