30 Tanks; Most Efficient Progamming CLX

[plcsavage]

Hello All,

I’m working on a project that requires filling/discharging from 30 batch tanks that are the exact same. Simplifying things some here but each tank will have an inlet valve, an outlet valve, and a cooling jacket valve (all 3 valves have open and closed feedback). Only 1 tank can be filling at a time and only 1 tank can be discharging at a time. At no point will the same tank be filling and discharging. Each tanks' valves are named very similar where they follow the format XV-1XXA where XX represents the tank number and A represents the valve function. I’m looking for some pointers in how to write my logic the best way (possibly utilizing indirect addressing) so as to eliminate the amount of rewriting/troubleshooting/organizing onsite. I have the availability to use a 1756-L8X PLC and will be utilizing pre-developed AOIs.

I was thinking of making a UDT with length of 31 (30 tanks so will use [1]-[30]) and under that UDT also have a UDT for all the valve I/O on each tank so when we set the active batch tank, we can use indirect addressing in the UDT to open the proper tank’s valves and check the open/closed inputs. But this requires me to map all the valves inputs into the UDT which will be very time consuming. I’ve done quite a bit of research on this site and have seem some good threads but most seem to focus on PLC5/SLC and not CLX. Is there a better way than the above to do this for CLX? I would like to make things as clear and concise as possible without copy and paste 30 times.

 

[Paullys50]

I think your approach is wrong. You are more concerned about 'efficiency' than functionality and code readability. You didn't talk about the cooling control logic required either.

Valves at minimum should have Hand-Off-Auto control and position feedback checks to generate alarms.

I would also suggest additional functionally:
- Adjustable Alarm setpoints
- Ability to configure for N.O. or N.C.
- Simulation for testing when you don't have physical IO

This should all be wrapped up in a Valve AOI. Each should have a called instance of the AOI ---> Clearer than calling a subroutine and using indirects on a signal AOI.

You have 2 equipment module functions:
1. Fill/Empty, shared across all 30 tanks. You need 2 function selections, one for choosing if you are filling or emptying, the second for tank selection. What about a pump? Where are you pumping from/to?
2. Cooling control, an instance for each tank I would assume. You didn't mention a TT at each tank for cooling control, but I would believe you need one.

You didn't mention fault monitoring during a fill/empty and the impact of a failed open/closed feedback of a valve. What about cooling valve faults?

You also didn't mention how the filling/emptying process will start/stop. Is it operator initiated from an HMI or is there additional batch logic that will automatically do what is required?

What do the pre-developed AOIs do for you?

I think you need to focus on all the functionality you require before getting wrapped up in creating minimal functionality with minimal code.

 

[parky]

As they are all the same functionality, I suggest you create a function for the control of a tank, parameterise this with the tank controls, once tested then just copy & paste changing the inputs/outputs to the relevant tanks, I suggest you keep away from too much indirect addressing as it can be difficult for others to fault find (however, if that is intentional just be aware you will be the one having callouts if there are problems).
As already posted, write down the process sequence for one tank take into consideration alarms how you prioritise the tanks I assume that filling/discharging will be only one at a time however, the cooling could be in parallel i.e. maybe one tank filling, one discharging & others cooling so bear that in mind for interlocks regarding priority.

 

[cardosocea]

ACM and the tag export/import?

Are those AOI's PlantPAX by any chance?

Doesn't Excel allow you to create logic for mapping fairly easily? Failing that ST is easy enough to read as a map... you can even make a nice comment at the top of the subroutine explaining how the := sign works.

 

[Saffa]

Firstly, not a huge Rockwell guy ... but, this should work the same regardless of platform. I'm a Schneider guy.

Create AOI (DFB in Schneider-land) for each tank. I'm not a fan of nested AOIs, but each to their own... yours sounds simple enough to just have everything in one AOI, i.e. no need to have nested valve AOIs within each Tank one. You could however have a UDT for each valve, and pass those in and out, to keep the number of individual tags down.

Each tank AOI instance is given a "hard baked" tank number as an input. It is also given an input for "current fill tank number" and "current drain tank number". All AOI instances use the same two tags. If these input tags match the hard baked tank number input, then the AOI logic executes the drain or fill cycle. If both drain and fill tags match the hard baked tank number the AOI should provide a fault output and go to whatever is the safe state(drain & fill closed?)

A seperate routine, acting as an Arbiter, writes to the current fill tank number and current drain tank tag number based on whatever rules or operator input selects the tanks.

 

[Corsair]

Generalities

Here's a general statement that you may choose to ignore.

Sometimes there can be so much complication to code to avoid copy and paste multiple times that it causes problems. This is especially true when the customer told you that ## items are 'identical' and later you find out later that they aren't.

Remember that the copying and pasting only occurs one time but the figuring it outs go on for the life of the system.

- - -

I'm trying to keep a sense of balance here - it seems like I've seen a lot of posts on this forum where the biggest concern seems to be avoiding keystrokes. I use AOIs (DFBs) all the time but I try to not overcomplicate them just to avoid keystrokes.

 

[plcsavage]

Thanks for all the replies and ideas. So when it comes to each tank, I was understating things as there are more like 20 devices (3-4 TT, agitator, 10-12 valves, LSH, TCV) so not quite that simple (there are also SIPs & CIPs that need to be done for each tank). Our custom AOIs have all the built in functionality that Paullys mentioned but are not PlantPax. To extrapolate more on the process:

*Each tank is filled with product from an upstream process/pump, all I have to do is know which tank the product is going to and set/check the correct valve path
*The tank filling process is initiated manually now but will eventually use a queue type system with a FIFO and it will be automatic as the operators become more familiar/comfortable with the system
*The cooling system will need to be active during the entire time the product sits in the tank (4-5 days)
*When the tank is ready to discharge, it is also initiated manually by the operator now but will use a similar FIFO/queue as above later on
*There is a main tank discharge header with a pump that pumps the product from each batch tank into a much larger holding tank, as that tank gets lower, another batch tank is pumped over to fill it back up
*In between tank batches, each tank must either be SIP or CIP, which is initiated manually now but will eventually happen automatically in the future

My main concern with copy and paste is that the customer has not clearly defined everything that they want and we know there will be additional features/alarms/things they will want and we will need to add once onsite for commissioning. My idea to use indirect addressing was just a way to help combat the time needed to troubleshoot onsite and to help lower the time needed to implement these additional features.
I do like your ideas of using AOIs or some type of parameterized control modules but everything needs to be fairly flexible. We will not have the opportunity to modify AOIs/do additional downloads once onsite.

I’m somewhat leaning more towards the copy and paste now but it just seems like such a bear as I know they will want to add more features and we will not have the opportunity to get one tank to 100% due to the holding time requirements for each tank (product sits in tank for several days so it’s not a very repeatable process).

 

[parky]

I don't think it's a major problem, if there are doubts about slight differences then create a standard block but instead of a call to that one block, use separate instances (Not done much CLX over the last 10 years assuming it does meet IEC specs), that way if there are differences it would be easy to copy the code as a separate function & modify just that one & use it.
As for the time, using simulator you could just speed up the process i.e. instead of days could be minutes, this way it's easy to iron out most of the wrinkles.