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

I want to respond to the comments about the hardware side, and it not keeping up with technology.

If your process is working, and has minimal downtime why would you want to inject new, unproven technology into it.

"If it is not broke, don't fix it!!"

Just my two cents.

I'm not arguing for replacing things that are running well. The thing I'm asking if the technology we use for the upgrades or entire new systems can't be better.
 
About replacing the IDEs: apparently the Eclipse Foundation is already working on it. They even seem to be pretty far:
https://www.youtube.com/watch?list=PLy7t4z5SYNaQS1XZ8uiqqn0nNLi4qU-VW&v=1z3pxDngQG8

You probably want to be careful choosing this application at this moment because once you do you're stuck with it.
On the other hand it's open and you can just download it an play around.

Also the moment a big serious company (again for example ExxonMobil) starts switching succesfully to an open IDE like this (or another one) then it could go fast.
 
Being a "3AM Bubba" myself, I don't have much of an opinion either way.
It sounds like it might be useful to certain people.
I doubt that it would affect my job much, depends on how it's implemented. I only have about 17 years until retirement, and we generally stay AT LEAST 17 years behind the technology curve.
The biggest flaw in the argument that I see is this: How are you going to convince the people who hold the purse strings? They are the ones who make the decisions, not the electrical engineers.
If you can't show them how it's going to increase this quarter's profits, or how it will ultimately increase your company's market share and/or run your competitors out of business, then you're shooting blanks. Because that's all they care about, 1. This quarter's profits and 2. Increasing market share Period
Ultimately, you're asking companies that are in competition with each other to start cooperating with each other. I can't see that happening.
It's either that or find a way to leverage enough capital to start your own company, and gamble it all on the chance that you will be able to make a go of it.
Anyway, thanks for an interesting read, and good luck to you!
 
Great discussion.
I'm still young in automation and can only add from my limited experience - 4 years in one process industry, state-machine code, Siemens hardware/software.
And I was going from other side of the process that Ed described - from plant maintenance needs.
So most of the ladder code are already there, we are still doing on-site modifications in ladder and HMI.
Being familiar with open-source programming toolchains the things most negatively affected me were the lack of collaboration support in used software, absense of changes tracking system, absense of code testing tools, manually written specs that unpossible to keep in sync with the code.
What we did were:
- extract all ladder code blocks out of Step7 project and put them under version control- done and good by itself
- write some docgen tool to build specs from saved ladder code - partially done and promising

And already at this early stage the next question come - we need some more strict rules to how specs have to be written.
Ideally one tool or format that is used at first stages of defining specs before coding and at the last one when rebuilding documentation from running code.
In that case we can clearly compare the both.

It's not an IDE, but rather an API.
It is both open and customizable.
...
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.

Exactly

Are you inferring that the development environment you are proposing could be used as an active troubleshooting tool; that is, the plc state would be displayed in an active copy of whatever you use to define the process? That would be pretty useful from a troubleshooting standpoint, I would think. Especially if there was an active link to drive the actual lower-level programming environment to the program section of interest.

Keith

It is not a question addressed to me but something like this was in my vision about the application I've started to implement now.

Thanks again Ed for bringing this discussion and sharing the project.

Dmitry
 
What we did were:
- extract all ladder code blocks out of Step7 project and put them under version control- done and good by itself
- write some docgen tool to build specs from saved ladder code - partially done and promising

And already at this early stage the next question come - we need some more strict rules to how specs have to be written.
Ideally one tool or format that is used at first stages of defining specs before coding and at the last one when rebuilding documentation from running code.
In that case we can clearly compare the both.

Dmitry

Interesting!

- How do you extract LAD from Step7? Don't you first have to export to STL? Or did you find a better way?
- Do you use git for version management? Any specific software?
- How does your docgen tool work? Do you plan to make it open?
- About the specs: that's part of the API that I'm defining. Could you share where you are with this? I assume big parts should be similar.
 
- How do you extract LAD from Step7? Don't you first have to export to STL? Or did you find a better way?
Currently it is done with Command Interface to Step7. It converts LAD to STL when writing the file
- Do you use git for version management? Any specific software?
Yes, with separate custom filter that reformat diff accepted from git to show the diffs by network
- How does your docgen tool work? Do you plan to make it open?
PEG parser is used to extract logic from stored STL code. Then extraction is stored in json format from which the html presentation of the spec is constracted.
My employer might disagree to open.
- About the specs: that's part of the API that I'm defining. Could you share where you are with this? I assume big parts should be similar.
The format was established long before me and I do not have any reference to existent standarts on that. But it is very similar to what you used for code generation.
I'm getting the specs as output and the key point is to fill steps and transisions tables fully and consistently.
 

Similar Topics

Hello, I have an automation direct d2 262 plc and C-more HMI EA9T6CL-R. I need to prepare a program, scheduled to be performed on a future date. I...
Replies
0
Views
1
Hello all- I have a unique challenge using a customers Direct logic 06 PLC. This customer has a DC motor operating at 10 RPM which is turning a...
Replies
1
Views
84
Hi, I have been trying to run drive via Sysmac studio. I can ping the drive. I can see the logic bits going on/off as per command. But, drive is...
Replies
21
Views
443
Hello Guys, I am using 1769-L36ERMS PLC by Rockwell which doesn't let me MOV or COP literal text into string datatype? i very well know the...
Replies
13
Views
350
Good Afternoon , Does Rockwell Automation have an Input Card , maybe in the 1734 series , or CompactLogix series that will receive signals...
Replies
15
Views
774
Back
Top Bottom