Why do you pay for PLC programming software?

> I also use unitronics. HMI options not as awesome as Siemens or AB, but FREE.

Unitronics are not PLCs - they are horrible smart relays with very clunky software. If they charged for the software they would go broke fast!!
 
G

Gary H. Baker, EE

>>My question is simple, but the answer escapes me. To all
>>you devoted Allen Bradley people and to everyone else who
>>uses PLCs, why do you pay for their programming software?
>
>Because I don't know how to steal it. LOL

Having just suffered through 3 days of introductory AB training I have a couple comments:

1) The majority of the AB devices and software seem to be hampered by complete disregard, acceptance or appreciation for well defined computer science programming standards like regards Linux, C++ and Python used by Arduino and Raspberry Pi. I suggest they get subscriptions to IEEE Spectrum, Computer and Communication.

2) Ladder Logic, Structured Text & Function Block look as if they might be programming languages that have been purposely disguised in the name of remaining special and proprietary.

3) Most AB Control Engineers seem to pride themselves for not being or wanting to be programmers. Remember, for generations lots of discrete hardware designs have been sucked into software.

Are AB automation technicians and this AB PLC automation industry really feeling threatened by the progress made in computer science? They seem to be mostly electricians unhampered by this progress, and proud of it!

I am sure a PC, Linux and Open Source style revolution is just what is needed and it is starting to happen. Approximately 1,000,000 Raspberry Pi are being produced annually, and 500,000 of these devices are going into industry. And don’t think for a minute that the Arduino and Maker movement are not actively looking at this situation. It pays to remember also that Linux rules the internet and makes it possible - Amazon, Facebook, Google, etc, etc, etc.

 
D

David Ferguson

Well well where to start.......

First of all a 3 day introductory class isn’t quite enough time to grasp the breadth of Rockwell equipment....but I digress.

Your 3 points......

1. I’m not sure what class you took but The Controllogix platform is very in tune with the modern control standards that are out there.....in this case IEC 61131-3.
Standards of a multitude of languages that have been around for 30 years of industrial control programming.

2. They are languages designed and used by the plant end users, who are required to keep equipment running 24-7-365. When break down can cost 10’s of thousands of dollars per hour in downtime.....this isn’t some desktop app or phone app written in C sharp or a game.....Lives are at stake due to the control of extremely dangerous equipment, and the end users of that equipment front line diagnostics start with electricians on shift, at 3am when you are home in bed.

3. I have done this for 30 years......I have written very basic logic and extremely advanced code with object oriented principles using global objects designed with all the same fundamentals of encapsulation, polymorphism, abstraction and inheritance. And I have written 3 line ladder logic......It depends on the strength of the end user like any good programmer......If I build it so that no one can troubleshoot it, I fail.....but I also understand that this is not some $99 arduino app that I am going to trust to keep lives from being put in jeopardy.

I have received the call when a coworker was killed by the machine to see if the “code” was at fault, and I have seen machines kill and greatly maime more than once. So I understand just how “industrially hardened” this equipment must be, and what a dangerous job it is.

I am scared to death by the flippant attitude of people who take a couple of computer science courses and think they have seen the light of good software design.......

This equipment has been around for ages and is far more advanced and can be than you seem to grasp in your 3 days course. It has to encapsulate many disciplines from electrical, motion, process control, motor control etc etc as well as computer science.

And before you lump me into your classification of feeling threatened by the progress of computer science......I have been an Electronic repairman fixing chip level video games in the 80s, an Instrument tech, an IT guy and a Control Systems Engineer........I started with computers on a teletype with an acoustical coupler in 7th grade......I have programmed in just about every language. I was part of a team that was the first double winner of Microsoft’s Windows World contest for custom programs beating out Chase Manhattan Bank and GE worldwide, as well as, Aramco and other big names. I met and drank a beer with Bill Gates, and I have led numerous multi million dollar controls programs writing 10™’s of thousands of lines of code. I am a Microsoft MCSE, ISA CCST and CAP and certified in Virtualization and managed and designed our industrial control network with 100s of servers and workstations.........

I realize this is an old thread that had been around for ages......but just as you accuse AB guys not wanting to be programmers......I think you should take more than a 3 day course in something you don’t know the history of and just like you think that we should adapt $99 arduino and raspberry PI tech and Facebook and Google technologies. You should open your eyes to something that has been controlling plants for over 100 years Allen-Bradley and their PLCs and PACs controlling equipment for my entire 35 year career.

Know you customer and the risks involved ......no company should trust their equipment and livelihood to $99 arduino and Facebook tech just yet, and there is a long way to go before my life depends on internet connected tech.

Just like autonomous vehicle programmers are learning how hard it is to write code to......
A. Save the occupant of the car by putting it in the best position in a crash.

B. Swerve the car to save the driver and kill the little old lady on the sidewalk. Or

C. Save the occupant, the little old lady and kill the mom and baby walking on the other side of the street with the baby buggy.

There’s a lot more to good, safe programming than the coolness factor when you get to this league.

Now that you understand what’s involved, maybe you should go work for Facebook or Amazon where you code won’t hurt anyone.......

Unless it’s programming the Kiva robots in the Amazon warehouse.

Dave Ferguson
Control Systems Engineer
 
It is true that the IEC-61131 languages are quite dated by modern standards (or more typically the tools are dated), though vendors frequently enhance the spec (ie Codesys supports inheritance and more OO concepts). These enhancements are also one of the reasons there is no perfect cross-vendor controls language.

However, not all of it is age. They are domain-specific languages that emphasize different things, and you have to understand what the intent behind the language is.

Function Block language is about data flow. This is fundamentally different than a traditional procedural language, because controls engineers are primarily thinking in terms of control loops and manipulation of signals.

Ladder logic is all about sequencing and quickly tracing the cause of a condition or what conditions must be true for an output to occur. Many people consider LL to be dying, but this is more of a religious debate and winds up being very generational. A lot of older engineers love LL. Not my favorite.

SFCs are basically computer executed flow charts, and IMO are the best representation for sequencing and state of a control system.

Structured Text is a very Pascal like language, useful for cases where you need loops or complex conditional evaluations. However, ST suffers from the same problem as other procedural languages like C or Python. Most operators and a lot of controls engineers are not programmers, but need to be able to read the control logic to trace problems. ST has to be used sparingly if the code isn't just a black box.

There is another serious issue with C, Python, and other GP languages that make them poor choices for serious controls applications. There are no "guard rails". If you have a bug, you're at best tripping your controls, at worst killing somebody. Even Structured Text is dangerous, depending on the platform. At best, procedural languages should be limited to core library functions or a few very carefully audited special cases.

For that matter, a pure IEC-61131 Function Block language can be dangerous, as it doesn't protect against arithmetic overflow or the "NaN" problem. If you get a NaN as a result of an operation and feed it back in a control loop, suddenly NaNs propagate everywhere, with really bad results. More safety-minded platforms like the GE Mark VIe go to great lengths to make it syntactically impossible to make those kinds of mistakes--saturating rather than overflowing, for example.

All that said, I'm a big fan of innovation in controls languages. I think we can do better while still providing the intrinsic safety required for controls. For example, I once prototyped a Scratch 2 editor that generates Function Blocks for GE Mark VIe, and I think visual languages like Scratch are something operators might accept. I've used something similar in the Microsoft Robotics Studio that used simple event messages to create intuitive parallel programming.

The other area that most controls platforms lag on compared to the software industry is DevOps, but that is another whole topic.
 
D

David Ferguson

I agree with everything you said......I can write spaghetti code in every language or I can write good clean safe code. When I transition to higher level OOP languages I can write ravioli code......

Good safe software takes error checking code, documentation, end user knowledge, understanding of the tools available to you.....

I really don't care what tool is used but when it comes to "can kill you", I am going to default to tried and tested tools until something else can be proven out and shown to be safe. As I said I can write crap in just about every tool, and I can write some amazing well thought out safe stuff with every tool. I have seen things from every end of the spectrum and I have been completely amazed and what some people have done with very "primitive" tools.

One thing for certain it's always interesting.

Dave Ferguson
Control Systems Engineer
 
B
PLCs are not the same thing as computers. One thing about PLCs that is radically different from your typical computer is the need to be able to run 24/7 and to be able to change the program online and on the Fly without having to recompile and reload the software. Just because they use different terminology does not mean that there is substantial difference between the way PLCs work and the way typical computers work. It's just a different programming language. In fact most modern PLCs can do just about anything that a Linux computer can do that would need to be done for basic control systems. These are also intended to be maintained and modified by Factory floor Personnel not by computer technicians and computer programmers.
 
To understand why ladder logic exists you need to understand the development and history of PLCs. They were designed to replace and modernize logic using actual relays. So the language was designed to look and work like the physical contacts and coils.

Triconex development software for their TMR SIS safety PLCs (SIL 1-3 plus Nuclear) only costs $1200 per system, has no copy protection and can be used on as many PC's as are supporting that system. Good value for money considering hardware and software is designed and tested to perform at those high safety requirements.

you get what you pay for
good luck
 
C
I never discounted the good points of PLCs. I have dozens of them running as well. And yes. you can do most problems either way. And PLCs are still very good for what they are good for. I think, at least in my case the problems have changed. And they aren't very good at integrating, except if you have the luxury of an all AB shop or an all Siemens shop. For example, I was asked to build a flexible conveyor system of about 30 conveyors with about half a dozen having side shift and the rest interchangeable. Not a problem, they each have a Click and an AB drive (two for the side shifters) and form a zero pressure accumulating conveyor system for doors. They feed a big sander and a flipper I built to send doors sanded on one side back around. Now we need to know which doors have only been sanded on one side. No problem, we use fluorescent labels and a fluorescence sensor. Oh, now
we've decided we need to track all the doors and work with the existing enterprise system. I read an RFID tag and send it to the database as XML, and it returns an XML record which I parse and send settings to the sander, it speaks RS232. The rest on the company Ethernet plant. Now, I suppose it is possible to write an XML parser on a PLC and send XML But, I'm not too keen on the idea. For $$$ and many months, the enterprise vendor can accommodate something the PLCs can grok, Oh and we want the queue displayed large and overhead in two places so the ops know whats coming. We could perhaps do this with automation gear, But it's much easier to put a pi in there and write import xmlparser or something like that. The Ethernet is free and it will drive any HDMI display from 7" to 75". And it has no problem with the RFID reader, and I can even run a camera to show alignment so one less person is needed. Everyone is happy and the hardware cost is real close to nothing. And I don't think the software took any more effort than it would take to learn the gear that an "automation" solution would require, And that stuff would not, most likely be "night technician" stuff to fix either.

Many of the Pi operate alongside the original control systems, collecting data, displaying information and easily circumventing the impossible task of actually integrating a multi-vendor shop as they seamlessly talk to each other and to the central database.

I'm interested in hearing what's wrong with this solution to a widespread problem. Except they don't follow the relay paradigm:)

Regards
cww
 
D

David Ferguson

I don't have a problem with using many of the numerous "open source" or modern IOT technologies. Using them for non life threatening (your mileage may vary) functions like, database management, data tracking, production monitoring etc (and I realize anything can be dangerous), is ok because lives aren't at stake.

Where I won't jump ship yet is on critical to safety machine control (again realizing this is a thin line). This equipment has been tested, proven and has a knowledge pool that is time tested. Some of the "internet" technologies have a 3 month lifespan and with less and less software testing, and real testing anymore.....makes me very nervous of the consequences of life and limb.....see the autonomous vehicle scenario I answered before.

I even struggle with things like Plant PAx blocks or DeltaV "global objects," and how using an object mentality we write blocks that can do "everything." And then build global graphical parent/child interfaces that the layman can "program" by clicking check boxes and relieves them of writing and usually "understanding" the underlying code. It can be very dangerous that with the click of the mouse on a checkbox, not knowing that you just made the machine dangerous.

I realize with less and less people who get it in the plant, that this is the way of the future....until someone gets hurt and we go back to having trained knowledgeable people on site.

My argument forever on AB or Siemens or the big players is one of risk management......they have more to lose so they are invested in the longer term aspects of it.....but of course that comes at a price. In my book I feel more comfortable around high end robots when I understand their background versus cobbled (I don't like that word) cheap (I also don't like that word) Systems that saved my company a buck. If they have to survive by cheapening their safety and control, I don't want to work for or around their equipment. But then again I have that luxury.

Dave Ferguson
Control Systems Engineer
 
>>>My question is simple, but the answer escapes me. To all
>>>you devoted Allen Bradley people and to everyone else who
>>>uses PLCs, why do you pay for their programming software?

value is defined differently from user to user. The infrastructure (support, education, etc) for manufacturing is based on the PLC. Will probably stay that way until manufacturing techs go to school for Computer Science.

>1) The majority of the AB devices and software seem to be
>hampered by complete disregard, acceptance or appreciation
>for well defined computer science programming standards like
>regards Linux, C++ and Python used by Arduino and Raspberry
>Pi. I suggest they get subscriptions to IEEE Spectrum,
>Computer and Communication.

Version control of PLC software is handled differently than Java, Python, MS-VStudio. Java 1.2 projects don't migrate cleanly to today's Java. Python 2.7 to 3.x isn't the same. I deployed a system with PLCs communicating with MS Visual Studio Tools for Office and Excel '03 in 2006. Machine is still running and probably will be for another 5-10 years. I warned against this when we designed it, but lost the fight & today we are dealing with minor issues we shouldn't have to deal with related to PC OS, and MS-Visual Studio/VSTO.

I didn't buy into it (for no good reason), but my guess is some on this forum used a Windows CE device for machine control circa 2003 or so. 10/15 years later it'd be interesting to quantify the risk of those deployments relative to the life of the machinery.

>2) Ladder Logic, Structured Text & Function Block look as if
>they might be programming languages that have been purposely
>disguised in the name of remaining special and proprietary.

Maybe that's a side effect. PLC IDE's logic objects might seem to have rigid rules because that's the nature of machine control.

>3) Most AB Control Engineers seem to pride themselves for
>not being or wanting to be programmers. Remember, for
>generations lots of discrete hardware designs have been
>sucked into software.

I don't see that- most of my colleagues consider themselves machine control programmers who are capable of marrying up discrete/analog/process control, motion in lots of flavors, and HMI/UI. To do it in such a way that's easy for the user of the machine to do their job is part of the programming challenge. Operators are rarely shy about letting you know the machine you designed/programmed is too hard to use. This often negates clever software gymnastics of poorly planned code that the not-a-programmer has built their system around. Seasoned machine control people plan their code efforts like any good programmer in non-machine control disciplines.

Side note: good machine control programmers I know (and learn from) put all the bits/bytes in the right place and plan the UI well- but they also understand good machine practices, which requires aptitude with Physics, motion, safety and timing. Applying software tools to complicated machine dynamics is a skill. This makes them quite formidable & talented programmers.

>Are AB automation technicians and this AB PLC automation
>industry really feeling threatened by the progress made in
>computer science? They seem to be mostly electricians
>unhampered by this progress, and proud of it!

No. Techs are charged with keeping machinery running. Designers are charged with making a system that stays up & running at the required production rate. Both keep machines safe to run. Being "leading edge" comp/sci isn't a focus or priority to managing equipment up-time.

Unlike 25 years ago when I first touched a PLC, there are also many really good options in PLC software and hardware. AB isn't the "only option" for deploying a sound PLC/Motion based system.

>I am sure a PC, Linux and Open Source style revolution is
>just what is needed and it is starting to happen.
>Approximately 1,000,000 Raspberry Pi are being produced
>annually, and 500,000 of these devices are going into
>industry. And don't think for a minute that the
>Arduino and Maker movement are not actively looking at this
>situation. It pays to remember also that Linux rules the
>internet and makes it possible - Amazon, Facebook, Google,
>etc, etc, etc.

there's a place for a lot of that. Few will argue that PCs have a place on the plant floor doing something. PC control when done right has a place too. R-Pi's (imho) do not if for no other reason than the SD Card holds the OS. Maybe SoM's like the Samsung Artik or MS Azure Sphere will find their way into the factory floor as embedded devices- but not as user deployed control platforms. They don't address the same issues of roll-your-own PC Control, which include version control of the OS/IDE, management of the hardware and software for the life of the machine (plan for ~20 years minimum), capacity for internal user support, safety, and general acceptance. PLCs address those items well.

I am in the middle of a project using the CTC Incentive (there advertising is usually on this site) which is their PAC Logic Engine for one of there controllers executing on a PC Core with Ethercat to field IO and Motion. This makes sense because it addresses a lot of what I consider to be the shortcomings of PC Control and still lets me use a PC for some of the functions where PC's shine (minimizing exposure & risk of PCs/IDEs and O/Ss). Just about to start coding and looking forward to it. Maybe options are not just PLC v PC only? (imho) I think more suppliers will see the opportunity of offering some form of hybrid that addresses longevity, stability, security, and control with a higher level of I.T. flexibility for non-machine control functions that are required (recipe, batch/lot tracking, MQTT, whatever).
 
R
Designing software is an expensive endeavor, and maintaining and upgrading it a continuous expense to those designing it. Not only is it the heart and soul of process automation, as a maintenance technician good software is the best troubleshooting tool I have. No one makes automation software and hardware easier to use and maintain than Allen Bradley, though I have no problems with GE Fanuc. Automation Direct is ok, but not nearly as user friendly. To complain about having to pay a software license fee is no different than complaining about having to pay your vehicle registration year after year. If your company can't afford to use the best, then your company will always be in this position of being unable to afford what it needs to thrive. Think of it as an investment in your companies growth an expansion, because that's what it will help you do.
 
C
>If your company can't afford to use the best, then your company will
>always be in this position of being unable to afford what it needs to
>thrive. Think of it as an investment in your companies growth an
>expansion, because that's what it will help you do.

The people I work for seem to think they have the best, that's what they pay me for. The best isn't necessarily expensive. And the best may very contain elements where big automation is abysmal, like multi-vendor plant wide integration with enterprise systems and up to date technology. It's a fatal mistake to think that by paying the most, you get the best. Even with people, who make a lot more difference in what you end up than which hardware vendor you bow to. Lately, a lot of what I do simply couldn't be done at any realistic cost using any of the usual suspects in big automation. But, back to what PLCs can do.

I would agree that AB with RSLogix was perhaps the easiest. But they are fixing that. The recent trend for enormously bloated "all in one" programming tools has been a great leap backwards in ease of use. And some have never _considered_ ease of use as a factor at all and their products are some of the most expensive. They are the EU favorite although patently un-intuitive. As the tasks to be done evolve, these guys all concentrate on making the most profitable buggy whips rather than accepting that people have expectations that everything should work together without proprietary barriers. That IoT is a far better model going forward than "islands of automation". Soon, the "best" might not involve PLCs except for trivial systems. And to thrive might very well require far more flexible approaches than walled gardens of the expensive, outdated, embedded hardware sold as PLCs. And I like PLCs. I just see the writing on the tablet.
 
D

David Ferguson

Well 15th year of Curt predicting Rockwell’s death and apparently now the plcs death. Let's add Windows for control and we have a trifecta of old predictions.

I have used Rockwell products for 30+ years and I have heard these tales of woe for years.

I for one like and use the new Studio 5000 daily.....I build and have built numerous "objects" AOI and Global Objects to do just about anything you can think of. I have talked to just about every kind or proprietary system out there.

And because these tools are integrated together (if you take the time to read the manuals) you find that you can build large libraries of these tools and you can automate bulk building of all your code, graphics, historian tags, alarming tags etc. all with a free tool from Rockwell ACM Application Code Manager (one of the bloated additions :p)......

Yesterday I wrote the code for 450 motors and generated all the code and graphics, alarms and historian tags in 123 seconds (yup you read that right) .....all the code commented, tags built with tested library objects.......motor control, interlocking, permissive, runtime monitoring and alarming

Again as I have said many many times on this thread......I don't mind that my tools are expensive......Like any good old world craftsman, the best tools are expensive but serve you well, the trick is taking the time to learn them and to earn with them....

As Robert Martin says in "The Clean Coder"...."Your career is YOUR responsibility. It's not your employers to make sure you are marketable. It's not your employees responsibility to train you or send you to conferences or buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer."

Every single manual for every single product is available for free online for just about every vendor.......but you have to know how to read. I had a young guy ask how he could learn our Provox DCS.....I said go up to the control room, go in the back and in the second file cabinet, third drawer is your answer.

He came back with a perplexed look on his face, I asked "what did you find"...he said "a bunch of manuals still wrapped in their shrink wrap"........I handed home a pocket knife and said "break the shrink wrap, it's your chance to be the expert...it's all right there" and he did and still thanks me years later.

I find all the tools are out there to learn just about everything no matter its price....just go on YouTube and enter search for any and all Rockwell products.

I hope I'm wrong but my guess is Rockwell, Microsoft and the PLC will last longer than I will.......and I'm hoping to last a long time.......

Dave Ferguson
Control Systems Engineer
 
C
Hi Dave

I don't disagree that Rockwell, Microsoft, and PLCs will outlast us. After all, I still know of plants with pneumatic controls and even relay sequencers and tube op amps. But that doesn't mean change hasn't happened. And the changes I'm concerned with are actually happening faster than I expected and accelerating. You're using Linux or BSD every day, and it outnumbers Microsoft (Android is Linux and I phones are BSD). You would have thought that impossible 15 years ago. PCs are becoming obsolete. What does that look like for MS? You can't possibly have missed the changes that have occurred in automation and the big made small and the names, now only names. No arena has more obsolescence but longer dwell time. I think it's a bad idea to bet against change, but we are safe until retirement.

Written on a new $35 computer:^).
 
D

David Ferguson

My point would appear to be some zealot for the big names Rockwell, Microsoft etc. Nothing could be further from the truth.

My JOB hasn't really made what I consider a technical leap in 40 years.....I still turn motors on and off and move a valve to control a flow. Did it years ago with pneumatics, then stand alone controllers, then big dcs's and then pcs and now virtualized pcs.

I gather more data to analyze etc, I can point out more motors faster and tell you why it didn't start and when it needs to be worked on but none of these are what I consider a leap for mankind......Maybe the microchip...but it's not free fusion energy or real AI or the invention of electricity.......

Companies have been able to reduce humans because these tools have made it more efficient to do the same old crap. So the tools have gotten more expensive as they have absorbed the work that 50 humans did (substitute value here).

My dad was a draftsman and fought the changes from a drawing board to CAD. Yet fundamentally, the only change was his office with 40 draftsman was reduced to 2. But the tools cost way more for the 2. Change in technology like the invention of electricity.......nope.

He carried a pocket full of recipe cards, with his important phone numbers, want ads cut out of the paper taped to them, birthdays, to do lists, all behind his pocket protector full of pencils and pens. He had a phone on his desk, a paper phone book that was sent free, and adding machine, a drawing board, a stool and mechanical pencils (don't get me started on technological change), a blueprint machine etc etc.

I progressed and had a pda and a flip phone and a 40 pound "laptop" .........today I have a $1000 iPhone. it is my phone, my gps, my contacts, Craigslist, access to any question I want, calculator and on and on.....can I buy a $700 phone or a $300 phone......sure, doesn't matter. Is it a technological wonder that has changed what I accomplish as compared to what I accomplished 10-15 or even 30 years ago.......not really. I do it faster and more efficiently and it might have reduced some humans that had an expense that is now traded for its expense.......but change mankind as a giant leap in what gets done......I (only I) don't think so.

It's just a tool to get a job done, use the tool to discover life by traveling to distant galaxies or find cures to cancer, or invent free energy ...... these are game changers to me.....versus arguing over the price of a tool. I joke that I spend a ton of time automating crap so that just when I get to the part where I can add value by mining all the data I have gathered that wasn't available 40 years ago........they send me back to start all over again because I can do it so efficiently.....trapped .......and never allowed to find the life on the next planet buried in the data.

Dave Ferguson
Control System Engineer and
CTU - Chief Tool User
 
Nobody generally predicts ahead of time what the next big disruptive technology will be; who saw the iPhone and the rise of "Apps" coming? Even in relatively narrow fields like controls, where the barrier to entry for new vendors is huge, it wouldn't take much for a disruptive new technology to change the landscape virtually overnight. While all of the controls vendors plod forward with incremental improvements to processing speed, tools, and algorithms, somebody starting from scratch doesn't have the legacy products and existing ecosystem hanging over their heads. That is a huge advantage! Is it enough to overcome the advantages of the entrenched controls platforms? Familiarity, consistency across fleets, spare parts inventory, availability of experts, and patent protection are hard to beat.

I don't think a small startup or open source platform has any hope; this isn't silicon valley with 3 month product lifecycles and a fail fast and often mindset. Fail at controls, and people can die.

I do see a big player in an adjacent space having the resources to succeed in controls. Maybe they invent something disruptive in-house, but more likely a company like Apple or Microsoft buys an IoT startup that loosely overlaps controls and expands into the traditional RTS digital controls space.

Microsoft to me seems well positioned for it. They have the tooling expertise to revolutionize the devops experience for controls software, industry wide recognition, the resources to invest and establish standards, and a total embrace (albeit recent) of open source that should allow them to build trust at both the high end corporate and hobbiest ends of the spectrum. They also are key researchers into two of the most disruptive technologies I see on the horizon: AI augmented tools, and quantum computing. They are also have a good (IMO) edge computing stack and cloud IoT platform that complements well traditional controls.
 
>As a business owner and consumer of these devices and
>processes, I prefer a scaled approach as proposed by Mr.
>Wuollet.

This is what we decided to do when designing our controller. Focus purely on process applications, no modules and no support for drives. Sensors, valves, pumps. Third-party integration with common protocols (MODBUS, OPC). Protocols and programming software do not cost extras. In the approach that was selected, the system has to be more open for the developers, more flexible in the implementation, and convenient in use.
 
Top