PlantPax Reviews? Does anyone have good or bad Experiences?

lunenburger

Member
Join Date
Jul 2008
Location
Summerside
Posts
207
We are getting a two day presentation from Rockwell on PlantPax.
Does anyone have any experiences with PlantPax that they could share?
We are looking at thin clients and remote support....
 
Last edited:
I have asked them about it twice and I still don't really know what it is.

I know its option #2 on tech support, so that can't be good.
 
In my experience Plantpax is good for larger plants and for standardisation across a companies facilities

However it relies on large AOI's and High Screen counts for FTSE so it drives sales of high end PLC's and high screen count licences also
 
On Rockwells Website they leave the details pretty vague.
Also, they are calling it a DCS system using Controllogix which I find surprising....
 
Its just a large library of very nicely built HMI screens, global objects and a bunch of AOI stuff. Its lots of pre-defined code that just looks like a well put together integrator project. Its just the money they charge for the licenses and such. As one already mentioned its intensive on the tag and screen counts. We looked at it for our facilities. We are fairly large but it seems for more massive sites, continuous process and such. There are some nice face plates and some bits of code you can pull out. I played with them a bit as they are free to download, just expensive to run.
 
One issue that I have found with PlantPAX (after 4 installations/upgrades) is that it uses a LOT of cpu power. We've had to upgrade all the L6 processors to L7s in order to do the same "work" with the PlantPAX AOIs. You'll want to eliminate any continuous task you have and go to only periodic task to provide enough down time in the CPU for comms.

Also, they are going to show you the gray-scale, High Def, stuff, don't get too hung up on that. If you already have standard colors, you can edit the PAX objects to your color scheme.
 
I haven't used PlantPAx yet, but used the PCS7 which should be similar.

On PCS7, you'd start off by configuring your hardware (PLC's, remote IOs, SCADA servers, Clients, Switches and so on). Once that is configured, you then describe the functioning of the plant via code blocks in code sheets (a bit like FBD). You can write your own blocks and use them in the PCS7 sheets, but usually there will already be a block that does what you require.

Comms are also taken care of when you decide which PLC will control a certain sheet, because you are describing the process, you first worry about describing it and then put the sheet in whatever PLC is more adequate (based on IO distribution).

You then compile the project and it will create a WinCC SCADA project where all the objects are in the correct screens and all you need to do is rearrange them and put some pipes between them. Most alarms are generated automatically by the system which is quite nice and the IO config is also interesting.

One important thing to remember is that it works on periodic tasks and not like a normal PLC would...

Overall is pretty neat and there's value to it, but it's basically a tradeoff. You can achieve the same result by programming a PLC and SCADA yourself, but would take you a long time. With this type of system you can probably get through it in a day or two. However, you'll be paying for more licenses, paying for much higher grade hardware and so on.

I would estimate that any system's integrator that has been in business for a few years (like 5 or so) will probably already have a similar codebase available to achieve the same and won't be tied to a certain SCADA package.
 
Interesting, I been trying to get some info on it as well.

Sounds just like Windows 3.1 on MSDOS. I wonder how much $ difference is this vs a "real" DCS like DeltaV?

When I worked with DCS in the past, the dig is always that the interface and control programming is worth the $ but price for IO breaks the bank so I see a lot of AB PLC with only data passing to a DCS. There has been many other attempt to have a DCS like overlay on a PLC, some ended in flames but this is a inhouse product.
 
As stated above Rockwell's PlantPAx uses Logix hardware including compact logix , point I/O, flex, Armour point, or 1715 redundant I/O. Controller selection depends on how many "control strategies". Read that as how many loops you have. Primarily designed for use in process or batch applications. The PlantPAx controller software is essentially a collection of AOI's that are used to speed up development. On the HMI side each AOI has a face plate and generally a shape associated so that you should be able to drop in an AOI into the controller put a shape on a screen and a face plate will be associated with the AOI and the shape. This is pretty much what goes on in the typical DCS platforms like Honeywell Experion or DeltaV. The upside is that if you have alot of existing fairly current RA hardware AND you are going to do a rewrite it can save you some time. The downside is that the AOI's are a significant controller load and typically require more controllers and memory than just writing a one off your self. But you wont have a one off and they AOI's etc are supported by RA. I have been doing DCS control systems for years and have looked a RA for a while now. While it doesn't make sense due my installed base of brand X in my application they are worth a look. Like most of the other vendors there a lots of other features as well.
 
Thanks for the information...
After the presentation, it looks like the PlantPAx is a structure of AOI's and prebuilt graphics.
The manual can be downloaded here:
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/proces-rm001_-en-p.pdf

Like everyone has previously stated, the programming is an extremely complex system of AOI instructions, I am not sure how anyone could navigate the programming to find an issue.

Still not sure why they call it a DCS? It's still a PLC with a graphics package....
 
Like everyone has previously stated, the programming is an extremely complex system of AOI instructions, I am not sure how anyone could navigate the programming to find an issue.

Still not sure why they call it a DCS? It's still a PLC with a graphics package....

If you lay out the program in a structured way, finding problems is really easy with PAX objects.

We don't use the AB layouts where each block (motor, interlock, e300, etc) is on a separate page, we use the largest page available and put everything on the same page. Is easier to follow that way.
 
Thats pretty much what all DCS's are now days. There is a controller and servers/clients for HMI, historian etc. Traditional DCS vendor have all that rolled together tightly so that its not real easy to see the seams or pull apart.
 
Like everyone has previously stated, the programming is an extremely complex system of AOI instructions, I am not sure how anyone could navigate the programming to find an issue.

Still not sure why they call it a DCS? It's still a PLC with a graphics package....

If the programming is done in a logical way, finding an issue is usually a breeze compared to a regular PLC program. Part of the reason for this is that their AOI's have been tested far more than a regular PLC program has. The function blocks all follow a documented standardized interface and there is documentation explaining exactly what the block does.

I would organize my code per tag number where each tag number would have an FBD code sheet. In it you place all the blocks related to that tag number and the conditions for it to work (interlocks and so on).
Once all of this is done, you'll realize that there is very little, if any, code left on a chemical process that requires dealing with.
You'd then compile the graphics package, put some lipstick on it and you're ready to roll.

I honestly felt the same way when I was confronted with PCS7, but after a little while realized how much more you can get done compared to the normal PLC environment, that it does make sense to use these DCS packages for chemical processing plants. Obviously, this wouldn't work nicely in a packaging machine, but there is a place for these systems in the market for sure.

Edit:
You can also get a glimpse of PlantPAx on RS Studio 30 if you have it with you. If you look at the ALMD and ALMA instructions, I am willing to bet they are the ones used by PlantPAx so that you can create and manage alarms in a consistent way. If you use these, you configure the entire behaviour of the alarm directly from the PLC and the HMI will follow suit. This is exactly what is done on a DCS package.
 
Last edited:

Similar Topics

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
50
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
185
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
195
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
499
Hello, I am trying to design a new system using the latest and greatest in PlantPAX but also wanting to use STO over ethernet for vfd's. The...
Replies
3
Views
669
Back
Top Bottom