The dilemma is whether our software being installed will be more reliable on a WinNT machine or a Linux machine. I appreciate the various good points for each OS, and am not that fond of Bill's monopoly on everything, but all that aside I need a reliable system to deliver. The system will house and encryption engine as well as a Wireless Network Router. The encryption engine I am developing but the wireless software is from another source.
So people, the floor is open to suggestions and reliability figures (namely MTBF) if you have any.
Kind Regards,
Javier Gonzalez

 

You won't find a lot of hard data on this subject because the Linux folks don't have the money to commission studies and the MS folks don't want to talk about reliability, although I've heard that W2K is better than the previous revs. I have on the average of a dozen Linux boxes with Redhat 5.0 to 6.2 on them doing various things from machine vision to actual control and
about the same number of PLC's on the factory floor. We have more problems with the PLC's. The Linux boxes very seldom stop between scheduled plant shutdowns or power outages. The problems we have had are mostly power related but I have had mechanical damage to the vision cards, the connectors fatigue. We have replaced all MS licenses with Linux and noted about 70-80% less support hours. This is vs w95, w98, NT3.x and NT4. I can't help you with W2k as we have never (and probably will never) installed any. The support cost reduction includes the office people who are all running Linux now as well. Linux is reliable. To run My Iron Lung, it would be the only one of the bunch I'd even consider. I count on uptimes greater than one year if the power holds.

Regards

 

Nothing like opening the can of worms on a friday!

Hands down, Linux (unix based) OS is more reliable. Windows is more user friendly. If you have a system that needs general purpose use that office people are going to be using daily as a general purpose workstation, use Windows. It will still crash more in the long run, but the pretty GUI and wider availability of office type applications makes up for it.

If you need server room type operation, use Linux. I have had a WinNT 4.0 server sitting next to a Linux server. The NT box is always more
problematic than the linux box. And before anyone jumps down my throat, I am better at windows than Linux! I actually took the time to configure Windows to MS spec. I threw Linux on the machine just to see what it would do at the time. The linux box ended up as the file/print server, and the NT box ran MS-SQL 7.0. Both saw about the same amount of workload. I had a BIG UPS on the machines (kept both alive for 120 minutes), so power outage never was a factor. In 18 months, I rebooted NT twice. Linux never. I left the job before I got any more data.

I hope this helps.

--Joe Jansen

 

Is this a C app or something that can be easily ported to either OS? I hate Microsoft passionately BUT poorly written software will provide poor reliability on either OS. I have an NT box that runs for many months without being rebooted and gives me no problems. It also does basically nothing except for some nightly data management and be an under-utilized PDC.(only about 30 clients) I occasionally reboot it just because I don't trust it, despite that it has not failed me yet. On NT boxes that do more, I have more problems, and killing offending processes does not resolve problems like rebooting does.

I also have 3 Linux boxes at home (I'm a newbie) running Redhat 7.1, and they aren't as bug free as I'd expected. I haven't had a crash, but I have had them lockup. Frankly I sort of prefer a crash, depending on the damage. At least then I have some idea what went wrong. I'm sure I just
need to learn how to best configure Linux and probably stop using X-Windows. Then I'd likely achieve the proverbial Linux reliability.

I'm sure you'll get more passionate answers in favor of Linux than mine, but I'd say, as long as the app is good and you know how to configure Linux for your functionality, Linux would be a no-brainer. Unfortunately you have to have quite a bit of a brain to meet the pre-requisite assumption.

In other words, can you support Linux well enough that bad system administration doesn't become the source of unreliability? I can't ... yet.

Dale
Honda Eq Staff

 

Curt wrote:
>I have on the average of a dozen Linux boxes with Redhat 5.0 to 6.2
>on them doing various things from machine vision to actual control and
>about the same number of PLC's on the factory floor.We have more problems
>with the PLC's.

What the heck kind of PLC's do you have that you could possibly have more problems with them than with any PC, Linux or whatever?? I'm getting on
the Linux train too, but I have literally NEVER seen a PLC crash, and we have HUNDREDS of them in my department. Practically the only one's we've
replaced since the plant was built 13 years ago are those in high vibration cabinets, and only as a precaution. The PLC's we use are as reliable as
the hardware they're made out of and the prudence of circuit design connected to them. I have seen PLC cards fail because of poor wiring practices or irresponsible, crazy forklift drivers who crash through conduit and short a 115vac circuits to output cards. We don't have that problem at Honda though due to exclusive use of 24vdc control to the IO, only using AC for large solenoids, and this applied by relays external to
the PLC.

Dale

I do believe though that scaled down embedded Linux will be able to achieve this reliability with great care in configuration and development.

 

Dale Malony wrote:
>
> Curt wrote:
> >I have on the average of a dozen Linux boxes with Redhat 5.0 to 6.2
> >on them doing various things from machine vision to actual control and
> >about the same number of PLC's on the factory floor.We have more problems
> >with the PLC's.
>
> What the heck kind of PLC's do you have that you could possibly have more
> problems with them than with any PC, Linux or whatever?? I'm getting on
> the Linux train too, but I have literally NEVER seen a PLC crash, and we
> have HUNDREDS of them in my department. Practically the only one's we've
> replaced since the plant was built 13 years ago are those in high vibration
> cabinets, and only as a precaution. The PLC's we use are as reliable as
> the hardware they're made out of and the prudence of circuit design
> connected to them. I have seen PLC cards fail because of poor wiring
> practices or irresponsible, crazy forklift drivers who crash through
> conduit and short a 115vac circuits to output cards. We don't have that
> problem at Honda though due to exclusive use of 24vdc control to the IO,
> only using AC for large solenoids, and this applied by relays external to
> the PLC.
>
> Dale

GE Series 90/30 with Horner Electric OIU's and comms modules. Of the two I'm less impressed with Horner. Lots of DOA and bugs. Once you do the
workarounds and get it running, there is still occasional memory corruption and comm failures. We won't even discuss the Windows only tools, it sure is annoying to have to keep a Windows machine running just so you can use the products. That's more work than it's worth. Part of the
issue I'm sure is that we are always breaking taboos. What we do primarily is integration. We _have_ to talk to other (GE and Non-GE) equipment and PLC vendors are tightly focused on preventing this or at least making it non-competitve with doing it _their_ way. We build machines and cells and it's the nature of our business to use existing equipment. The result is very slow, painful, development. Yet, it's amusing that when I mention on the list that I can do it faster with full custom code and Linux people think I'm lying or at least blinded by Linux zealotry. I say amusing because these are almost always people who use Windows and so believe that PC's are junk and always crashing, etc. The rich and open comms environment in Linux is so vastly superior for talking to diverse systems that it simply takes much less time than using "off the shelf" PLC's. Linux excells at what PLC's are intentionally and notoriously lacking,
interoperability and connectivity. If you don't believe me, you haven't done much talking to "foreign" systems. This is not opinion, you can come and see it run and talk to folks who paid for it. They will go with Linux next time. Any and all of the above can do logic, that's a given. It's so well marketed that PLCs are infallable and PC's are junk,that people always want to boot my Linux boxes whenever there's a problem. At least nine times out of ten the problem is elsewhere, sensors, or the PLC. I am
quite conservative with Linux, there is no way I would be running a new release until I have seen it run for a year or so. With Open Source Software, there is no compelling reason to upgrade from a version that does everything that you need. I use standard desktop RedHat 6.2 on socket 7 motherboards at the moment. Even for machine vision I don't need 1.2 Ghz processors and the wonderful gee-whiz gadgets like USB, etc, etc, typically don't work for the first year. I will have to switch to ATX MB's as they are "standard" now and have been out long enough to actually work. When you hold all the cards and make the decisions, you _control_ reliability. When you let others do it you have no control. No forced upgrades or version churn under Linux. MS and Intel are forcing the demise of ISA cards, but I can deal with that.

> I do believe though that scaled down embedded Linux will be able to achieve
> this reliability with great care in configuration and development.

I find standard Linux on commodity hardware comparable at least, now. YMMV I am interested in Embedded Linux and watch the developments quite
closely. Since I use a lot of the features of "regular" Linux for HMI, remote access, etc. I haven't needed to go there yet. When LPLC is ready
I'll probably work on "direct replacement" hardware. A din rail mount LPLC would let me replace a lot of proprietary gear ;^).

In summary, IMHO people who are down on PC control are simply running the wrong software on the PC. I couldn't do it that way either.

Regards

cww

 

In my opinion, there can be no common solution for all applications. My feeling is that the person selecting the hardware, software and the
network cofiguration, should be certified by the OS supplier and have a throught undertstanding of the application. A unix/linux system which may
function admirably to serve databases, may crawl if it acts as an XWindows server as well.

These are my views only

---------------------
Sumeet Chimalkar
Design Engineer- Instruments
Jacobs H&G - Mumbai
(9122) 8208075 ext 227

 

Wow Curt you can sure respond to a question.

I think we see more eye to eye than you may have thought from my email. I don't think PC's are junk. I think that bad software and the
mysteries of Windows compatibility make them far less reliable than their hardware. I stated in my message that the PLC's we use are as reliable as the hardware they're made out of, which is the best anything can get. You were talking about what you'd have control your iron lung. I would do it with an Omron PLC and probably some others, but from what you're telling me about Horner, I wouldn't use their stuff to control the heater for my dog's water-dish in winter. Maybe a sprinkler system if didn't have so much money in my landscaping.

As for trusting commodity PC's with my life, no way. I have seen far too many hard drives fail and I just don't trust them to that degree. I don't trust anything that I need to keep clean and cool. If I have to build an air conditioned apartment for control hardware, I'm not interested in it.

Embedded is where it's at. I can get a 200mhz MIPS box with disk on chip that burns only about 20watts, thus doesn't need a fan. And I can get far better long term manufacturers support for such hardware. Try getting a commodity PC manufacturer to support you 10 years from now. Most likely aint gonna happen. Many Industrial hardware companies have a track record of providing long term support, so when I need to replace the flash disk or even buy another identical box (why?) ten years later, I can.

I believe that you can develop Linux control systems faster than with proprietary methods. I also understand that you have spent great deal of
time developing modules for this and have become an expert at doing it. Very few people have that skill level and it's not going to catch on
until lots of really smart and talented guys like you develop great software tools with dumbed down front-ends ala Windows/Mac. Most people that will deal with the creations of integrators after installation could care less how efficient the development process was if they only have 2%
the knowledge required to figure out what's going on when a wrench gets thrown in and stops it from working. What about reconfiguring from scratch
after a major failure like a lightning strike? Downloading a program and setting some dip switches is far easier than anything I've ever seen in PC configuration.

I totally agree with you that it's a major pain in the rear to integrate 3rd party products with PLC's and that Linux is an optimal platform for
this. I work with Omron in Ohio. Aside from Honda and a few other Japanese transplants, nobody uses or supports Omron and they are barely
getting into Devicenet, let alone any other flavor of "open" protocol. If you see another recent post of mine, I mention Omron's new "Open Network Controller" which helps to live with the mess they created by developing no less than 4 proprietary network protocols. The fascinating thing is, it runs on embedded "QNX" which is basically an embedded Linux variant. I about fell off my chair when I learned Omron actually is on the cutting edge with a product again.

I'm getting on the train Curt, but it's not quite at the destination yet.

Dale

 

Hi Dale

I regret it if I seemed overzealous :^) I am, I think, justifiably excited at how this project has been turned around by using the right technology. Anytime you can turn a loser into a winner easily, it's exciting. To be succinct, my
points were that we can manage reliability better if we hold all the cards and that better tools and truly open systems can make a world of difference in project feasibility. I am not a super programmer and the total resources to
accomplish this were a lot less than you might think. With all the software that comes with Linux there is very little that you have to write and you have a wealth of ready source code examples for almost any problem. Support is
an issue, but, from some of the discourse on the list, the automation vendors aren't batting 1000 either. Support of the two types is very different. I'm sure that Linux and my program will run on machines available for the next ten years. I can get them from anybody, and someone will have what I need. Contrast that with a single source proprietary system, how many ten year old products will they support. And if they decide not to, you're toast. It's not that black and white but I know _I_ can fix my system for ten years even if all the vendors I bought it from go belly up tomorrow. It's all generic enough to do that and I've got the source. By the way the QNX folks would have a cow if you told them they were a Linux derivitive. They have opened up some on account of Linux. Come on board, We're accelerating

Regards

cww

 

In my experience WinNT is more reliable that the hardware it is running on. You would be better off concentrating on how to keep the hardware running. Based on what you are describing
I would suggest a diskless system and an OS like QNX.

I don't want to start a big debate here but the fact is there are dozens of OS's available. Therefore, Bill does not have a monopoly on "everything", including OS's.

Oxford American Dictionary
Monopoly : exclusive possession of the trade in some commodity.

Jay Kirsch
[email protected] <mailto:[email protected]>

 

Funk & Wagnalls
Monopoly: "The exclusive control of a commodity, service, or means of production in a particular market, with the resulting
power to fix prices."

Standard Oil did not have to be the only company producing and selling oil to be a monopoly. Other people could sell gas, but they were able to use force them out of the business. The exclueded competitors from the market, by fixing the price so low, the other companies went of of the business, (then they raised the prices).

Likewise, Microsoft doesn't have to be the only one selling (producing) OS's to have a monopoly. They exclude competitors largely through pricing, the use of proprietary protocols, and purchasing agreements, and liscensing agreements.
Microsoft has control of the market and is able to excude other OS's from the market. They are a monopoly.

Mark Blunier
"Any opinions expressed in this message are not necessarily those
of the company."

 

I find it interesting that I can often fix "bad" hardware simply by loading Linux. I had inherited all the "bad" systems while the rest of the company was running Windows. Now that they are all running Linux, I have had to build generic systems for utility use. Per Oxford, Bill still has a monopoly, the others, except for Linux
could hardly be described as commodities. the volume is too small. I have evaluated QNX. Nice, UNIXlike, proprietary, horrendously expensive. For my applications it offers less than free, open, Linux. The only way it would make sense is if I needed to keep my stuff secret and proprietary. I have no real need to do that in house. Most of the stuff I do could be ported, except for the machine vision. Commissioning a driver is not feasible. I do have some flashdisk
around. It's cheaper and easier to clone the drive as a backup. MTTR of 10 minutes or so. For non hard disk failures, I would put the hdd in another barebones system, MTTR about 15 minutes.
So far I haven't had to do either but hdd's are the most likely failure. If there's much vibration I can burn an image to CDROM, bootstrap
to ramdisk and run. Live data goes to a remote NFS mounted filesystem. And everything I need to do it comes on a $1.98 cd. And I can know
exactly how it works. Just the programming tools for MS would exceed my system cost. I'm having a real hard time seeing the downside.

Regards

cww

 

Not trying to pick an argument, but...

>Standard Oil did not have to be the only company producing and selling oil to be a monopoly. Other people could sell gas, but they were able to use force them out of the business.
The exclueded competitors from the market, by fixing the price so low, the other companies went of of the business, (then they raised the prices).<

...OTOH, look at how Charles Dow made Dow Chemicals a huge and successful company in the face of foreign dumping and price fixing. A great story!

 

Mark Blunier wrote:
> Microsoft has control of the market and is able to exlude other
> OS's from the market. They are a monopoly.

I suggested that the questioner look into the QNX OS for his application. There is absolutely nothing stopping him from buying this product instead of a product from Microsoft. If more
people did this, Microsoft would not have what you call a "monopoly".

No one from Microsoft has ever forced me to buy one their products, hid information from me that I had some "right" to, undercharged me, or overcharged me. Even if Microsoft had a
monolopy, so what ? I still don't have to buy anything from them. They have no control over me, let alone an entire market. The only monopoly I have to deal with is the U.S. government. I have to pay for their goods and services or go to jail. They even force me to pay for many things I believe are immoral, including the persecution of Microsoft.


Jay Kirsch

 

Curt Wuollet noted:
> It's not that black and
> white but I know _I_ can fix my system for ten years even if
> all the vendors I
> bought it from go belly up tomorrow. It's all generic enough
> to do that and I've got the source.

Maybe this subject should be renamed "Intellectual Manageability"

I think Djikstra coined that term in the 1970's.
It basically refers to the ability of a person to get their hands around the whole problem.
You can't do that with megalithic software systems.

Purchasing software and other components "off the shelf", is great until you have negotiate with support people, sales people, and pointy hair
bosses just to talk with the guy who wrote the code.

Often times, it is better to look at the code--figure out if you or the other person is making the mistake. Then send them an e-mail.

With Linux, the engineer is essentially in-control of the software and hardware systems. The source is with you (to paraphrase George Lucas).

But essentially, if you disagree with the source of another engineer you can change it.

William F. Hullsiek
MES Software Engineer

Whatever happened to POSIX ???