Is the time right for a commercial PLC Programming Tool that runs on linux?

[Saffa]

LOL

The cost to design, develop, test and document software is constantly underestimated, in my experience.

What is the cost for one man month of a good programmer in the US?

Who still writes software in the US? You guys outsourced most of that years ago.

 

[Mark-]

Who still writes software in the US? You guys outsourced most of that years ago.

That is a myth. The myth gets massive press coverage because it feeds the narrative.

 

[Epy]

Sounds to me like you would be better off with a microcontroller or other embedded software solution rather than a PLC.

I would, but as part of a very small OEM, we don't have the money/time to develop/maintain our own boards and to get UL/FM approvals for an enclosed version of those boards.

 

[Epy]

Sample size: over 800 embedded engineers.

Hmmm...

800 is a fantastic sample size for confidence intervals, etc. Presidential polls have a sample size of 1000-5000 from the entire voting population, and there are a lot less embedded engineers than voters.

----

Linux and other *nix OSes are basically dominant everywhere except the desktop, for now. There are plenty of companies that commercially support software for Linux, and they eliminate the problems mentioned by only officially supporting certain versions of certain distributions, such as LTS/stable versions of Debian, CentOS, Fedora, etc.

I know my view of "everyone should support Linux" is idealistic and not realistic, but that's how I'll be, because it needs to happen someday. Windows is a steaming pile.

Food for thought: http://www.zdnet.com/article/red-hat-ceo-google-facebook-owe-it-all-to-linux-open-source/

 

[kamenges]

Originally posted by rootboy:

Linux, or a Linux derivative, is used in about 50% of embedded devices...

But we aren't talking about an embedded solution here. We are talking about a development application used on a PC by a class of users that are by and larges not software engineers. The issue isn't with embedded devices. Embedded systems are actually a great place of open operating systems. You can tailor the operating system to support what you need and jettison the rest. You also will be vetting the combined operating system, either modified or not as you see fit, and application running on it to make sure everything operates as intended. And by and large you don't have to worry about some guy loading any off-the-wall software on the system after you have it fully vetted.

The equivalent given the initial discussion would be like Rockwell releasing Studio 5000 with their own "vetted" version of Linux, with Siemens doing the same with Portal and Beckhoff and GE and any other company that delivers development software.

As far as supercomputing goes, I don't doubt that Linux would be the preferred OS for those systems. However, if you are investing in that kind of hardware you will also invest in the people who can support it in whatever form that support requires. That is a far cry from a small manufacturer with 20 or so employees and a copy of Step 7 that won't install or run.

As I said in my previous post, the likelihood of the OS being the cause of any given development install issue is pretty low. But to think that a supplier wouldn't fall back on that as the first excuse that something isn't working is just naive. Why would these companies willingly open themselves up to the possibility given the lack of push from end users?

Keith

 

[Mark-]

800 is a fantastic sample size for confidence intervals, etc. Presidential polls have a sample size of 1000-5000 from the entire voting population, and there are a lot less embedded engineers than voters.

Now that made me laugh.

I know my view of "everyone should support Linux" is idealistic and not realistic, but that's how I'll be, because it needs to happen someday. Windows is a steaming pile.

OK, nothing wrong with cheerleading. The pile part is...

As to the URL It is the opinion of one fellow. And he says "had it not been..." like something else would not have come forth and filled the need. This kind of statement is self-serving and taints the argument. Plus it is more of an advertisement for Red Hat than an analysis. My2c

 

[rootboy]

But we aren't talking about an embedded solution here. We are talking about a development application used on a PC by a class of users that are by and larges not software engineers. The issue isn't with embedded devices. Embedded systems are actually a great place of open operating systems. You can tailor the operating system to support what you need and jettison the rest. You also will be vetting the combined operating system, either modified or not as you see fit, and application running on it to make sure everything operates as intended. And by and large you don't have to worry about some guy loading any off-the-wall software on the system after you have it fully vetted.

The equivalent given the initial discussion would be like Rockwell releasing Studio 5000 with their own "vetted" version of Linux, with Siemens doing the same with Portal and Beckhoff and GE and any other company that delivers development software.

As far as supercomputing goes, I don't doubt that Linux would be the preferred OS for those systems. However, if you are investing in that kind of hardware you will also invest in the people who can support it in whatever form that support requires. That is a far cry from a small manufacturer with 20 or so employees and a copy of Step 7 that won't install or run.

As I said in my previous post, the likelihood of the OS being the cause of any given development install issue is pretty low. But to think that a supplier wouldn't fall back on that as the first excuse that something isn't working is just naive. Why would these companies willingly open themselves up to the possibility given the lack of push from end users?

Keith

What I was responding to was the culpability argument. I'd have to say that the folks over at Redhat takes things pretty seriously (well, ever since RH5.0, which came complete with a "Redneck" version of the installer ).

And I'm not a Microsoft hater, far from it. I would much rather develop on a MS box than on Linux. So in that regard, Microsoft clearly wins for me.

 

[kamenges]

Culpability may have been too strong a word with too much of a legal connotation for what I was trying to say. I didn't mean it in a litigious sense. I meant it in a blame-fixing sense relative to solving a compatibility issue.

I have run into compatibility issues between components from "big" manufacturers enough times to know how they would react to any opening on the development software side. You know the drill. Given two players, its always the other guys issue especially if it isn't something either have worked with themselves before.

Keith

 

[rootboy]

Culpability may have been too strong a word with too much of a legal connotation for what I was trying to say. I didn't mean it in a litigious sense. I meant it in a blame-fixing sense relative to solving a compatibility issue.

I have run into compatibility issues between components from "big" manufacturers enough times to know how they would react to any opening on the development software side. You know the drill. Given two players, its always the other guys issue especially if it isn't something either have worked with themselves before.

Keith

Yeah, but you get that with any OS. And keeping any two engineers from going in three different directions is nearly impossible.

I take the "render unto Caesar" approach. If it works better on a given platform, then use that platform. For example, you won't hear me extolling the virtues of Linux gaming anytime soon...

 

[mk42]

I think it's far more likely for PLC programming software to be embedded in the PLC itself in the future than for the manufacturers to switch to Linux. I don't know whether it would be a remote desktop/VNC type solution, or something more like HTML5, but that's the direction I see things moving. The major manufacturers store pretty much the full project in the PLC already, and lord knows that just about every AB programmer already makes the majority of his changes online.

Do I want linux support? of course I do. But for goodness sakes, lots of major manufacturers don't even support Win 10 yet, let alone anything out of the box. It isn't happening any time soon.

It all comes down to cost. Do you want the cost of the programming software bundled into the PLC, or separate? How much support is the software developer willing to throw at "other" platforms. OEMs, Integrators, and End users all have different expectations of those things.

 

[Toine]

I would, but as part of a very small OEM, we don't have the money/time to develop/maintain our own boards and to get UL/FM approvals for an enclosed version of those boards.

OK, that makes perfect sense indeed, I had not understood that correctly. My apologies.

I have not needed this myself so no detailed first hand knowledge here, but if I understood correctly then Wago has PLC hardware running Linux that you can work from yourself in software running on the OS in the controller. Programming in i.e. C/C++. You may want to look into that path, as you can use your choice of approved Wago modular I/O's.

E.g.
http://global.wago.com/en/products/new-items/overview/basic-page-2600.jsp

http://www.wago.us/products/compone...tem-ip-20-750753-series/plc/linux/index-2.jsp

 

[nmambre]

At this point of the discussion I think most agree that it is possible, but there need time and money to make it happen. Where does the funds come from?

My first hand experience, I've been involved in developing/testing a Linux based controller. It was funded by a state company (oil and gas industry). Based on the LP-808x http://www.icpdas-usa.com/lp_8081.html that already has Linux, the company went a step further to create their own embedded Linux version for the controller (with additional features like RT, support for PLC programming). It has some of the features mentioned in other posts here: Development programs in the controller, ISO to install Linux distribution or VirtualBox to install on PC with programming tools.

Even with those advances, field engineers had to be convinced to use the system, as it has new hardware, new tools, and even new OS.

Maybe the hobby market can push some development in the right direction, there is for example OpenPLC with PLC-Open Editor, for RPi, Arduino, PC's that could be used as starting point Those projects of course need a lot of work, but they could be used for simple controls, and get more feature rich.

 

[Epy]

Now that made me laugh.

Natural reaction to laugh at what you don't understand. Please explain to me how 800 is an insufficient sample size.

 

[Epy]

I think it's far more likely for PLC programming software to be embedded in the PLC itself in the future than for the manufacturers to switch to Linux. I don't know whether it would be a remote desktop/VNC type solution, or something more like HTML5, but that's the direction I see things moving. The major manufacturers store pretty much the full project in the PLC already, and lord knows that just about every AB programmer already makes the majority of his changes online.

Do I want linux support? of course I do. But for goodness sakes, lots of major manufacturers don't even support Win 10 yet, let alone anything out of the box. It isn't happening any time soon.

It all comes down to cost. Do you want the cost of the programming software bundled into the PLC, or separate? How much support is the software developer willing to throw at "other" platforms. OEMs, Integrators, and End users all have different expectations of those things.

Agree, already have seen this in a newer RTU that has an in-browser Lua editor. I could go for an in-browser solution instead, would be much easier than making client software on an OS anyway.

 

[Mark-]

Natural reaction to laugh at what you don't understand. Please explain to me how 800 is an insufficient sample size.

Double laugh. It has nothing to do with sample size or a lack of understanding. Perhaps you do not understand the humor at what you wrote.