Mutliple Processors in One Project

What are others experience with combining multiple machine processors into one project?
In my case this is for TIA Portal V16, but I guess the principle applies for any package that allows it.

TLDR: What are the watch outs for multiple machine CPU's in one project, would you prefer each of your CPU's to have their own project or are you happy with some grouped together in to one project file.

Background: Traditionally we have kept separate projects for each machine and use network connections with defined telegrams to communicate with the common services (cooling systems, etc) that serve multiple machines.
Now we are modifying two essentially identical machines to each have much closer integration with one of its support services/machines. Our systems integrator has suggested merging all three of these projects into one TIA Portal project as it will make the engineering and commissioning much easier and faster.
I am OK with that, but I am unsure if I should unmerge the projects afterwards.
Advantages of one project are it will be easier to keep both machines identical, easy to keep a common library of function blocks, Scada screens, etc.
Disadvantages are the project file will be much larger. I have concerns around engineers accidentally modifying the wrong machine. Keeping one project current may be difficult as often we have different concurrent work being developed for both machines at the same time.

I know these problems should be manageable with better process and discipline, perhaps better password protection on CPU downloads and by utilising Multiuser Engineering, but I'd like some other real-world opinions.

Thanks!
Phill

With regards to multiple PLCs in a single project, I'm working with a project that has at least 6 PLCs, and 5 HMIs in the same project. Yes, the concurrent work is a disadvantage, but I found a way around it.

There is a feature called "reference project", which you can open to do comparisons of PLCs from different projects, and you can do a side-by-side comparison of PLCs, and even execute an overwrite of any data that is different (tags, program blocks, etc.)


See below: How do you compare between two projects and between project and library in TIA Portal?

https://support.industry.siemens.com/cs/document/81748055/how-do-you-compare-between-two-projects-and-between-project-and-library-in-tia-portal-?dti=0&pnid=14678&lc=en-US

For HMIs I found my own way. If I know what I'm modifying, I can work on my own copy of the project. Then I retrieve that project into a new folder, which opens in TIA Portal. Then I open TIA Portal again with the target project, and copy the tags, screens, or objects that I've added/modified.

Phill77 said:

I have concerns around engineers accidentally modifying the wrong machine.

Click to expand...

Interesting thought. Can a PLC program access an identifying property of the PLC it is running on e.g. the MAC address? If so, then perhaps there would be a way to ensure a given program cannot be downloaded to, or at least no run on, the wrong PLC.


I have heard of a signature (checksum?) capability in A-B, that has something like this capability. The context in which this is used is that a contractor provides a program with both (safety?) signature, so the program cannot be changed without also changing its signature as evidence of the change, and a password. The password is not handed off to the customer until they ask for it, at which point responsibility for the PLC, and anything it does, passes to the customer from the contractor.

drbitboy said:

Interesting thought. Can a PLC program access an identifying property of the PLC it is running on e.g. the MAC address? If so, then perhaps there would be a way to ensure a given program cannot be downloaded to, or at least no run on, the wrong PLC.

Click to expand...

Can't speak for other PLCs, but on ControlLogix you can use a GSV to read the processor serial number. You then compare it to the stored value set when the machine was commissioned.

I believe you can also read serial numbers from other modules as well, though I've never seen it done.

drbitboy said:

Interesting thought.

Click to expand...

I have done it on a Red Lion before and have had people do it on a DH+ network, the Red Lion was on the Ethernet network and since I did it I just blamed it on a 'software glitch' the DH+ shut down the plant during the off shift and I had to go in early to get it back up and running, they downloaded so we have two node 2's (it did not like that)

drbitboy said:

Interesting thought. Can a PLC program access an identifying property of the PLC it is running on e.g. the MAC address? If so, then perhaps there would be a way to ensure a given program cannot be downloaded to, or at least no run on, the wrong PLC.

Click to expand...

Siemens lets you pull things like a serial number from the PLC, yes. It couldn't prevent DL, but you could stop it from going into run.

From my perspective, the more likely issue would be that with multiple PLCs in the same project, an engineer goes to make a change in PLC A, but makes it in PLC B instead, and then downloads PLC B's project with the change meant for PLC A. PLC B's process is now running incorrectly, and you might not notice something was wrong for a bit. PLC As project is ALSO running incorrectly, because it never got the change it was supposed to get in the first place.

It's certainly possible to download the project to the wrong PLC, but by default Portal will look for a PLC with the matching IP instead of browsing the network to see what is available. Only if you can't find a match do you need to do the full browse. It's an issue on initial commissioning, but rarely after that (unless there have been some other big goofs to screw up IP addresses/networking).

I have a site where we have maybe 10 PLC, 6HMI and 4PC stations in one project.

I don't work with it that often so I can't give a representative picture but I haven't found anything negative about it

/Tim

mk42 said:

From my perspective, the more likely issue would be that with multiple PLCs in the same project, an engineer goes to make a change in PLC A, but makes it in PLC B instead, and then downloads PLC B's project with the change meant for PLC A. PLC B's process is now running incorrectly, and you might not notice something was wrong for a bit. PLC As project is ALSO running incorrectly, because it never got the change it was supposed to get in the first place.

Click to expand...

That's the exact situation I am worried about.
The PLC can be password protected, but I think once you enter the password to unlock the session it does not prompt you to enter the password every time you download. If the engineer was prompted for a password every time then I think I would be happy.

Thanks for all the comments.
Phill

Are the machines 100% standardized ?
Are they in the same network, or in different networks ?

If you have PLCs in the same network, then they should have unique names, also unique network names. TIA will not accept that you have multiple identical device names in the same network.
With that, it should be impossible (bar the malicious intent of the programmer) to load the wrong program in a machine, even if it is otherwise identical with another machine, apart from the name.
edit: I would say that if the various devices are in the same network, then they should to be in the same TIA project.
But is a problem if multiple programmers have to work on the same TIA project at the same time. There is multi-user, but it costs extra licenses, and as far as I have heard it is not perfect.

If the machines are not in the same network, then I dont see any reason to have them in the same TIA project.

With identical machines in different sites or networks, there is the risk of loading an update to the wrong machine.
Positively identifying the machine before making any changes is an absolute requirement. There are multiple ways to do that.
1. Having a unique identifier in the program, and compare the identifier offline to online.
2. Use the flashing function of CPU LEDs or HMI screen to have a person onsite verify that you are connected to the correct machine.
.. Preferably both.