Linux, MS, longevity and popularity(was MS 'Monopoly'?)

A

Thread Starter

Anand

hello LinuxPLC skeptics and supporters,

Note: I am not a LINUXPLC spokesman, and neither is this any official
declaration from LinuxPLC, but just some views that I have.

i have been on the Linux PLC list for some time now.
I have worked with AB PLC's (2/05, 2/17, 5/10, 6/40, 5/40E, 5/80E, SLC
5/01,2,3), modicon, Mitsubishi, Toshiba, Siemens, Crompton Greaves,
Honeywell (IP620-35 a long time ago) and others. A few DCS systems, A
TMR and other systems.
I recently uploaded the CSV files of the linux PLC project. I am not a C
programming expert. but have some knowledge and with some help from
friends, intend to understand the advantages.

Some basic advantages that I could figure out were:

* Modular approach. The program has a good modular approach and over
time, the PLC overhead can be reduced so that only the used
functions act as program overhead, this will in result translate
into a faster code.
* Multiple blocks. A lot of functionaluty will be added by
programmers over a period of time and you could have a number of
special function blocks, largely absent in many PLC's today.
* Embedding of linux and program could lead to a variety of devices.
* The project is working on the goodwill of a few people. We are
still talking of development. We could shift the development to
India and work can move faster at a very low cost but then someone
will have to finance it.
* And you have the flexibility of using a good programmer and
changing the routines as you require them Flexibility in other
words, is one big advantage.

Some things that need to be added:

* IEC-61131-3 compatible languages. PLC programmers are conversant
with one or some of the IEc61131-3 languages and so all of them
will have to be supported. This will take additional development
time.
* A simple rpm or apt file will have to be provided, so that PLC
programmers do not have to go through the hassles of compiling
etc. Fully automatic installation with the press of a setup key.
And program built and transferred in the background to the
processor when the download to PLC key is pressed on the panel.
* I/O variety and communication variety. Though some work has been
done on it, still some more will be done so that all users are
satisfied.


I believe with time, the other comercial vendors will get a lot more
goodies from the LinuxPLC leading to overall development of the I&C field.

Anand
 
List,

So it's a couple minutes past six in the morning and I'm reading John
Waalkes' comments about GM, AB, and "hostage-taking" as a metaphor for
support and technical innovation.

I'm sitting in a motel on the coast, 320 miles from my office, with my
hardhat and Carhartt on the chair next to my trusty Dell laptop, my
ordinary ZIP drive archive system, and an interface card to an open network
protocol administered by an industry committee. I got here at 11 last
night to teach a class first thing this morning to some maintenance
personnell about using their networked motor starters to improve the
reliability of their pumps, conveyors, and other ordinary mill equipment.
The mill isn't paying for this class; the consultant that they pay to
improve their material efficiency is doing so.

I'm using proprietary software that I downloaded from a closed Internet
site using my license key. I'm using an open protocol specification
document as the basis to write simple instructions for the maintenance
personnell to replace motor starters and complex instructions for the plant
engineers to log system data into a Microsoft database engine. What
matters to me, and to my customer, is that the system works, and will keep
working when I leave.

And here I find that really what I do for the living is suck blood out of
GM and hold them into sluggish committee standards because I'm a leech and
a moron. Thanks, I had no idea it was that easy. I'll be certain to lay
down my earplugs and meter this afternoon and put another hitch in the
tourniquet I have around the arteries of my customer's purchasing
department.

When I go into the mill this morning, we'll be using Microsoft operating
systems because we know we both have the components needed to run the
application; they weren't optional in the distro. We'll be using a
major-brand PLC and major-brand motor controls because they're available in
a store an hour away by car, not "overnight" via FedEx from a web dealer in
Florida. The PLC manufacturer has been in business slightly longer than
the mill we're servicing... since about 1903, not 1993.

One of these nights, I'm going to try a little experiment... I'm going to
go into a bar near one of these mills and ask around the fellows playing
pool under the Budweiser light if they can compile a kernel. And then I'm
going to drink some of that Budweiser and go back to the hotel and not have
to mess with my operating system to get it to support my archive drive...
because I paid $210 for it.


Lay off the venom about the big mean technology monopolies. You might
find that there are some good engineers and honest support technicians
working there.

Ken Roach
Allen-Bradley / Seattle
[email protected]
 
D

Daniel C. Rozok

Golly jeeper's, someone really has to make this stuff work!

Ken, thank you for the poetic and accurate reprisal

Daniel C. Rozok

 
K

Kolt Loughran

I've only been doing the control system thing for about ten years, so I won't claim that I'm an Allen-Bradley expert. But I have been an "A/B integrator" for those entire ten years.

My understanding of the "integrator" relationship is that we the experienced contracted engineers are called on by your company, the equipment vendors, to install your systems. And during this period I have been front row to MANY of Allen-Bradley's dissapointing performances.

But my biggest disappointment came when Allen-Bradley announced that they no longer would support the 6200 software for the PLC-5 line. Instead they were going to move to the new RS-Logix model... thus taking advantage of Microsoft's wonderful integrated operating system. (This was after the buyout of ICOM's competing AI software obviously). Now I don't know if you remember this, but at first the RSLinx only worked on WinNT... and not very well. Then when the drivers did finally get ported to Win95, they had this tendency to crash the OS depending on which SR version you had installed.

So here was this 100 year old company that had contracted me to install a simple PLC, and I was spending my time installing and reinstalling the SUPPORT SOFTWARE! Of course Allen-Bradley blamed it on Microsoft, and Microfsoft blamed it on Allen-Bradley. The bottom line was that I had to explain to a company (that didn't want the PLCs to begin with) why they HAD to upgrade to WinNT on at least one supporting computer, purchase COMPLETELY new programming software and would have to pay me for another two or three days worth of work just to port the logic database over to the new system. (And this isn't even scratching the surface. I can go on and on about the new Panelviews needing an intermidiate database where direct mapping was previously sufficient, and RSLinx drivers that won't function with a KT card on one side and a KF on the other...)

I therefore would support the original author and his opinions on proprietary software. An open source model allows the user to OPT OUT of upgrading, unless required to do so by THE HARDWARE. Plus, I also find that open source bugs are found quicker and are resolved faster. The extra money that a company gains by keeping their software proprietary is not only cost in terms of the purchase price, but also in terms of the extra effort required by the user to operate and maintain it over a given period of time. Thus open source is MUCH cheaper for a user (and thus more desirable to the accountant).

I finally gave up on all of the versions of RSLinx and wrote my SLC and PLC code in ASCII. It eventually was easier to port into all of the various revisions of RSLogix that came along. And I didn't have to waste time relearning or reinstalling. Oh, and I too have a trusty Dell laptop Inspiron 3200, and since I installed RedHat 5.0 on it three or four years ago, it has never crashed... even once. And I have NEVER recompiled the kernel for it.
 
C

Curt Wuollet

Hi Ken

I appreciate what you do and yes the existing environment works, it's got billions behind it and That's good because the whole thing runs on
money.
You don't appreciate what I do, I think. I have spent the last two weeks in a fiendishly hot and humid environment putting the finishing touches
on a system that is built with OSS and some my own code. Why would I do this with all that wonderful "off the shelf" equipment available? Well, because I was asked to after the attempt do it with said equipment cost a small fortune and got bogged down by intrigueing little details like: Fanuc lathe controls won't talk to Fanuc Robots which won't talk to Fanuc PLC's. The only common means of talking amongst them is RS232.
This wouldn't be too bad if they were actually designed to integrate in any way shape or form, but they're not. Of the three, only the robots
have any reasonable facilities for sending what _you_ want to send to another machine. The PLC's require a particularly unreliable module that
can be commandeered with enough effort to communicate in cmm or ccm, one is the module and the other the facility to what? I never did find out.
To get anything useful into or out of the PLC, I wrote enough of the protocol, probably at risk of lawsuit, to communicate with it's "canned"
inflexible, rather buggy routines and exchange a few registers.
The lathe controllers are rather intent on only accepting and spewing stuff reminiscent of my earliest work with Micros (that's Z80, not PLC).
They deal with PTP's and tty's, which fortunately I am familiar with. I might sneak some chad and oiled paper tape into the same coffee shop
and see just how many people know what it is. I digress. Anyway, to get this lump of machinery to communicate without killing any trees requires
that you do a bunch of thinly disguised assembler (it has the innovative "MACRO" features) in two seperate flavors. To write EPROMS requires an
absolutely criminally overpriced piece of gear called an FAwriter and you need to write EPROMS iteratively. I broke down, figured out what they were doing and used a $50.00 EPROM burner and a little snippet of code on my Linux box. I couldn't see any reason for obfusticating the
process except to sell said FAwriter. Anyway, compared to that, writing the vision code and my side of said comms was trivial, really. As it
turns out the robot serial comms were better left alone and we did a simple hardwire interface. After solving all these problems, we were ready
to _start_ integrating the equipment. Of course, by this time, the costs and speed of development were making management very unhappy. The
development on the proprietary PLC wasn't nearly done and there was more for the proprietary SCADA. After about a year They threatened to
pull the plug.
I enhanced a simple PLC demo that I had written for LPLC, designed and built some hardware to interface a ttl IO card to 24 volt levels and wrote the additional code for my vision box to do the cell control. The GE PLC went away, the SCADA went away and two an a half months later we are installing. None of the work was difficult to
research or do, there were no secrets or nasty proprietary roadblocks and progress was quick enough to turn around the attitudes of the powers
that be which was important to our future.
I don't make this stuff up. Getting the off the shelf stuff to work can be difficult to impossible and very stressful. I was one of the
worlds happiest campers when we switched to software where I have some control. I still have to deal with the proprietary stuff, but at least
having one side open means you can cope. We wrote no more checks and have not had to go outside our company to finish the project.
If the other machines were running say, EMC from NIST on Linux, this would have been a two week project. And EMC would do the job.
I have been asked "Explain again why we are using all that expensive stuff"? I have no answer.

There are two sides to every story, I invite GEF to provide theirs.

Regards

cww
 
J

John Waalkes

> So it's a couple minutes past six in the morning and I'm reading John
> Waalkes' comments about GM, AB, and "hostage-taking" as a metaphor for
> support and technical innovation.

"Support and technical innovation"? That's one way of putting it.

Listen, I'm not out to break anybody’s rice bowl, but I don't think that my complaints are that out of line.

It's a short list so I'll get right to it:

1) We want to use an operating system other than Microsofts. It's a reliability thing. Go to www.netcraft.com if you don't believe me.

2) We want the manufacturers of our PLC's to listen to us when we uncover that rarest of critters -- the bug. So you are going to insist that you fix things yourself, then at least be prompt about it. The same goes for new features.

3) And take a look at AutomationDirect when you get the chance, they have innovated prices down to what people can afford.

> I'm sitting in a motel on the coast, 320 miles from my office, with my
> hardhat and Carhartt on the chair next to my trusty Dell laptop, my
> ordinary ZIP drive archive system, and an interface card to an open network
> protocol administered by an industry committee. I got here at 11 last
> night to teach a class first thing this morning to some maintenance
> personnell about using their networked motor starters to improve the
> reliability of their pumps, conveyors, and other ordinary mill equipment.
> The mill isn't paying for this class; the consultant that they pay to
> improve their material efficiency is doing so.
>
> I'm using proprietary software that I downloaded from a closed Internet
> site using my license key.

Did you pay for these things out of your own pocket? I'm guessing no.

> And here I find that really what I do for the living is suck blood out of
> GM and hold them into sluggish committee standards because I'm a leech and
> a moron. Thanks, I had no idea it was that easy. I'll be certain to lay
> down my earplugs and meter this afternoon and put another hitch in the
> tourniquet I have around the arteries of my customer's purchasing
> department.

No, it ain't your job, this is what the sales guys are for :) So don't take it personal.

> When I go into the mill this morning, we'll be using Microsoft operating
> systems because we know we both have the components needed to run the
> application; they weren't optional in the distro.

Which service pack will you be using today?

> We'll be using a major-brand PLC and major-brand motor controls because
> they're available in a store an hour away by car, not "overnight" via
> FedEx from a web dealer in Florida. The PLC manufacturer has been in
> business slightly longer than the mill we're servicing... since about
> 1903, not 1993.

That's hilarious! We wanted to build a couple of trainers two months ago, we're still waiting on parts.

> One of these nights, I'm going to try a little experiment... I'm going to
> go into a bar near one of these mills and ask around the fellows playing
> pool under the Budweiser light if they can compile a kernel. And then I'm
> going to drink some of that Budweiser and go back to the hotel and not have
> to mess with my operating system to get it to support my archive drive...
> because I paid $210 for it.

Okay, but to be fair, limit yourself to guys that know which version of a .dll works for any given program.

And you paid $210 for Linux?

> Lay off the venom about the big mean technology monopolies. You might
> find that there are some good engineers and honest support technicians
> working there.

I don't remember picking on engineers and techies, just the company you work for. Once you make that distinction, it's easier to look upon my comments with objectivity.

If you don't realize that there are disgruntled customers out there, then I would say that you haven't been listening.

The real issue here is: fear.

It's the fear of what's going to happen when a company can no longer lock their customers into their hardware.

It's the fear of losing their monopoly.

The last thing that any company in this position can allow is to have their products treated like a commodity.

So I don't blame them for being scared to death.

John Waalkes
Saturn Corp.
[email protected]

 
J

Joe Jansen/ENGR/HQ/KEMET/US

An interesting aside: Several years ago (well, like 4 or 5, anyway) I was working for a Fanuc robotics integrator. We had a small, in-house project to try to get GEF 90-30 series PLC's to talk to the robots. The new line of controllers had just come out, and the I/O rack had been redesigned with the 90-30 style I/O. Since many of the I/O module were interchangeable, we figured the backplane comm's must be similar. We also realized that the left-most module (I/O controller) looked just like the link-coupler for the PLC.

Long story short: A few days of hacking, and we had a 90-30 with a link coupler tied into the I/O loop of the robot. The robot's I/O space worked
just like a shared memory pool, in that we could read/write bits from either controller.

What probably elevated this from normal integration to shining moment, however, was GEF's attitude. I would call them from time to time to ask for specs, etc. Throughout the whole project, they disavowed any relationship between the two I/O systems. I was told, quite emphatically, that I was wasting my time, it was impossible to do, and I should just stop messing around with it. Not a direct quote, but all the sentiment was the same. Basically: It won't work. Stop doing that now.

This continued even after I told them I had a working demonstration of it. They refused to send out field reps, because I had to be making it up, since it "wasn't physically or technically possible to get the two systems to interoperate". I suspect this was to try to keep selling the overpriced Genius expansion boards for the robot.

Sad, really, the extents they would go to in order to protect their secret.

--Joe Jansen
 
R

Rick Jafrate

Curt,

You hit the nail on the head when you commented on the lack of ability of traditional PLCs to communicate. I have found that it is very difficult to get traditional PLC's to talk to themselves not alone other PLCs or controllers, or computers. As you have said (implied) below once it's on Linux it can talk to anyone.

Curt Wuollet wrote:
>
>You don't appreciate what I do, I think. I have spent the last two weeks
> in a fiendishly hot and humid environment putting the finishing touches
> on a system that is built with OSS and some my own code. Why would I do
> this with all that wonderful "off the shelf" equipment available? Well,
> because I was asked to after the attempt do it with said equipment cost
> a small fortune and got bogged down by intrigueing little details like:
> Fanuc lathe controls won't talk to Fanuc Robots which won't talk to
> Fanuc PLC's. The only common means of talking amongst them is RS232.
> This wouldn't be too bad if they were actually designed to integrate in
> any way shape or form, but they're not.

Most of my clients' facilities are like museums, they have numerous examples of technology from all previous ages. They only difference is that they are still using the old stuff to make production. The Linux PLC offers the hope of cost effective means of upgrading these systems so that they can commmunicate with each other and the rest of the plant.
 
Rick,

Just curious, not trying to sway your opinion.

What do you think about modern control devices, like PLCs, that support TCP/IP on standard Ethernet? Do you have trouble communicating with these devices? I think the argument here is with the lack of standard protocols and not with the architecture of the PLC or other control device.

Sam
 
J
> Long story short: A few days of hacking, and we had a 90-30 with a link coupler tied into the I/O loop of the robot. The robot's I/O space worked
> just like a shared memory pool, in that we could read/write bits from either controller.

Cool, I wondered how similar these devices were. Other than one being yellow, and the other black, I can't see too much difference.

Any chance you would care to share how you did this? :)

[email protected]


> What probably elevated this from normal integration to shining moment, however, was GEF's attitude. I would call them from time

I can only imagine :)

I got much the same response when after talking to a GE engineer, I realized that doubling the memory on a Series Six was as simple as soldering a jumper back in where they removed it (GEF's 4k board is the same as their 8k board with the exception that one of the jumpers is removed on the smaller board)

The funniest part was when they looked me sternly in the eye, and said; "You know, we won't be able to support this"

Like my piece of wire was somehow inferior to theirs :p

John
 
J
> hello LinuxPLC skeptics and supporters,

Sorry Anand about hijacking your message.

But I would like to introduce myself and offer an apology.

For whatever it's worth, I'm John Waalkes, I work for that other car company as a Controls Engineer. Before that I did the road thing -- startups. I've hung out here for quite awhile, but prefer to lurk most of the time.

Around '95 I discovered linux, and even though it was impossible to use unless you were some sort of software physic, I stuck with it and eventually managed to use it more or less fulltime at home.

Since then it has blossomed into a fullfledged OS that is actually easier to install than Windows (YMMV). At least it manages to get everything done with just one reboot :)

Support for hardware has improved to the point where my Winmodem and goofy soundcard worked right out of the box. And I've read that it actually supports more hardware than WinNT does, for whatever that's worth.

Okay, so I'm a fan. We knew that.

So when I came across some posts that were written by by someone who obviously doesn't use linux, or has a clue as to what open source is -- or isn't, I got a wee bit miffed.

So I pounced on Mr. P.'s post with fervor :)

In doing so I never intended to insult or belittle anyone. But apparently I did, and for that I apologize.

And to set the record straight, while I don't agree with all of AB's policies, I do respect their service people.

I can say for certain that I have never had a bad service person from AB come out to assist me. They have all been knowledgeable of their equipment, and experts in their craft.

So again I would like to apologize, and if anyone has anything to add to this, please contact me directly. I would just as soon limit my involvment here to automation issues and not ideology.

Thank you,

John Waalkes
Saturn Corp.
[email protected]
 
I would agree totally! While many of the traditional protocols such as Devicenet and Profibus, are claimed as "open" by their supporters, the reality is that they aren't. On one level, technology transfer is not as simple of a task as hyped. On another level, it takes several manufacturers of peripheral devices, willing to adopt the many protocols that exist, to
be able to put together a complete system. Think of the challenge for these guys, to support so many protocols?

When using TCP/IP, you truly have an open architecture, supported not only on the factory floor, but all the way to the management suite! You are finding more and more suppliers jumping on this bandwagon, and experience has shown little to issue with interfacing devices from several manufacturers.
 
C
Just to give credit where credit is due, Groupe Schnieder _is_ doing the Open, sensible thing and tunelling their Modbus/TCP protocol in regular, STANDARD, TCP/IP on Ethernet. And that's a good thing and enhances compatibility with the real world. All of the other efforts I've heard about give you Ethernet which doesn't mean a damn thing if some off the wall, proprietary, protocols
take the place of TCP and IP. It becomes another brick in the Tower of Babel. A proprietary assault on the good name of Ethernet and an
effort to destroy compatibility not enhance it.

Scuse me for interrupting, Kudos to Modicon.

cww
 
R
Sam,

I guess I agree with you. The problem is that each vendor has their own protocol or flavor of standard protocol. They have little if any
incentive to be compatible with other PLC vendors. Many vendors are not even compatible with their own previous versions of equipment. This makes upgrading to new equipment difficult. In the case of most metal rolling mills the most
costly aspect of replacing the control system is the down-time incurred during commissioning. Not being able to communicate with the existing system
is not helpful in this respect.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Wow. SquareD seems to be getting active on this list! <grin>

Have you ever tried to use TCP/IP to communicate between two different brands of PLC? Still not possible. Sure, it is TCP/IP over cat 5 twisted
pair, or whatever physical layer of Ethernet you use, but the data *inside* the IP packets is still bastardized to the point of non-functionality. Don't beleive me? Try this:

From an AB SLC 5/05, initiate a message to a PC. Can't be done. I asked RS tech support why, and got some run around answer about not being
compatible with windows TCP/IP. Basically, you can only initiate the comms from the PC, be it a data send, or a request for data, and then not by
using standard networking calls, but using specialized calls thru an ActiveX or .dll specific to the brand and type of plc.

Try using the same SLC 5/05 to talk to a honeywell plc over ethernet. Same result. No talkie........

The problem is that all the vendors saw the demand for ethernet comms, so they obliged with a standard network stack up to the application layer. At that point, it all falls into the same infighting as the DeviceNet - ProfiBus - flavor of the weekBus breakdown that this industry is so good at.

Tell me this: If I need a dedicated computer to talk to the PLC's via ethernet and translate it into something usable by office apps via some
activeX control sold to me by the vendor for $800 - $1500 USD, why shouldn't I stick with a dedicated computer talking thru the proprietary
network to the PLC's and translating it into something useful using a similar Active X control? What have I really gained? Especially
considering the premium paid for a plc with an ethernet jack?

To me, it seems that at the end of the day, everyones implementation of TCP/IP is just as 'open' as Profibus and DeviceNet.

--Joe Jansen
 
I agree, and like Curt said Ethernet and TCP/IP alone is not enough. ModbusTCP is being used by some people to fill in the application layer
protocol.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

>> Long story short: A few days of hacking, and we had a 90-30 with a
>> link coupler tied into the I/O loop of the robot. The robot's I/O
>> space worked just like a shared memory pool, in that we could
>> read/write bits from either controller.

>Cool, I wondered how similar these devices were. Other than one being
>yellow, and the other black, I can't see too much difference.

>Any chance you would care to share how you did this? :)

It has been about 3 years or so, but as I recall, we put a slave module into the PLC rack, removed the I/O backplane from the robot, and placed the
PLC backplane into the robot controller. The screw holes don't quite line up, but we managed to make it work.

The robot CPU is the Link Master. configure the PLC link module just as you would if you were expanding the I/O in the robot, with the PLC taking the place of the main backplane.

I'm afraid I can't remember much beyond that. Really, it was mostly research thru the Fanuc robot manuals, buying some link controllers, and
just playing with it till it worked.

We did find some of the PLC modules were not compatible. These were the specialty modules tho. Digital I/O modules are completely compatible, and seem to cost a few hundred dollars less. Guess that yellow plastic is a
real value added component, no?

--Joe Jansen
 
J
> >> Long story short: A few days of hacking, and we had a 90-30 with a
> >> link coupler tied into the I/O loop of the robot. The robot's I/O

Thanks! I will pass this on to my partner who's in charge of the 'bots.

> We did find some of the PLC modules were not compatible. These were the specialty modules tho. Digital I/O modules are completely compatible, and seem to cost a few hundred dollars less. Guess that yellow plastic is a
> real value added component, no?

I'd add something to this, but I'm trying *real* hard to be good :)

Thanks again!

John

 
R

Rob Hulsebos Philips CFT

>When using TCP/IP, you truly have an open architecture, supported not only
>on the factory floor, but all the way to the management suite! You are
>finding more and more suppliers jumping on this bandwagon, and experience
>has shown little to issue with interfacing devices from several
>manufacturers.

An open architecture does not mean a workable environment. For example, I once had a system set up with several PLC's and a few HP/UX version 5 systems. In the old days, you couldn't exchange a PLC's Ethernet-controller without having to reboot all HP/UX's. This was necessary as they kept the 'old' PLC's MAC-address in their ARP-cache, which couldn't be reset without reboot ;-(
Hope that is better now....

Next, we once bought a TCP/IP stack from a well-known company for an embedded application. One reason we bought from them was the idea that since they had their stack so long on the market, it would be quite reliable and bugfree. Boy were we wrong. All sorts of bugs. For example, if we were to set up a TCP connection to a system which did not exist, the whole stack would hang. We patched this by (sort of) ping'ing to that destination via UDP first, and if we got an answer continue with the TCP connection. I know, a quick hack, but it worked.

Next, a more recent insight. How to set the IP-address on an Ethernet remote I/O box? One supplier might use switches, which is OK although cumbersome (need a lot of them for the 32 bits). Another supplier uses BOOTP and a third uses DHCP. Now imagine using them all on the same network... apart from the extra hub or switch one needs, suddenly I also have to install a BOOTP and/or DHCP server too. All extra sw, all extra single point of failures, and on which equipment do these servers run on? Suppliers that advise me "just add a Linux box" don't know how much this costs if you have to have 1000 of them (one per machine sold).

No, the architecture may be open, but life is not yet simple... it is not the architecture that counts, it is the implementation. We don't sell architectures. We sell working products.

Rob
 
C
Rob Hulsebos Philips CFT wrote:
>
> >When using TCP/IP, you truly have an open architecture, supported not only
> >on the factory floor, but all the way to the management suite! You are
> >finding more and more suppliers jumping on this bandwagon, and experience
> >has shown little to issue with interfacing devices from several
> >manufacturers.
> An open architecture does not mean a workable environment.
> For example, I once had a system set up with several PLC's
> and a few HP/UX version 5 systems. In the old days, you couldn't
> exchange a PLC's Ethernet-controller without having to reboot all
> HP/UX's. This was necessary as they kept the 'old' PLC's MAC-address
> in their ARP-cache, which couldn't be reset without reboot ;-(
> Hope that is better now....

Where is the world did you get the idea that HP/UX was open? If it was,
you could know the cache strategy and override it. I'm pretty sure that
Linux will let you clear the cache withoug a reboot. This is also a
programming issue. Shouldn't be a problem now.

>
> Next, we once bought a TCP/IP stack from a well-known
> company for an embedded application. One reason we bought from
> them was the idea that since they had their stack so long on the
> market, it would be quite reliable and bugfree. Boy were we wrong. All sorts
> of bugs. For example, if we were to set up a TCP connection to
> a system which did not exist, the whole stack would hang. We patched
> this by (sort of) ping'ing to that destination via UDP first, and
> if we got an answer continue with the TCP connection. I know, a
> quick hack, but it worked.

Again, this was a proprietary stack. The Linux stack and the ECOS stack
are both Open Source and viewed and critiqued by thousands more eyeballs
than any single company. This is the most important way that Open Source
produces better software. The bugs in a networking release get fixed fast
as networking is fundamental to the apps people are building on Embedded
Linux. What you are mentioning is the problem, not the solution.

>
> Next, a more recent insight. How to set the IP-address on an
> Ethernet remote I/O box? One supplier might use switches, which
> is OK although cumbersome (need a lot of them for the 32 bits).
> Another supplier uses BOOTP and a third uses DHCP. Now imagine
> using them all on the same network... apart from the extra
> hub or switch one needs, suddenly I also have to install a
> BOOTP and/or DHCP server too. All extra sw, all extra
> single point of failures, and on which equipment do these
> servers run on? Suppliers that advise me "just add a Linux box"
> don't know how much this costs if you have to have 1000 of them
> (one per machine sold).

I happen to agree with you on this one. There should _always_ be a way
to configure without a host. BOOTP is going away and DHCP can be an
option for a managed network, but it's inexcusable to require a host,
especially a particular host, for configuration. A terminal perhaps,
but not a fully configured host with xxx.yyy and zzz rev 17 set up
the same way as in our factory. That's unreasonable. I've had to
spend a day and a half finding and fixing, and rebooting and
reinstalling a Windows box to configure Ethernet IO that should have
been a 2 minute job. And next time I'll have to do it all over again.

>
> No, the architecture may be open, but life is not yet simple...
> it is not the architecture that counts, it is the implementation.
> We don't sell architectures. We sell working products.

You haven't had the option to work with a truly Open sysstem. You have
the same problem I do. These products advertise they are open but they
are not open enough to benefit the user. It's all marketing. That's why
we are working on a TRULY OPEN system. None of these things would have
been a problem if you could look under the hood.

Regards

cww

>
> Rob
 
Top