Platform Showdown: Rockwell vs Emerson

Join Date
Dec 2016
Location
Southeast
Posts
134
Rockwell PlantPax w/Factory Talk Batch vs. Emerson Delta-V Batch.

Replacement of 50 DCS Controllers in a single building. Life Sciences sector.

Anybody here have enough experience on both platforms to compare and contrast the two at the Development and Operations levels? I've heard my fill of how 'great' both of these platforms are from the 30,000-foot-level, but now I'd like to hear the real deal from the developers on the ground who use these systems day in and day out.

What are the 'dirty little secrets' you won't hear from the vendor's sales people? What are the most irritating features of both? Are upgrades any more difficult with one than the other? Are there any developer features that distinguish one from the other? Are CHARMS really worth it, or is that just a marketing thing? What about M-series vs. S-series with Emerson? Does one vendor kill you more with licensing fees than the other?

I don't know much of anything about either system except some ControlLogix programming recently and a couple of Emerson classes I took (Programming I, and Batch), but we've got plenty of Rockwell PLCs here and the one thing that I find *very* annoying about them is all the different versions of application software, the different versions of firmware, and all the licensing and rules associated with all this. To me, it looks like a business model that shouldn't be rewarded. For that reason, I'm partial to the Emerson system, but I realize this is a myopic view.

Any thoughts?
 
Havent used deltav in almost 10 years but from memory .DeltaV you tend to use alot if or built blocks and a lot of fb programming. From what I remeber deltav Is quite expensive up. Not much difference functionality wise between s and m series aside from hot swapping and charms on s series. I remember charms being around $200 usd per point not including the rack/comms module for long runs may be worth it. Another feature I liked about deltav was the ability to do partial downloads without shutting down the processor. Deltav also comes as a whole package hardware hmi and programming software and I believe licensing is tag based but it has been a while. Hmi development is similar to plant pax all prebuilt objects linked to processor blocks.

One thing with DCS IMHO is that it is not as open as with pacs in terms of going with different hmi vendors alt hough I have never attempted to run a deltav proc through another visualization program.

Plant pax does kind of level the playing field in terms of reduced development time. And while the different version is ab software may be annoying it allows to to pay for only what you need.

Really it will come down to price and local support.
 
One thing about Rockwell having so many different versions of software is that they do get updates often, but your plant controls guys should be on top of your systems and make them as ubiquitous as possible with firmware versions and application versions.
 
How about *this* solution: Neither platform!

We already have an I/O system that is gathering all our data points (13,000 site wide) and MUXing it onto an Ethernet wire. Why do we even *need* any PLCs? We could just send the data directly to an array of redundant servers that could do the control and output back to the I/O system. I really don't see the need for any of these "programming in a box" package systems.
 
What software runs in the server(s)? Who supports it? Assuming you get around all of the technical hurdles getting the I/O back to the servers. What kind of network infrastructure will you have to implement to maintain a reliable connection to the I/O?
 
How about *this* solution: Neither platform!

We already have an I/O system that is gathering all our data points (13,000 site wide) and MUXing it onto an Ethernet wire. Why do we even *need* any PLCs? We could just send the data directly to an array of redundant servers that could do the control and output back to the I/O system. I really don't see the need for any of these "programming in a box" package systems.

Is that hypothetically possible? Sure. A PC should be able to communicate most Ethernet IO protocols. I assume you have the network infrastructure in place to manage it.

Managing the redundancy itself might be a little tricky, depending on the IO and ethernet protocol used. IO control is different than something like a load sharing web server. The servers would need to be syncing data constantly, to ensure that all internal state is shared. That way when you fail over from server 1 to server 2, it knows things like 47 is halfway thought its ramp to the new setpoint and valve 12 is in manual mode.

Besides the redundancy, one of the really hard parts with a PC based system would be changing the code during operation. 99% of the time that PC code is deployed, it needs to stop execution before the new code can start. I don't think the type of plant that uses a DCS would be up for that sort of limitation.

PC based control does exist, and some of those "programming in a box" vendors do sell a version of their controllers that can be installed on a PC. These usually have special realtime kernels so they don't have the kinds of timing issues that windows typically does.
 
I suspect at the size you are talking, you might be able to put a business case together for writing your own software. You would need to show how you intend to ensure it can be supported over the next X years, but hey, people support things all the time.

"Hey, rather than a few million on software licenses /year, why don't we just start a few million dollar/year batch software development team?"

I would be interested to see your figures Vs your quotes.
 
What software runs in the server(s)? Who supports it? Assuming you get around all of the technical hurdles getting the I/O back to the servers. What kind of network infrastructure will you have to implement to maintain a reliable connection to the I/O?

What software? Just a real-time operating system (probably a Unix variant) and a whole lot of (modular) custom code written in an off-the-shelf language like C++.

The I/O is currently already getting back to 40+ 68000-based Controllers (arranged by area), which run a Unix variant OS with dual (asymmetrical) CPUs (1 CPU to collect the I/O input, 1 CPU to run the control logic). So the new servers, loaded with multiple *symmetrical* CPUs, plenty of RAM and HD space, would replace these Controllers, reducing them down to probably 8-10 in number (but also, still arranged by area).

The network infrastructure is already reliable.
 
Is that hypothetically possible? Sure. A PC should be able to communicate most Ethernet IO protocols. I assume you have the network infrastructure in place to manage it.

Managing the redundancy itself might be a little tricky, depending on the IO and ethernet protocol used. IO control is different than something like a load sharing web server. The servers would need to be syncing data constantly, to ensure that all internal state is shared. That way when you fail over from server 1 to server 2, it knows things like 47 is halfway thought its ramp to the new setpoint and valve 12 is in manual mode.

Besides the redundancy, one of the really hard parts with a PC based system would be changing the code during operation. 99% of the time that PC code is deployed, it needs to stop execution before the new code can start. I don't think the type of plant that uses a DCS would be up for that sort of limitation.

PC based control does exist, and some of those "programming in a box" vendors do sell a version of their controllers that can be installed on a PC. These usually have special realtime kernels so they don't have the kinds of timing issues that windows typically does.

The I/O protocol is already implemented. It would just need to be ported to the server(s).

I mentioned redundant servers, but I'm not really sure if that's even necessary given the hardware redundancy you can build into servers nowadays (redundant power supplies, redundant hard drives, multiple CPUs), plus the use of Virtual Machines.

With regard to changing the code during operation, I'm envisioning a system similar to the military applications I worked on years ago out of college: A privileged real-time OS running hundreds of task-level modules running as independent processes in memory. If you wanted to update one of those modules, you just "warm-started" it - which meant it would be reloaded by an OS-level privileged task right off the disk and sent a "restart" message. All you would have to do is compile the new executable and place it on the disk. Then, at a System Level "Console", you could force the "restart" of one or more instances of this module across any number of affected Servers (in parallel, if possible). It would be WAY better than these "programming-in-a-box" systems that require you to go around to each PLC and download the program again and again.

And no - Windows would *NOT* be the Operating System used. No way!
 
I suspect at the size you are talking, you might be able to put a business case together for writing your own software. You would need to show how you intend to ensure it can be supported over the next X years, but hey, people support things all the time.

"Hey, rather than a few million on software licenses /year, why don't we just start a few million dollar/year batch software development team?"

I would be interested to see your figures Vs your quotes.

The quotes are in the $8-$12 million range, but after the smoke clears, I'm guessing the metric will work out to something like $1 million per 1000 I/O, or $13 million! That's a LOT of room to come up with your own system that could be supported by any software developer familiar with systems built with COTS components (eg: C++). And like you said - no licensing fees - ever! Yes, this would be a "custom" system, but it's not like we would be creating our own software environment (or language). We would be using standard hardware and software.

And I think support is overrated. A lot of this so-called "support" is to fix problems created by the vendor itself. And look at the "upgrades" you pay for. Once your system is built and up and running, how much of that stuff do you actually end up using? Little to none! It's mostly aggravation for you. I can tell you that we've had a "custom" system running here for *many* years now, next to ZERO support, no licensing fees, very few "upgrades" over the years, and virtually no problems. We have a very stable system, and we've even expanded it over the years as the Plant has grown, but we've reached the point where hardware support has become a big problem (ie: just not made anymore). So we've swapped out some of those components for newer systems, but even those are reaching end-of-life now (although some are backed by major corporations and at least have a path forward).

I just think these "programming-in-a-box" companies exist because they've conditioned this industry to automatically go to them all the time - not unlike the world of real estate where Realtors and Real Estate Agents have not only brainwashed all Americans to use them, but they manipulate the market for their own benefit, too.

At some point you have to say 'enough is enough ... I'm tired of this racket' and come up with your own solution. For the sake of your own sanity...
 
if the outputs are controlling a physical thing, and that thing can only take one instruction at a time (say open, stay still, or close), how do all of the redundant software processes, which apparently may be running different versions of the software at a given instant while some are being upgraded, decide what the final instruction sent to the physical process is?
 
SoftwareJanitor said:
And I think support is overrated

And that right there, is the crux of why I think that very few people on this forum are going to side with you in most of your arguments.
 
if the outputs are controlling a physical thing, and that thing can only take one instruction at a time (say open, stay still, or close), how do all of the redundant software processes, which apparently may be running different versions of the software at a given instant while some are being upgraded, decide what the final instruction sent to the physical process is?

It wouldn't be like that. There are 120+ software modules, each of which control a particular function (transfers, heating, cooling, pressure, centrifuges, dryers, utilities, etc). Each module may appear in each Controller instanced once, twice, maybe even up to 12 times (tank farm), and then also across other Controllers. Some modules appear across 30 Controllers, others are only found in one, two or three Controllers. But each instance is a block of dedicated (but also duplicated) code that controls a set of Plant hardware which it "owns". So there would never be any "competition" to control any particular output. The redundancy, if even necessary, would be in a completely separate Server, a mirror image of the first Server.

As for the different versions of the modules, a parallel reload from a System Console would only be possible for "interior" logic changes that applied across the board. If, for example, new I/O was to be added to a particular module (eg: adding a new transfer valve to a Transfer Module), a decision would have to be made whether to ripple that through to all instances of the existing module (making the new valve "configurable"), OR just create a new variant of that module.
 

Similar Topics

Hello, I am trying to implement some data coming from an Compressor Controller, but cant quite figure out what i am supposed to put into the...
Replies
0
Views
118
Hi all. I received two identical brand new Dell desktops from a customer to install the softwares for a project. The first one is for a...
Replies
3
Views
442
Hello, I'm struggling to learn something on Wonderware, and the distributors are taking days to get through the email chains. I was hoping for...
Replies
1
Views
343
Hi guys, I facing some issue regarding the Historical Alarm settings. Currently my historian is configured as High-Speed storing method, and...
Replies
1
Views
274
Hello everyone, After a Deploy of the viewapp on Intouch, I started getting an error not allowing me to start the viewer "NAD unable to download...
Replies
0
Views
872
Back
Top Bottom