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

This becomes a case of chicken and egg though. If there's no automation software that runs on Linux then of course I am not going to use it.

But if it was available then I certainly would.
Exactly!! The reason that I'm using Win7 is that the software I need won't run on Linux without using a Windows VM. đź“š
 
This becomes a case of chicken and egg though. If there's no automation software that runs on Linux then of course I am not going to use it.

But if it was available then I certainly would.

OK, supply the funds to develop the project and you will get what you want.
 
All of the above, using cross-platform libraries/frameworks. wxWidgets for example, offers all listed here:...

That is assuming:
#1 You want your project based on Python, nothing against Python
#2 You do not have an existing code base in some other language that would need to be ported at $$$.
#3 You want to base your project on an open source foundation.

The idea that commercial programs should be on Linux because I like the OS or more, I do not like another OS is not going to convince the folks putting up the money, to put up the money.

I think programs running on some flavor of Linux would be great. Will I invest money in it (I also have bills to pay), no.
 
That is assuming:
#1 You want your project based on Python, nothing against Python
#2 You do not have an existing code base in some other language that would need to be ported at $$$.
#3 You want to base your project on an open source foundation.

The idea that commercial programs should be on Linux because I like the OS or more, I do not like another OS is not going to convince the folks putting up the money, to put up the money.

I think programs running on some flavor of Linux would be great. Will I invest money in it (I also have bills to pay), no.

#1: No, wxWidgets is C++ with bindings to many other languages, one of them being Python. That's only one example of a cross-platform GUI toolkit though. There are many others, like Qt for example.
#2: Almost all languages have the ability to interop with other languages.
#3: That is a risk, but so is basing your application on a company's proprietary API. The risk is that someone else maintains it and may stop at some point, not that it's open-source.

The value proposition for Linux is not *only* that I like it more, it's just that -- the value.

The Linux desktop has come a long way. Many of you have probably tried it in past years and been disappointed. But right now, it's very good. If you were disappointed in the past, you should try it again to see how it's improved.

But anyway, the value:
1. Can run on older hardware and still be faster / more responsive
2. Free software that you can load along with it, such as LibreOffice (to replace M$ Office)
3. No Windows licenses to pay for or deal with
4. More secure and/or not much malware out there for Linux, don't have to pay for commercial antivirus or worry about this as much
5. blah blah blah, ranting now
6. in general, a lot less BS to deal with
 
Hello,

>wxWidgets

You are correct. I have only seen it discussed referring to Python.

OK, let us stipulate everything you state is true. It does not move the needle one millimeter.

If money was to be made by creating products for Linux, more people would be producing products for Linux. That more people are creating commercial products for Linux, does not move the needle. The automation market, while large, is a tiny portion of the market share any OS occupies.

The chicken and the egg analog is flawed. The idea that if you build it they will come is specious. Someone has to be first. If not for free, the money has to come from somewhere.

Companies that create software, at least all the ones I have worked at, frequently evaluate expanding the product by supporting as many platforms as possible. It is expensive. ROI must be possible for companies to take the chance.

I am not against more Linux. I was playing with Mint and Debian flavors last month.

Can AB/Siemens/AD/Omron/Mitsubishi/etc. justify the cost to support Linux? I posit, if possible it would be done.

My2c.
 
Epy, I hate to do this on a Super Bowl Sunday, but I need to drag you out of Utopia and back to Earth for just a little bit.

The issue is neither technical nor strictly financial. It is an issue of culpability. Assume you have issue with your development environment running on Linux. If I were the developer of the development environment my position would be that you as the end user need to prove to me in whatever way possible that the operating system you are running has not been modified in any way relative to the operating system the software was developed for before I would start looking into the issue. We all know this is probably silly. Most end users will not modify an OS even if they could and even if they did the modifications would most likely not affect the development environment causing issues. But that doesn't mean the position wouldn't be taken. I can't even get AB and Parker/SSD to even look at a comms issue between them even though I can consistently repeat it. What do you think would happen if I had a development environment issue with something runing on a platform that MAY NOT be what it was developed to run on.

Those of you who have seen enough of my posts know that I am just enough of a cowboy that Linux based systems would appeal to me. Performance trumps almost all else in my books every day and twice on Super Bowl Sunday. I also know that there are enough stable Linux implementations out there that stability really isn't much of an issue. But I am also enough of a realist to know that most companies will not just abandon 20 years of relationship and development for what is effectively a parallel path. Many of the bigger players in plcs are tied very deeply into the Windows environment with their development packages. Until Linux makes a much bigger push into the general commercial market I don't see any movement from the big plc players to jump into it from a development environment standpoint.

Keith
 
Fat chance they ever will unless Linux becomes as easy for the end user as windows is.

I have been using Linux as my home OS since '96. If we were back in the '90s, I'd have to agree with you. But these days it really doesn't get much easier than Linux for installation and use.

I only boot into Windows for things like doing my taxes, and 3D printing (and curiously enough, to load my Amiga emulators). That's about it.

As an upside, the influence Linux has had on Microsoft has been amazing. Who would have predicted that MS would be giving their operating system away 10 years ago?
 
#3 You want to base your project on an open source foundation.

Nowhere does it say that you have to use the GPL (or any other Open Source license) to create or run your application on Linux. You just can't use other people's works as a basis for your own without providing the source code.
 
I do. It's called annual software support.

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?
 
I'd like to see things go a step further than simply bringing existing PLC programming applications to Linux, would like low-level access to PLCs similar to how you can with hobbyist boards. I'd like to be able to load FreeRTOS or otherwise directly into the PLC and handle communications and everything myself. Most will say that we have ladder logic and IEC languages so that everyone can play nice with each other, but I work for an OEM and am thinking along the lines of very custom programming for my application.

Sounds to me like you would be better off with a microcontroller or other embedded software solution rather than a PLC.
 
Epy, I hate to do this on a Super Bowl Sunday, but I need to drag you out of Utopia and back to Earth for just a little bit.

The issue is neither technical nor strictly financial. It is an issue of culpability. Assume you have issue with your development environment running on Linux. If I were the developer of the development environment my position would be that you as the end user need to prove to me in whatever way possible that the operating system you are running has not been modified in any way relative to the operating system the software was developed for before I would start looking into the issue. We all know this is probably silly. Most end users will not modify an OS even if they could and even if they did the modifications would most likely not affect the development environment causing issues. But that doesn't mean the position wouldn't be taken. I can't even get AB and Parker/SSD to even look at a comms issue between them even though I can consistently repeat it. What do you think would happen if I had a development environment issue with something runing on a platform that MAY NOT be what it was developed to run on.

Those of you who have seen enough of my posts know that I am just enough of a cowboy that Linux based systems would appeal to me. Performance trumps almost all else in my books every day and twice on Super Bowl Sunday. I also know that there are enough stable Linux implementations out there that stability really isn't much of an issue. But I am also enough of a realist to know that most companies will not just abandon 20 years of relationship and development for what is effectively a parallel path. Many of the bigger players in plcs are tied very deeply into the Windows environment with their development packages. Until Linux makes a much bigger push into the general commercial market I don't see any movement from the big plc players to jump into it from a development environment standpoint.

Keith

Oh for Pete's sake, the '90s called, and they want their arguments back.

Linux is used in virtually *all* of the world's supercomputers, presumably because they don't have to worry about culpability. Or reliability. Or performance.

Linux, or a Linux derivative, is used in about 50% of embedded devices, and the market for embedded MPUs vs desktop CPUs is about 10 to 1 the last time that I checked. Not exactly what I would call a financial lightweight.

And the "last time that I checked" was a decade ago. What doesn't have an IC in it these days?

And while we weren't looking, it seems that developers have moved on as well:

"In 2016, embedded Linux is now all grown up. Of embedded engineers that VDC recently surveyed, 40% indicated that they were using Linux as the primary operating system in their current project, with the distribution of those using commercial Linux (Android, SUSE, Red Hat, etc.) and free Linux (Debian, Fedora, kernel.org, etc.) split 50/50 down the middle. Furthermore, sentiment points strongly towards abandoning of commercial OSs by many OEMs, primarily for the greener pastures of free, open source Linux distros in the foreseeable future."

Source: http://www.vdcresearch.com/News-events/iot-blog/Embedded-Linux-All-Grown-Up.html
 

Similar Topics

See the Codesys LD program below; I would expect Rungs 2 and 3 to produce functionally identical results, but they do not. Does anyone have any...
Replies
36
Views
2,026
Hi All, I have a programming background but have never used a PLC. I have what I think is a simple automation project however Im not sure of the...
Replies
19
Views
1,853
Hi All, I'm new to Siemens PLCs. I have a device that have a Siemens 1515SC IPC ruining the control and HMI applications, its documentation...
Replies
8
Views
1,703
See picture. I want to add a rung (magenta) into the existing code. Can't figure out how to do this. I select a -||- , right? When I drag/drop...
Replies
21
Views
1,800
Back
Top Bottom