Do you use Open Source Industrial Software?

[Nathan 7]

Just curious if anyone here uses or participates in open source industrial projects. It's a shame to hear about so many people writing the same little apps from scratch. This is kind of a version of this thread from plctalk. I got flamed for suggesting that communication drivers ought to be free. How dare I even suggest that hardware manufacturers bundle drivers with their products! Or that users contribute to something without being paid!

[TConnolly 13]

I don't use open source, but I also think that it is fine to use. There is some really great open source stuff out there. There is some not so great stuff as well. If you want a driver that is supported and has easy to get tech support then I don't think it unreasonable to pay for it - as was said in the thread, development and support has costs associated. But, there are lots of tinkerers in this world who are incredibly bright people. I'm glad they develop open source applications and take the time to upgrade them - I just don't expect the same level of support.

[paulengr 44]

I use open source extensively when possible or practical. There are two basic reasons. First, whenever I have to buy software, I have to fill out a purchase requisition and go through the bureacracy to not only get it approved and installed but then I am obligated to maintain copies of the software, the license agreements, and fill out annual paperwork for renewal of support contracts. Basically every time I buy something, it adds more and more bureacracy on me over and above the initial purchase (which is bad enough). With open source, I just download and install. Depending on the complexity and size of the program, I could have it installed and running within 1 hour. For commercial software, it amounts to a minimum of several days. Talk about your development time killer! The second problem is that it really drives me up the wall when I'm dealing with the proverbial black box situation and trying to debug both my own application work and the underlying platform's strange little bugs and idiosyncracies. Theoretically, you get "better support" with a commercial product. In practice, even if you pay for customer service, it doesn't really happen. The techs that you get on the phone go through a prescripted conversation which amounts to going down through tech notes that are published on the company's web site. If this fails, then they kick it back to "engineering". At this point everything dissolves into E-mail and it can take either days or months before you get a response. By way of example, with one MES system that we have, a specific advertised feature that took up an entire chapter in the manual (and training classes) flat out did not work at all. After spending hours on the phone, it got kicked back to "engineering". After a month of no response, I downloaded an open source project and developed an alternative that wasn't sexy but it did work. Six months after that, the engineer who actually needed the feature to work went to work for someone else. Six months after THAT, the MES vendor got back with a patch that still didn't work! Second caee in point: the CPR 9 version of "RS-Linx" from Rockwell. If you are using Rockwell's own HMI, you'd use "Enterprise Linx" which hopefully has the bug fixed. But "Linx Classic" has a major problem. Whenever you drop communication to a Contrologix (Logix 5000) processor and then restore it, an OPC-based software connected to Linx Classic has to drop it's connection and then restore it. If you don't do this, it will NEVER EVER AGAIN talk to that processor. So you ought to see the little arcane scripts and workarounds it takes to deal with this one since you have to first detect the problem and then fire off commands to stop and then restart the driver in the HMI to recover from Rockwell's screwup. Their solution: just buy their HMI and spend months rewriting your entire SCADA/HMI system to run on Rockwell's system. If this was an open source project, if somebody didn't publish a patch inside of 2 days on a forum that you could snag and install first, there would be a new release within a month for the official version. And failing that you always have the option of doing it yourself if you have to. That option is never available with commercial software. As to the argument that drivers ought to be free...the hardware is effectively useless in today's environment without the drivers. This is akin to selling you a car but then charging a substantial percentage of the price of the vehicle for each set of keys. Then rubbing your face in it by talking about the amount of time it takes for the dealer's technician to cut a key when the hardware store does it for free in 30 seconds.

[Nathan 7]

For now, I agree with you. However, the face of open source software is changing. I predict more corporate owned/sponsored/run open source projects that sell top notch support plans. Sun and Red Hat come to mind. These projects tend to have mature communities that offer high level support, which is typically free. That said, as I stated in my very first and subsequent posts, companies like Kepware have their place. They provide an outstanding product and stand behind it. I see these companies co-existing with the evolving open source communities, although I think it would behoove them to embrace and support open source like Sun does. I'm interested in changing the fixed perception in this industry that open source is inherently inferior because it's "free". Companies can profit by supporting these products and selling "higher end" versions. They get the benefit of free advertising/marketing/training/support communities. Open source projects can thrive entirely without corporate backing. Paul - the bulk of your complaints with commercial industrial software come down to specific problems and company responses that you've dealt with. A software project, commercial or open source, can vary in quality from total crap to very nicely written. The quality of updates/bug fixes/etc can vary to the same extent. I think it's fair to say that either commercial or open source could range in each of these aspects. IMO, the real problem with industrial software is that it's such a niche market. The biggest players, both commercial and open source are puny. I have had my fair share of gripes at certain industrial software companies. I've also dealt with open source projects that are a total waste of time. I've also dealt with the opposite of both cases. It really comes down to who you're dealing with and the quality of their product/support. Edited 24 Jan 2008 by Nathan

[paulengr 44]

I'll give you a specific example: charting software for HMI's. I beat my head against the wall repeatedly just because I was working with an ActiveX based HMI. The "free" one that comes with Microsoft's programming environment (free as in you just have to pay for Microsoft's programming environment) is a throwback to the 80's and really, really sucks. The one that comes with Office gives you very little control over the look of the chart and is always doing something wrong, but you also have to install Microsoft Office on every machine that runs it. The free ones range from just plain garbage to on-par with Microsoft's "free" one. There are several commercial charting programs but they aren't any better than the one in Microsoft Office and it only takes several hundred dollars and lots of time purchasing them to find that out. In contrast, there's JFreeChart for Java. They give away everything but the manuals (which you can still get for free with a little searching around), but JFreeChart is very, very nice. It works pretty much every time with very few bugs (and those are usually fixed promptly). If you need technical support, it's available in droves. There is little to no competition because it's very good at what it does. It's open source. It's very available. In the end, I ended up harnessing Internet Explorer (as an ActiveX applet) just in order to run Java and JFreeChart within it. I had to write a fancy web page and modify the HTML on the fly in order to handle all the HMI container--Internet Explorer container--Java applet container---Java environment issues. I'm not really happy with the interfacing ugliness but in the end at least it works very, very well. My experience has been similar in many areas across the board. So in this case, what I'm saying is that the best system was open source. I had to do a lot of work to make it work primarily because I was working from within a closed source world that has very poor offerings including tying their object interface so tightly to the OS that running anything more "open" is actually very hard to do. I also use open source PDF engines. The open source programming environments are top notch and better than I can get commercially (Eclipse, Netbeans, and CPython come to mind)...and yes, I've already worked with dotNET enough to get comfortable with it. Apache just works, every time. I can't keep track of how many electronic devices ("appliances") these days come with Linux somehow embedded in them. There are three applications I know of where the open source alternatives kind of stink. First, HMI's (FactoryPMI is inexpensive and very good but not open source). Second, PLC interface software (assuming this refers to OPC...generic drivers are pretty common and free if you don't mind spending the time to look for them). Third, PLC programming software or alternatively, PLC's in general (as in there's no open source PLC that you can load onto an industrial PC worth mentioning). I've read the "niche market" argument against open source software for industrial control before. Frankly, it doesn't seem to hold water in general. There are hundreds of open source projects that are dedicated to essentially niche markets where little or no commercial competition exists. One would think that precisely because industrial control is so specialized and the fact that it is definitely a niche market would mean that there would be a similar situation...very low commercial support but very good open source support. But alas as with any open source projects, it only gets that way when there is a small core of very dedicated and skilled individuals who start the ball rolling.

[Nathan 7]

This one's gonna be fun I should have known better than to ask you of all people for more specifics. Remember that I was sided with Open Source software at the beginning of this thread...I'll try to play the devil's advocate. First off, I'm not going to count FactoryPMI in the "normal" industrial software. It might as well fall half way between both - the list of open source software used in the license agreement is pretty extensive, many of which you mentioned: Apache (web server), JGroups (web clustering), JFreeChart (graphing), Jython (Scripting), JEdit (text editor), and various other open source components. OK - charting. Good example! I'll give Open Source a big victory because, to my knowledge, none of the HMI vendors use a charting package that's worth a darn. FactoryPMI uses a custom version of JFreeChart (which is an awesomely powerful open source chart project). I've also written custom PHP web pages that use JPGraph (also a good open source project). However, Microsoft Excel charts are about as good as it gets in terms of bang for your buck (although not totally relevant in HMI discussions). I know there are a lot of very powerful commercial charting libraries like this one. SCADA vendors have chosen to do their own things. Retarded decision, but I don't think you could decidedly argue that Open Source charting is better than commercial. That is a case where you'll get better results if you have problems.

[paulengr 44]

There's three huge reasons for this. First off, look at what's happening on the hardware front. The field bus wars are starting all over again. I have been able to very easily and successfully mix hardware from different vendors in the Modbus/TCP platform. I expect similar results with Ethernet/IP when we make that leap soon. This is going to pave the way for less vendor-specific systems over time. The reason that this didn't happen to the same degree in the software world is the dominance of the IBM PC platform. The fact that you had a single de facto vendor model that everyone else either supported or emulated paved the way for clearing up the software mess that existed in the 1970's and 1980's. It wasn't that way back then. Of course I wish that the gold standard had been any other platform but Intel's processors, but ce la vie. In the programming world, you have one of Microsoft's object models at the binary level (either COM/DCOM or dotNET) and then you have everybody else (XML, JSON, Java object models, XPCOM, CORBA, etc.). If you are working within the Microsoft world, there's a lot of tedious programming involved in translating everything in and out. In the world at large, you can pretty often mix and match freely with very few issues. Or for instance, although everyone "supports" SQL to one degree or another, many of the most important features of a given database server do not have even close to the same implementation on another vendor's server. This would be fine if the ANSI standards were implemented more fully and/or many of the most basic but important features were more uniformly available. MySQL only recently supported stored procedures for instance, a staple feature on SQL servers. The software world isn't quite as uniform as it sounds. The second issue has to do with the fact that industrial engineers (the generic term, not the specific field) and programmers are frequently very closely tied to maintenance. Reliability is a very, very strong requirement. How many plants do you see still installing hydraulic and pneumatic systems despite the fact that all electric automation systems are frequently cheaper, lighter, faster, and more reliable? Reliable AC vector drives have only been around for about 10 years. The same thing in hydraulics or pneumatics has been around for 2-3 decades. Reliable ball screws and linear motors have almost an even shorter lifespan yet. Relatively uncomplicated, easy to work with servos have been around for even less time than the AC vector drives. Finally...as to being supported and longevity...I wish they had a required course in industrial archeology when I went to school. In spite of the longevity arguments, not a month goes by where whatever we've been using and buying for years didn't get obsoleted. So then I have to spend some amount of time figuring out just what the heck the widget is and what it does and what's available currently. For something like a motor or a drive, this is fairly easy. Now try to do that with software! Unless it happens to be open source, you have almost no chance in the world of ever finding a direct replacement. And if something goes wrong or there's some kind of problem with software, you have almost no chance of figuring it out on your own once you get beyond simple mistakes that you can work through from the manual or that are the result of your own handiwork. By way of example, a new arc spark spectrometer where I work would cost between $50K and $100K. Our old one is functional and does pretty much everything that the new models do. The hardware really hasn't changed significantly. The PC software that works with it is essentially a DOS program and the "upgraded" versions that I've seen are just running the same old software in a DOS shell. The latest incarnation of a PC is that we took a thin client, ripped the OS out of it, installed a freeware DOS program via flash card, and we boot off that. No fans, no hard drives. If we need a replacement PC again, the cost will be <$300. In fact, we bought two just in case. If this had been a Windows program, chances are that we'd run into the various Windows 3.0/95/98/NT/XP/Vista compatibility problems, never mind the idea of running disk & fan free. It just wouldn't happen and we'd be forced into a never ending cycle of upgrades and bug patches trying to maintain something that's little more than a very large and expensive scientific appliance. So in some ways, I'm not really interested in upgrading the software again, EVER. I'm not entirely interested in upgrading the hardware either for the same reason. And there doesn't appear to be any availability of open source arc spark spectrometer software on the horizon any time soon, or pretty much any other spectrometers with the possible exception of HPLC's and GC's that seem to be much more common and have better overall support.