Platform Showdown: Rockwell vs Emerson

ASF said:

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.

Click to expand...

Well, the "support" I'm saying is overrated is that which comes from the vendors of these "programming-in-a-box" systems. It's largely a money-grab, and something we've never had to deal with here.

I differentiate that from the support people on this board are providing, which is building (and in some cases maintaining) system solutions for customers. That's value-added stuff.

But I'm also guessing - by the looks of the posts on this board, that there may not be many here who have even *seen* custom solutions - except for conversion projects to "programming-in-a-box" systems. So, I wasn't expecting much feedback.

I'd wager people on here have seen more custom solutions than you realize - the difference being they have been the ones who've been brought in to replace xyz custom scripts running on an old dos pc communicating via serial to a controller 3 generations out of date acting as IO..... Or many other examples of what happens when only a few, more likely 1 person knows how something is functioning and can troubleshoot and maintain it.

At least with a PLC - forget brand, the knowledge isn't tied to one person leaving a customer crippled if it all stops working (not withstanding keeping spares, or units being phased out and having no upgrade plan in place). There are always exceptions though

Regarding Delta vs plantpax - this more of a DCS vs PLC question for me. It is a concept of configuration vs programming. They have tried very hard to make PlantPax fall into the configuration area of things - drop the faceplate on the graphics, point it at the PIDE manager block and use that to set things up etc. The one big drawback of this I will say is that it is bloat ware, expect to be using larger memory processors than a normal programmed system. CLX is an excellent platform, and you would not go wrong with implementing your system using it, whether you use plantpax depends on the level of the programming you have available to you.

Both platforms are trying overlap each other's traditional roles in the quest for skynet. If you have any high speed discreet or motion in your plant I would go with CLX, you will end up needing something else to handle those if you go with A DCS. Though your plant may already use RMC's for motion etc. So that should be a factor as well

My 2c at least

Many on this board act like non-PLC solutions are the devil's work.

The support would be there, SoftwareJanitor can use a real-time operating system that adheres to standards (e.g. POSIX), allows for source code modification, and has commercial support available. Personally I would use FreeRTOS or NuttX.

Good luck with the cool project

raffles said:

they have been the ones who've been brought in to replace xyz custom scripts running on an old dos pc communicating via serial to a controller 3 generations out of date acting as IO..... Or many other examples of what happens when only a few, more likely 1 person knows how something is functioning and can troubleshoot and maintain it.

Click to expand...

Yeah, a number of years ago when I worked for an Integrator, I came across such a system which ran QNX (a Unix Variant). That system was a one-off that nobody knew anything about, and it ended up getting replaced with a Rockwell PLC. But those archaic solutions of years ago should not be confused with what is possible today with the kinds of machines and software available - all of which is fully supported .. just not by those who work with the typical solutions.

raffles said:

At least with a PLC - forget brand, the knowledge isn't tied to one person leaving a customer crippled if it all stops working (not withstanding keeping spares, or units being phased out and having no upgrade plan in place). There are always exceptions though

Click to expand...

Yeah - this is the main argument for going with the programming-in-a-box vendors. But it's really a fallacy nowadays. The custom solution would not be tied to one person (or a small group of people). That's a myth that's been perpetuated by the programming-in-a-box vendors, I'm sure...

raffles said:

Regarding Delta vs plantpax - this more of a DCS vs PLC question for me. It is a concept of configuration vs programming. They have tried very hard to make PlantPax fall into the configuration area of things - drop the faceplate on the graphics, point it at the PIDE manager block and use that to set things up etc. The one big drawback of this I will say is that it is bloat ware

Click to expand...

Yeah, I'm a bit concerned about the use of GEMS, or whatever the vendor's pre-packaged code is called. To me, the vendor/integrators love that stuff because it makes *their* job easier: they can throw the applications together quicker. But after they're gone, is the owner going to end up with all this "dead code" (eg: simulation logic) embedded with their process logic that they never use (but have to sift through anyway)?? Right now, we don't have any "dead code" in our system. The only logic we have is the logic we need to run the process. That's a custom system, and that's what I'd want. Maybe you could argue that the "dead code" is only going to be in 'common logic', like PIDs - that are never going to change, but still ... I'd rather not have it in there at all!

raffles said:

Both platforms are trying overlap each other's traditional roles in the quest for skynet. If you have any high speed discreet or motion in your plant I would go with CLX, you will end up needing something else to handle those if you go with A DCS. Though your plant may already use RMC's for motion etc. So that should be a factor as well

Click to expand...

Nope! No high-speed anything here. In terms of computer time, it can take all day and it wouldn't matter (LOL!).

Epy said:

Many on this board act like non-PLC solutions are the devil's work.

Click to expand...

That's pretty funny! Maybe the earlier DOS-based systems that some might've run across could've qualified as the 'devil's work', but not a more modern, multi-CPU, Server-based system with virtually unlimited memory and hard disk space, and inherent redundancy. That's just a very capable machine doing the work of multiple PLCs, but in a much neater footprint (both physically, and financially). The only "drawback" is you don't get the running start with all the pre-packaged code that comes with the 'programming-in-a-box' solution.

But for this site, at least, that wouldn't really matter much. Off the top of my head, the only thing we'd need is a PID algorithm, and multiple flavors of those can be imported from anywhere.

But you would get a running start. You can use open-source libraries for free, or pay for a commercial license of a pay-for software library if you don't like the idea of open-source.

General for-instances:

Here's your Modbus: http://libmodbus.org/
Here's your OPC UA: https://open62541.org/
Here's your EtherNet-IP / AB / Rockwell: https://github.com/kyle-github/libplctag
Here's your Siemens: http://snap7.sourceforge.net/

Et cetera

Open-source software is the best, if it doesn't work, you can change it yourself, and in many instances the original/main author will consult and give commercial support.

Sounds like you have made up your mind and you are working to get an internal consensus.
Custom solutions have been around a while. Lots of companies have done it. Dow did this in the 70's and those systems ran for a long time. Some are probably still running. This is an old article but interesting anyway: http://www.controlglobal.com/articles/2006/029/
Of course there was a HUGE company behind that effort with a significant investment of resources to deploy world wide. Clearly computer technology and hardware have change significantly over the years so the board level design effort wont be there. How do you validate the software? Confirm that it does what you think it should? You write code the compiler compiles it adn it runs.. Maybe. Unless the compiler changes or the software has changed a little. Maybe your PID or your digital filter doesn't act quite the same this time as they did the last version. Are you going to build your own control software library? If you use somebody else's library then you are back to the "program in a box" model but now its software in a box. If you don't then you are looking at a large software development and validation effort. As with any project system documentation will be crucial. In this case the software internal design specifications and documentation will be even more important as it will be a one off that lives only at your site. It would be a cool project. Not sure I would want to be the next guy to have to deal with it though.
Just my two cents.. BTW I work in a plant not for the any of the "programming in a box" guys mentioned and don't have a dog in this fight either way. Good Luck!

Hi Rem, good points. In response to your comment about validation:

In the computer programming world, the de facto standard mission-critical language is Ada. Ada is used in avionics, defense, real-time systems, etc. Ada is also an ISO/IEC standard, has been around since the 80s, and was originally developed by Honeywell under contract with the US DoD. Ada is also syntactically very similar to Pascal, just like IEC 61131-3 Structured Text.

One of the developers of the Ada reference compiler, AdaCore, has developed a subset language called SPARK, which has proving and validation tools as part of the toolchain. http://www.spark-2014.org/about

Outside of that, there's a whole specialization in the programming world devoted to this problem: unit testing.

@SoftwareJanitor: sounds like you've already got things worked out for yourself, but if you were interested in Ada, there's already a project for using Ada in industrial automation: https://slo-ist.fr/ada4autom

Remrun said:

Sounds like you have made up your mind and you are working to get an internal consensus.

Click to expand...

LOL! I wish it was that easy. The only shot I have at avoiding getting steam-rolled by the "Programming-In-A-Box" proponents" is to prove a sizable cost savings. It's definitely an up-hill battle!

Remrun said:

Are you going to build your own control software library?

Click to expand...

All we need is a PID algorithm. The rest will be just common routines, but some of that will be privileged-level tasks to handle things like Display data, Recipe/Phase sequencing, Network comms (?), PI data. I really don't think it's a big deal. It will end up being a lot of code, but there's a LOT of instancing/replication, so if you just focus on the unique stuff, it's not that bad.

Remrun said:

you are looking at a large software development and validation effort

Click to expand...

We're looking at a large software development and validation effort regardless. Made me laugh when the Rockwell sales people came in and said Validation would be faster with *their* solution because they'd be using GEMS (or whatever they now call their pre-tested/pre-packaged/pre-validated logic). Over the years, we've done our own validation in-house and we've had outside companies do it. Not *once* in all the years I've been here has a single validation person ever inspected any of my software to see if I used so-called "pre-validated" code. They simply run an OQ procedure and verify what they see on the screens.

Remrun said:

the software internal design specifications and documentation will be even more important as it will be a one off that lives only at your site. It would be a cool project. Not sure I would want to be the next guy to have to deal with it though.

Click to expand...

We've got very good documentation here (for our current "custom" system), and we've been very good about updating it over the years as we've made changes (and we've made PLENTY of changes). But our software is graphical and considered "self-documenting", so there are no 'Software Design' documents. We only have Functional Description Documents. But if we were to produce a new custom system here (replacing the graphical software), I would have no problem putting together some very good documentation describing the design of the system. For anyone who comes along later, they should have no problem working on the system.

Epy said:

Hi Rem, good points. In response to your comment about validation:

In the computer programming world, the de facto standard mission-critical language is Ada. Ada is used in avionics, defense, real-time systems, etc. Ada is also an ISO/IEC standard, has been around since the 80s, and was originally developed by Honeywell under contract with the US DoD. Ada is also syntactically very similar to Pascal, just like IEC 61131-3 Structured Text.

One of the developers of the Ada reference compiler, AdaCore, has developed a subset language called SPARK, which has proving and validation tools as part of the toolchain. http://www.spark-2014.org/about

Outside of that, there's a whole specialization in the programming world devoted to this problem: unit testing.

@SoftwareJanitor: sounds like you've already got things worked out for yourself, but if you were interested in Ada, there's already a project for using Ada in industrial automation: https://slo-ist.fr/ada4autom

Click to expand...

Whoa! Ada for Automation?? I LOVE it! You know, when I got out of college a number of years ago, my first job was with Raytheon working on large-scale software projects for the Navy. Right before I left, the Navy was starting their C.O.T.S. (Common Off The Shelf) Initiative to move away from proprietary Operating Systems (Unisys) and languages. Ada was the future, and we had started writing Ada PDL toward that goal. I think they ended up going to C++, however, with Posix (or Radix, which I believe was a Raytheon Posix-compliant Unix variant). Not sure what became of Ada, but it *must* have been used *somewhere* in the Government Contracting circles.

Thanks for the info! You're inspiring me to push forward. Wish you were here, though. I could use some help ...

Well feel free to PM me about anything SJ.

You might also be interested in Eclipse 4DIAC (https://www.eclipse.org/4diac/) which is an implementation of IEC 61499, and also includes the ability to use IEC 61131-3 languages. What's special though is the ability to use C++ in function blocks. So you could do a bunch of 61131-3 code and be standard that way, and then use C++ in another block to do more advanced things if you want.

SoftwareJanitor said:

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.

Click to expand...

Oh god, not this again.

This is not what you want to hear but I say hell no to C++, ADA, python, etc..

I absolutely understand the temptation and I witnessed many PC programmers make this mistake in the past. Industrial control is screwed up (from your viewpoint) for exactly the RIGHT reason. Online editing, viewing of parameter values, and most importantly, programs that can be supported by a large base of people. As great as you think you can make your programming to be, it will be hard to support.

Also, back to the DCS vs PLC question. I came from the DCS background and now work primarily with PLC. DCS is as different to PLC as PC programming to the industrial world. IMO, it takes many years of experience before a PLC programmer becomes experts while someone can be very proficient with DCS after a month or two. One big mistake I seen, similiar to the PC world vs industrial computing is that DCS programmer trying to make PLC work the way they are used to in the DCS world.

It's human nature to use what you know to solve a problem. I seen this over and over again. Not everything is a nail if you know how to use a hammer. Be very wary of your own limited prospective and experience.

/off the soapbox

I'll just say this: especially with the IoT stuff taking off, we need Linux-oriented devs in the industrial automation space. Then you will have your support.

Relevant: http://linuxgizmos.com/survey-shows-linux-and-freertos-out-front-in-embedded-tech/

I always laugh at the custom solutions. The end user wants to save money and roll their own.... blah blah
They do it and the years goes by. The main guy leaves... and operating systems change....
Then the end user is left with a non supported mess.
But hey, they saved a few bucks on the front end of the project
And Janitor, you can be hired back as a consultant
Haha