PlantPax Reviews? Does anyone have good or bad Experiences?

We are still in the process of deciding whether we will be using PlantPax (Large Pharma system here) or another solution.

The problem I have with these claims of being able to 'put your systems together more quickly with AOI's' etc.) is - I see that as an advantage for the *integrator*, and maybe a drawback for me (the ultimate *owner* of the system).

I don't care how *quickly* the system can be put together as much as I care about how *cleanly* it's put together. I don't want a lot of "baggage" logic in my final system, and that's what I fear will happen with these one-size-fits-all generic AOI's that allow the software to be slapped together more quickly.

I see people here talking about CPU loading with PlantPax, which makes me believe even more that these solutions contain unnecessary overhead logic - which is what you'd expect. If you can build it quickly, it's probably not going to be very efficient (or clean)...
 
A few years ago when taking a class on PCS7 (and yes, similar concept to PlantPAx), the opening statement that set it all up for my finally getting it was this:

"PLCs make things. DCS systems make stuff."

A DCS is a plant WIDE control system where the "control" is WAY WAY too many PID loops fopr a PLC to handle centrally. The centrally is the key here. If you are trying to run a pharma plant or a refinery, a LOT of different separate complex processes hare taking place simultaneously, and the outcome or variances in one process are going to affect how other processes must be handled. Any one of those processes might be controlled by a PLC, but that PLC can't handle thousands of similar processes all at the same time. A DCS system does EXACTLY that. In a "real" DCS like a Delta V, the real-world hardware is some proprietary stuff made by Emerson that gathers all of the digital and analog I/O data, ports it up to the DCS processor (often a minicomputer, not a PC) running the plant wide operation software, then the outputs are pushed down into other dedicated Emerson hardware.

The only difference in something like PlantPAx or PCS7 is that Rockwell and Siemens ALREADY make very good rugged factory floor hardware, called "PLCs" (or really, PACs now), so there is no need to duplicate the hardware. So the PlantPAX / PCS7 systems simply add that plant wide operating software on the computer, and of course all of the graphics screens, using the existing PLC products to off-load some of the processing burden and provide some level of autonomy. But really, it's still the main software / computer that's doing the bulk of the thinking, not the PLCs.
 
Last edited:
Jraef:

For our Plant (~50 DCS Controllers currently), I don't think it matters whether we go with a DCS like Delta-V, or PlantPax. They'll both do the job. Maybe we can get the overall Controller number down a little better with one over the other, but other than that - I don't see any real differences at the performance level between the two. To me, the differences are mostly up-front and long-term cost, plus this issue with "garbage" or "overhead" code associated with being able to build the system "quickly" (which I don't care about - if it means the resulting system, which I have to then live with forever - ends of being "bloat ware").

This is why I'd just rather do a custom system (on well-established commercial platforms). I think I could reduce the 50 Controllers down to 8 servers (4 servers, redundant), and my logic would be lean, clean, and efficient.
 
Jraef:

For our Plant (~50 DCS Controllers currently), I don't think it matters whether we go with a DCS like Delta-V, or PlantPax. They'll both do the job. Maybe we can get the overall Controller number down a little better with one over the other, but other than that - I don't see any real differences at the performance level between the two. To me, the differences are mostly up-front and long-term cost, plus this issue with "garbage" or "overhead" code associated with being able to build the system "quickly" (which I don't care about - if it means the resulting system, which I have to then live with forever - ends of being "bloat ware").

This is why I'd just rather do a custom system (on well-established commercial platforms). I think I could reduce the 50 Controllers down to 8 servers (4 servers, redundant), and my logic would be lean, clean, and efficient.

PlantPAx and PCS7 are well established platforms too...

I had exactly the same perspective as you when I started with PCS7... It wasn't efficient as you'd have a lot of extra code that wasn't in the specification...
However, after a little while those bits of "garbage" code ended up making a difference as a lot of the functionality is there... you may not need it today, but come tomorrow you will and it will be a matter of linking a signal to another block or point the operator to the location of the signal in the faceplate.
I'm not sure about PlantPAx, but PCS7 blocks have a simulation mode... need to do a change but can't stop the entire thing down for testing? Startup PLCSim and you'll be able to simulate the entire process on your laptop. This will also allow you to do it on the PLC level too if you feel adventurous.

To resume, yes you can achieve the same as a DCS package by programming precisely what you want in a series of PLC's, but you'll get only what you programmed and quite possibly for the same cost of the DCS package system.

So in the end it will be a matter of cost of licenses and testing (your code will not have been tested, while the DCS system is based on blocks that have been thoroughly tested) versus the engineering hours. I don't have values with me, but am willing to bet that the engineering hour cost of the DCS package is smaller than the PLC option.
 
A DCS is a plant WIDE control system where the "control" is WAY WAY too many PID loops fopr a PLC to handle centrally. The centrally is the key here.

People talk about PLCs, DCS, SCADA systems like we all have the same ideas as to what they were and what they are now. When in reality, back when the terms came out, these systems and their abilities were much different from what we have now. DCS stood for Distributed Control Systems, but I never could find anyone that made it clear what was being distributed, the I/O or the controllers.

25-30 years ago, it seemed to me that PLCs and DCS were very similar on a hardware standpoint. It was generally understood that a DCS did analog cheaper, and a PLC ran discrete cheaper and faster, but both could do either. A DCS would consists of several groups of controllers each talked to remote I/O racks. A PLC system could be a brick, rack with Controller and I/O, or a Controller talking to remote I/O. The thing that differentiated them was the HMI. With the PLC, configuring a HMI required exporting tags to an HMI configuration program, setting up the graphic, and exporting it to the display. Each display that was set up communicated directly with each PLC. Usually the communication was mainly to one PLC.

On the other hand, a DCS had the HMI well integrated with the system. Tags did not need to be exported from the controller configuration platform to a graphic system platform. The tags came from standard logic blocks created by the controllers configuration and had associated faceplates available for the HMI. If the tags were configured in the DCS, they were available for the Graphics platform without needing to export or update tag lists. The HMI communicated to (redundant) data servers, and the data servers communicated with the controllers.

Over time, is seems like the DCS systems got the graphics less integrated as they moved off Unix and proprietary operating systems and moved to Microsoft operating systems. On the other hand, PLC HMIs become more integrated. The HMIs are the interface for several controllers. They started using data servers. Then they came out with logic blocks for controllers that would corresponding graphics in the HMI.

Since historically, the DCS system was a big well integrated system controlling the things that made stuff, marketers called their PLC with a fancy HMI system a DCS system. Another marketing idea is to call it a PAC, the new term for a PLC/HMI with classic DCS features.

Then there is the Supervisory Control And Data Acquisition (SCADA). I had always thought of these as being an HMI/Historian system didn't have an operator sitting in front of them. They were for systems that didn't basically ran without much interaction. They were usually on systems controlled by PLCs. I never heard controls guys call the HMIs a SCADA, as they refer to the type/brand of PLC and type/brand of HMI. On the other hand, IT guys call every system with an HMI a SCADA systems.
 
Ok, thanks for the info.

As someone who originally came from a DCS background, I can both see the benefit and potential pitfall of such a system. Afterall, I seen such a system back in the SLC 5/05 days that ended badly because all the logic blew up the memory capacity and took out the online ability but i can see how the newest contrologix can handle such thing easily.

As far as troubleshooting, as long as someone sticks with the structure and not go rogue with hidden code outside the PlantPAX structure, I don't foresee an issue.
 
DCS stood for Distributed Control Systems, but I never could find anyone that made it clear what was being distributed, the I/O or the controllers.


To me, PLCs were typically "one-offs": "here's a PLC program to run this mill right here". "And here's another PLC that runs this dryer". Each one had its own dedicated panel display locally, and data was sent back to a Historian.

The DCS, on the other hand, was an "army" of Controllers working together to run some large Plant-wide Operation(s). They communicated with each other, and they were "Supervised" by a higher-level system that collected display data and downloaded recipes. A DCS was *not* a "one-off".

Now, of course, the lines have been blurred by the PLC's ability to also work together, "supervised" by a higher-level system.

So now, I don't think it matters what it's called ... DCS, PLC, PAC, name it what you want - it's a processor that will run your programs. So what are the real differences??? Hell if I know. And don't expect any help from the vendors in answering your questions, either - because they don't know themselves.

So just flip a coin, pay all that outrageous cost, and hope you're happy with it in the end.

Certainly not the way *I* like to make decisions...
 
Plantpax for a 12500 I/O system - 10 Controllers

Just checking with you guys how PlantPax from Rockwell is performing in large applications. I had very bad experiences running RSView Se on quite large applications (more than 10k I/O) but I have been out of the Automation world for a while so I dont know if the product got mature enough for large applications during the last 8 years.

The system I am looking to upgrade should use around 12.5k I/O, around 3000 motor objects, 500 valves objects, 1500 analog inputs, 150 PID.

thanks for your comments.
 

Similar Topics

Hello, i need to use P_Intlk and feed the Status interlock OK bit to a P_DOut block. However, there's 17 interlocks for this output. How can I...
Replies
1
Views
106
Hello All We have 3rd party vendors that run on older versions of PLC (Plc2.0) while we run the main system using plantpax and PLC 3.5-10. Plantpx...
Replies
0
Views
88
Dear Members, Hello, we are working on a project and facing an issue with the plantpax 5 PMTR library, we have a bidirectional motor, which has 2...
Replies
6
Views
236
The PMTR has a timeout parameter for run feedback during a start, but once the motor has been running for a while and loses that run feedback (to...
Replies
0
Views
221
Hello, I am upgrading some custom AOI's for a customer that was using plantpax 3.5 they are moving to Pax v5. In their old AOI's they were...
Replies
0
Views
530
Back
Top Bottom