First of all, I agree with previous posts that open-sourcing is just saying that this code/hardware is not guaranteed to work, so removing the liability, which is not what companies want.
There are both advantages and disadvantages to open source. There is a general trend towards a bigger used of high-quality open source software, including in mission-critical applications.
And very important: open-source doesn't equal free: you either still pay a company supplying it, or you have to invest more in your own teams.
Also, just like Android is Linux based but is not really Linux anymore, open sourcing PLC is not going to propulse the industry in new territories, just create different vendors. And if cost is really the push for open-sourcing, we already have dirt cheap PLC's.
I don't think our first concern is having open-source PLC's. What we need are open PLC's with open interfaces and open drivers.
I use PLC's for machines, I never did batch mixing or process. So those are just my interpretations of the claims. I think this is just a case of bad design of a mixing plant
This kind of design / PLC program structure is the standard in batch-like control. I didn't invent it. See page 4-6 for a list om some companies behind it:
http://www.automatedresults.com/documents/S88-Batch-Standard.pdf
and some young smart engineer that came up with a clever way to fix a problem that can already be fixed with existing technology, without upsetting too much the current programmers way of working.
I'll take that as a compliment
Although I'm not that young anymore.
I don't understand the reason to be upset though.
The logical way to design a product, is analyzing your needs, and then choosing the right tools to achieve that. Not choosing your tools and then molding your end product with the tools your have chosen.
I presume that the specs for that plant were decided before the needs were established. Someone decided on PLC's even though it wasn't the best way to do batch mixing.
What do you propose then instead to do batch mixing?
A DCS is overkill for this application and doesn't add value.
Also the choice for PLC's has nothing to do with code-generation.
But even there I have doubts, couldn't what he is doing, be done by calling subroutines with parameters? Just like in C++ when you call a function, give it variables, and it will spit out the processed variables? We use subroutines for clarity, but really it can be a very powerful tool to process repeatable code.
I proposed this to my supervisor once when he tasked me to create code for a machine we were redesigning in-house. I told him we could have one subroutine that would handle ALL the motors. We feed it tags when we call it and it spits out the processed tags. Of course he was not very fond of the idea. Not being able to go to the specific ladder and watch the rungs troubled him deeply. I explained to him that with custom tags, we could group everything related to that motor under one main tag and we could see what was going on by watching that tag, and that the HMI would have all the possible faults anyways. He was not impressed, insisted that we would have to teach all the electrical techs how this functioned. I ended up doing a subroutine for every motor. Now I can only imagine if I had asked a group of programmers to do this...
Ok that's exactly how everyone works (or should work) in process industry: there's one FB for a motor type, another one for a valve-type, also control valve, PID, AI, ...
Then those FB's are called for each instance, while connecting the relevant IO, interlocks, phases, ...
Most experienced programmers already have automated code generation for this part. Or packages like PCS7 have specific tools for it.
The thing that still takes a lot of time is programming all the phases.
I think PLC's evolved greatly since address based programming and claiming that we program the same way we did 20 years ago is obviously coming from someone who didn't program 20 years ago.
Indeed I didn't: I started 17 years ago.
I might have missed the revolution in those previous three years.
Structured text is a perversion, don't ever mention those words.
How about Instruction List / STL?
Having an electrician background, I really do understand the stubbornness though. You can visualize the electrical flow from hot to neutral when you read a ladder, and literally see where the problem is. Not the case when calling subroutines with parameters or structured text or addons, or any other way than basic ladder. This one reason why basic ladder will prevail.
I do understand this. But that's a discussion of which language to use, not weather or not to use code generation because that's independent from the language.
Automation is fantastic a long as everything is working like intended. But when things go wrong, it's not the bright young engineer that designed the machine that will be troubleshooting the machine, it's the on-site electrical technicians, and like someone said earlier, they are very visual people. The code can be perfect, very compact, run the machine exactly like it's meant with absolutely no bugs, but when that sensor, cylinder, valve, etc fails, what happens? A bunch of coded text is not going to help your electrical tech... They need simple ladder.
Also here: code-generation can be applied to ladder. Has also been confirmed by other people in this thread.
The key is to have the ladder look very readable and structured.
I have seen many young engineers programming incredible things, like robots to go in hazardous locations, claiming ladder was dead but failing to answer simple questions like, what brand of PLC are you using and what language are you using because there were using a unified way of programming. And that project is prone to failure because its fine and dandy as long as everything is working, but when that part fails, you will be faced with compact computer generated code and no one will be able to fix it.
Not sure who's claiming that ladder is dead in this thread.
And generated code needs to be readable like it's written by a human programmer.
I have also seen software programmers claiming that they can program anything, and fail miserably and financially, trying to program a machine. As long as parts will fail, you will need electrical techs, and they will always need basic ladder because it's how electrical stuff is drawn. Software programmers see network switches, cat5 and stuff that can be programmed, and think "hey, I can do that, my computer has cat5 too!".
Where do the software programmers come in? Machines and plants need to be designed and programmed by automation engineers, not by software people who never set a foot in the plant.
What I do believe is that the new generation of automation engineers will need and have a skillset that includes software and modern development tools.
The push for change we are seeing in our industry to put our PLC's on the internet and bring in software developers to the PLC side is because there is a race right now, and that race is called IOT.
In case you don't know what IOT is, it stands for Internet of Things, it used to be called M2M but it was rebranded. Put simple, its connecting things that are not connected to the internet right now. There is a vision for smart cities. A store coffee machine can order coffee before it runs outs, have pollution sensors on streets, automated lights, such are the claims. I myself find it funny, street lights are already automated with 35$ light sensors... but just like when personal computers were invented, the usage claims were ridiculous... "you can do your grocery list with it", I might be laughing at the next biggest upcoming revolution.
That race is huge, every sector wants to win it, Cellular carriers are in it, PLC companies, most of silicon valley tech giants, on-line stores(yeah on-line stores) and there is of course the open-source community also.
So IOT is why we are seeing all those young engineers claiming there is a disruption of the PLC world coming up, because they are told so. There are forces trying to merge the two worlds or software programming and industrial programming because they want to win the IOT race.
I don't know where you look, but most people I see pushing for Industrial IoT are senior executives at Multinational companies.
And the push for IoT is only making the divide more obvious.
Also there are a lot of ridiculous examples of IoT, and a lot of people pushing it that have no clue what they talk about. The only thing that will matter in the end is how much value an IoT application creates for the customer, and if it's the best/most economic solution to realize it.
Model-based code generation does open up IoT opportunities.
An idea might be to automatically create a semantic model of the machine/plant and expose it over a secured API (like OPC UA) to other applications inside the company. Or take it a bit further and automatically generate the digital twin of the machine/plant. Or the model might be what defines the digital twin.
But that's something separate. The original idea of code generation stands by itself, nothing about IoT needed.
