PLC Large scale

Hi Guys,
I hope You're all fine ....

When you have to program a PLC to control a large amount of IOS (+200), You have to find a way to design your software prior into writing your code, So I have some questions about that :

- How to design and Layout the whole system ?
- Is there any approaches to design and organize your software (IOS Mapping, layout subroutines, Handling Faults and alarms, sequence control, and data flow between all of that)?
- What is the best PLC software architecture ?

The Problem appears with the relatively big systems with more IOS ...

200+ is not much for PLCs. You can use alias tags, or IO mapping. I prefer IO mapping. I can map then through filter AOIs, etc. I prefer splitting process sections into their own routines. if a IO point fails, its a single point of change. an alias you have to change every place it is in the program. Yes there is a very slight delay introduced through a mapping system. but its negligible for 95% of processes. You can also do both. mapping for the stuff that won't be bothered by the delay. Then you can alias/direct reference the stuff that needs the faster response.

Architecture? DO you mean PLC brand/manf. Clarify this for us.

ielkhatib said:

Hi Guys,
I hope You're all fine ....

When you have to program a PLC to control a large amount of IOS (+200), You have to find a way to design your software prior into writing your code, So I have some questions about that :

- How to design and Layout the whole system ?
- Is there any approaches to design and organize your software (IOS Mapping, layout subroutines, Handling Faults and alarms, sequence control, and data flow between all of that)?
- What is the best PLC software architecture ?

The Problem appears with the relatively big systems with more IOS ...

Click to expand...

The initial design for our mill was to use 1 massive PLC, with 30 racks (13 slot racks) of ControlLogix IO, with room to expand to 60 racks. It was all on a single controlnet. There was one gateway to the DeltaV.

This was not a flexible solution. Adding racks, mapping new data from other automation systems, etc required the whole mill to be down.

Design and layout:
The present organization is around the process - 2 different main product classes (Red and White) to start with, Loadout split into it's own PLC, the Steamplant and the Electrical Substation also in their own PLCs
Each PLC .. it was not designed this way .. sort of handles all of the equipment in an area. We don't have very many interlocks between PLCs. Most of the time the process has a tank or a bin that buffers product flow between
areas, so one PLC is in charge of filling the tank and the next PLC is in charge of pulling product out of the tank. That seems to work pretty well

Within each PLC we are quite simple. All of the code gets executed every scan. There are subroutines for each process area, and they are in order of asset number. Communications to the other PLCs is handled by separate subroutines.
Each PLC communicates to each of the other PLCs. And each ControlLogix communicates to a DeltaV controller using a VIM card.

The sequencing is done in SFC for the steps, but the step number drives actions in ladder logic (not ST within the SFC itself). If there is a lot of operational interaction with a sequence, it is done in the DeltaV.
If setpoints, bypasses, or pauses are not required, the sequences are handled by the PLCs

Our IO is now grouped by the MCC Room it is in, and the PLC that it connects to. We have cabinets within a specific MCC room that have Red IO, others that have White IO and Loadout IO. The racks and IO have to be well labelled
to avoid having new equipment terminated to the wrong locations.

We have many VFDs (about 1 in 5 motors are driven by VFD) so organizing their location, getting their communication and status straight, and allowing for size upgrades turned out to be a big issue for us. We have Devicenet
now and are moving to Ethernet. Ethernet is problematic since our IT guys are not on call. So any problems need to be repairable/be changed out by an electrician on site with assistance from a tech over the phone or on teams
Our VFDs are organized the same way as the rack IO (Red white, loadout, steamplant, etc), and in Motor Control Center sized groups.

I'm not sure I understand 'best PLC software architecture'. Can you give me an example?

Thanks for Answering My Question ...
By Software architecture you can see the attached pics

Questions to ask?
Is some process or task a high cpu intensive? Maybe plc split the tasks if so?
If your dividing tasks is there a place on your layout that the split will not cause a problem?
The local rack will usually have most of the specialty cards. Since some modules or need access to the plc processor due to comms limits on specialty cards. What considerations do these specialty cards require?
Power distribution of IO, look at if I kill an IO card does it only affect this area and not the whole area? Remote racks is there a limit in feet that you want an IO rack to cover? Say like 500 feet or what is that limit?
Or can you use remote IO IP67 blocks in field to capture this IO?
What type of network you using? Ethernet, profibus, Asi, ….etc Do you know the ends and outs of that arch? Is there some way to do an offline estimate of the network to see if the response is within what the process needs?
Estop zoning, what makes sense and what does the customer want?

Have you read or looked up ISA-88 or PackML? I believe it provides some indications on how to run this?

The other suggestion I would offer is for you to read up on DCS systems and how they're programmed as there's a lot of functionality there for coordination of devices (though usually for process industry, so if this is for packaging machines it may not be the best solution). Try finding manuals for PCS7 from Siemens or PlantPAX from Rockwell or DeltaV for Emerson, Hyperion and Foxboro. Perhaps that can give you some ideas?

I think standardization of software blocks for functions is what most people would say with regards to how it's laid out on the lower level. One thing that the typical DCS style systems also encourage (though some platforms are more flexible in this) is the use of tasks as an operating system would which is not how most people tackle PLC programming (particularly because it doesn't scale for a lot of machine). By understanding how fast the data is required, it is possible to stretch the processor a bit further in how it responds. It's pointless measuring a slow moving temperature every 100ms when if you do it every second it'll be more than sufficient.

look at your whole system.
are there and segments to the machine? by that i mean is there individual processes that you can separate into different stations?
if you can, that will help you with your i/o config in the plc.
remember to leave 20% spares every where. someone always forgets a detail or wants to add more.
james