Disruption in the Automation World, and a practical PLC Code Generator to get started

JesperMP said:

Ugh, S88 (**shudder**).
I have seen machine projects made with essentially S88, and it is not good. Maybe good for batch processes.

In the sample project on github there is a file "fds_example.docx" with a listing of steps and transitions. There is only one "next" step. It looks to me as a kind of SFC.
I would prefer a genuine state machine rather than SFC.

So, am I wrong that this essentially is an automated tool to generate SFC code based on descriptions in Word or Excel files ?
If so, I guess it is an OK tool, but hardly disruptive.

Click to expand...

Yes good remark about the state machine!

So S88 is basically state machine theory applied to a process plant, and it was designed mainly for batch process.

My example is not limited to having one possible succeeding state: see step 970 where it can transfer to two different states, albeit indeed only one at the same time. Which is also a true state machine.

I had the discussion with two very experienced machine programmers.
They both programmed mostly state-based. One important requirement for them was to have the ability to go from one state to two other states that run at the same time. Which would not be a big change. Just make the target step a list of steps instead of one number.

Is this what you mean?

About the 'Disruptive': that's about our industry being up for a change. A technology or solution is only disruptive if it ends up changing the market.

Just a comment on using Blackberry and Blockbuster as "disruptive technology" examples. While it's true that they were disruptive in their time, you might want to pick some examples that haven't gone belly up and left a lot of people holding the bag...

AustralIan said:

Are you proposing to skip steps 2 through 6 of this?

Click to expand...

So that's indeed the V-model, mostly used in used in pharma. Other industries are also adapting it but a bit less heavy on the documentation and verification.

What I propose is to replace any coding that's repetitive.
Which is step 4 in your figure, and what my demo is about.

Additionally I propose that the industry moves to automated test-suites for wherever it makes sense in the right part. I've seen some companies making progress on that part. I would say 80% automated and 20% manual/supervised.

The left part should stay mostly as it is.

jraef said:

Just a comment on using Blackberry and Blockbuster as "disruptive technology" examples. While it's true that they were disruptive in their time, you might want to pick some examples that haven't gone belly up and left a lot of people holding the bag...

Click to expand...

I'm using them as examples of where another technology disrupted their market.
Blackberry => Smartphones (Apple and Android)
Blockbuster => Netflix

JesperMP said:

I think he wants the "coding" part to be fully automatic.

Anyway, this is by no means "code that writes code".
This is a "use a template system to gather input that is used by a script for code generation". It is still humans that fills in the template with information.
The advantage is that you dont need to sit with a specific PLC coding software to do the inputting. And you dont need special programmers to do conversion from human input to PLC code. And you can in theory switch PLC types easily.
The disadvantage is that there will be no super-generic template that can be used for just any automation task. The template that works with one kind of industry will not work for another industry.

Also, debugging. Going back and forth between 2 systems will not be good for debugging.

There has always been tools that are supposed to enhance the productivity of coding, or let "anybody" do coding.
But a tool that is good for setting up SQL databases, may not be good for writing the next minecraft, or for creating an efficient graphics editor, or for creating the next whatsapp, or ....

Click to expand...

Yes agree that there will probably templates that focus on certain industries. This is not as big as it sounds. The team that is using this on an actual project does both Chemicals, Pharma and Food projects. Their template can already handle all of that. You could probably have about five to ten example templates that already cover 80% of the use cases, maybe more.

harryting said:

Various attempt at this has been tried. I was involved in one of those. It ended badly

It ended badly because intentionally or intentionally blindness to the reality of automation world by good folks who doesn't try to understand our industry. The one I played with can generate logic for AB 500 but it generated such huge amount of ladder it easily overwhelmed the processor memory. It also doesn't support online-editing. Which, in the real world, is critically important.

Someday, this will all be null with Singularity but we are not there yet.

Click to expand...

Yes this can't be built by people that have not built up a considerable experience in programming actual controllers, and also have spent a lot of time in the field commissioning them.
That's probably one of the reasons why there's not a good solution yet.

About the generated code: to make it work it should look almost like it's programmed by hand. It will be a little longer because it will be very structured, but if the difference is too big then the solution should be revised.

And something a very experienced programmer told me when I just started: "Prioritize programming for readability, not for compactness".

EdStevens said:

What I propose is to replace any coding that's repetitive.
Which is step 4 in your figure, and what my demo is about.

Click to expand...

Ive actually wrote repetitive code for micrologix plcs using my scada software.

I know other people have developed excel worksheets to write code for contrologix for repetitive stuff like alarming.

The "ladder" answer to repetitive code is using indirect addressing.

dmargineau said:

Functional automation open source software cannot be implemented without open source automation firmware.

An automation controller is not and will never be a consumer class Android device.

There is too much at stake and a great many resources had been invested in order to maintain the current status quo for generations to come; Apple anyone?

I remember Siemens' attempt to bond with Windows; Stuxnet anyone? As soon as they found out the virus' "modus operandi" new "highly-secure" firmware was pushed across all platforms.

I believe there is a disconnect between some amateur futuristic universal approaches and the professionally known current possibilities......

Click to expand...

Ok so there are some developments in the market.
The first is that smaller to medium players are massively adapting a shared IDE like CoDeSys. (Although still often with closed firmware and not branded as CoDeSys)

Secondly some serious players are experimenting with allowing linux to run in a part of the controller. Examples are Bosch Rexroth, Yokogawa and I heard from Rockwell representatives they will also release something similar this year.

On the other hand the big players like Siemens and Rockwell, and the entire DCS world are not interested to move. But even for Siemens they just anounced that their new TIA will support full import and export, maybe even for PLCOpenXML. For them that's probably because they want to integrate with PLM workflows.

I think there's big opportunities both on the short term without having to wait for the vendors to change their technology (see my example) as on the long term where indeed firmware will become open and hardware will become a commodity.

I've been part of companies that auto-generate a lot of 'base' code for the process industry. Relatively easy to handle repetitive code as long has you have standard methods to do so. Excel + VBA can do quite a bit for you.

The problem I see, especially in the process industry is the best you can do is 50/50, maybe a bit more if you have really standardized your program features and stand firm with the customers that you aren't customizing anything.

Unfortunately, things ALWAYS change. The P&ID gets changed, change orders come and go, the installation of the system changes for some reason, the mechanical design is flawed, the system has a bunch of unknown unknowns that you don't find until commissioning.

Automation of repetitive = good, trying to automate the process = bad. Mainly because if you automate the process logic, and you have problems how do you even know how to fix it? You basically dumb down Controls Engineers and when it's time to write code to make things work because the automated process broke down....people are lost. I made this argument with a few engineers who wanted to automate as much as possible w/o thinking of what happens when someone is onsite and has a problem the automated system cannot fix. The lack of understanding of how to program the process logic means nobody has a clue.

One company I was with had a 'great' idea to develop a .NET application that handled all the "S88" control functions. In theory a good idea, in practice not so much. It wasn't flexible and didn't account for all types of control, when there was a problem nobody could fix it, had to wait for the guy who developed the .NET application. Touchscreen - Nope, Database setup - nightmare, Terminal Services - Didn't think about that one....list goes on.

I agree with comments about the IDE, continually improve that and things will naturally improve.

mk42 said:

I agree with most of what you said, and I love your optimism. It IS the way things are going, sooner or later. I think you're right that this is a topic that many have tried, and the results are either failures or kept secret. I've heard Siemens talk about Automation Designer practically since I entered the industry, and it always seems to be JUST over the horizon.

Click to expand...

I think they're integrating it in their PLM solution. Talking about that: I just saw a screenshot last week where they also seem to be working template-based. I'll see if I can find it back.

Paully's5.0 said:

The problem I see, especially in the process industry is the best you can do is 50/50, maybe a bit more if you have really standardized your program features and stand firm with the customers that you aren't customizing anything.

Unfortunately, things ALWAYS change. The P&ID gets changed, change orders come and go, the installation of the system changes for some reason, the mechanical design is flawed, the system has a bunch of unknown unknowns that you don't find until commissioning.

Automation of repetitive = good, trying to automate the process = bad. Mainly because if you automate the process logic, and you have problems how do you even know how to fix it? You basically dumb down Controls Engineers and when it's time to write code to make things work because the automated process broke down....people are lost. I made this argument with a few engineers who wanted to automate as much as possible w/o thinking of what happens when someone is onsite and has a problem the automated system cannot fix. The lack of understanding of how to program the process logic means nobody has a clue.

Click to expand...

The team that is using this is now reaching more than 90%. The other 10% is making customized FC's and FB's for specific functionalities, for example interfacing with the MES.

And the change requests are amazing at this point: they indeed keep coming and it's just a matter of changing the documents and the entire program is immediately updated.

You have a good point about dumbing down control engineers: you want them to be involved in maintaining the templates, and make sure they understand where the important parts are. It's something to keep in mind but not unsolvable.

Epy said:

The idea of automatic code generation is much more difficult than you think, for many reasons.

Click to expand...

Since when is something difficult stopping us engineers to come up with a solution?

AustralIan said:

Going through your github, it looks like you are essentially writing another IDE for programming PLC's. This programs using syntax that I will have to learn. Is this syntax any better than the syntax in the existing IDEs? Is it any better than the tools for generating code/parameters in existing code? Not yet, but there is potential.

Click to expand...

It's not an IDE, but rather an API.
It is both open and customizable.
Do you have to learn the API to use it? Yes, but everything is switching to API's nowadays. I never heard anybody complain about having to learn an API of a valuable service.

AustralIan said:

The reason in pharma there are so many steps is to pick up problems at each of the stages. Ideally each stage will be handled by a different person. By automatically converting the output of the software design stage to the output of the code stage, you are doing what many other industries do and reducing the number of stages. This is fine and cost effective but there is a belief that it is more prone to errors.

Click to expand...

Not sure how automatic code generation can be more prone to errors, once the generator and template have been validated. Humans can program something 1000 times correctly, and then make a mistake on the 1001th. The generator never fails if the first time is correct.

Additionally you can iteratively reduce errors, and build in protection against past errors. Humans will keep making the same mistakes, it's only the frequency that goes down.

AustralIan said:

But what you are doing is worse because you have to code in ms word, rather than the myriad of IEC61131-3 IDEs.

Click to expand...

It's not really code, it's rather a convention of how to describe actions, transitions, ... . The people using it are actually happy of having a convention because often they have no manual about how something like this should be written.

The only thing I really wanted to touch on was hardware. We totally need an open-source PLC hardware design, but the problem with this is there is a certain legal liability for the loss of profits, life and limb that would need to be taken care of. You bet your sweet hiney that AB has liability insurance for their controllers in the event that they malfunction due to workmanship and hurt or kill someone. If a company is open-sourcing a hardware/firmware pair then what about the liability issue? I also understand how difficult it would be to make something like a PLC. I'm a fan of the RSDeveloper IDE. I think it is very powerful and fairly easy to use due to all of the preset instructions, but when it boils down to it the ladder editor is just a compiler for their program, and that also takes a significant amount of work for it to work and work well. I think those are the main reasons we don't see any widely used open-source automation controllers.

I remember my boss telling me once that he "hates open-source." He is an older guy, and very intelligent, but also set in his ways. As we see this generation of management head out the door and start getting some newer people around that have been using open-source, we will start to see more growth in that regard. You know, it took about 30ish years before electric motors started being widely installed in factories for the same reason.

There is also the issue with open-source itself. The beauty of open-source is that you can make it do whatever you want it to do and nothing you don't. You could, for instance, make a word processor with an mp3 player in it to whistle while you work. The thing is, not everyone wants to use a word processor as an mp3 player. Another good example is the plethora of DE's for linux. There are a lot of good ones, so you can pick the one you like best. This is a great thing, but building something into exactly what you want takes a LOT of time, energy and knowledge. This all equates to complexity.

Using linux back pre-2000 vs today, there is a huge difference in usability, but when you simplify that you take away the freedom of choice, so there is a real balancing act there. This also complicates training. I can go to any computer with a copy of RSLogix installed and connect to any MLX or SLC and see what is going on inside providing I can read the STL, FBD or Ladder. This is incredibly powerful in the fact that I don't have to relearn a company's implementation of RSLogix.

Those, issues, I think are what really keep open source out of the automation market. Once a company modifies an open-source product to use in their product, they make their changes proprietary.

The liability is why one would make money on an open source controller.

If you use centOS, you pay £0 to redhat. CentOS lags redhat by about 5days, and all that happens is they take open source redhat and write CentOS in places and remove the photo of a red fedora. You are also responsible for the liability.

If you use redhatOS, you pay a licence fee to redhat and they provide certain guarantees.

So you build your open source safety controller. Want obligatory support and liability from the project owner? You bet we can give you that! Money changes hands.

And guess what. That guy that cares about his employees enough to use a safety controller but not enough to pay for a safety controller over a standard PLC? He can build his own from source.

And on taking an open source safety controller and modifying it yourself? No-one does that for critical redhat installations currently. They modify it, run it in a test environment and submit the change to redhatTM for approval. Months or less later, their feature is in the new redhat.

Same goes for the libraries of template code.