> The mistake I made was driving the business by the selection of the
> technology. There was no question that UNIX was better. I
> think that Linux is better at core operating system functions than NT.
> However, *for me* this benefit is purely technical and if you look at the
> entire picture NT is the way to go.
>
> Just an opinion.

You've mentioned about your various experiences with companies obsolescing computers/OSes that you were using. Then you turn around and say "NT is the way to go". Firstly, NT is two revs back now for Microsoft. Most companies haven't even upgraded to Windows 2000 yet, and they're going to start jamming Windows XP down our throats.

Once again, I'd like to point out the product activation features in Windows XP. If you change hardware too much (like, say, for maintenance), the thing wants you to call Microsoft and get it approved. Combine this with their recent push to make their customers upgrade sooner, and I can foresee some very unhappy situations for people on the plant for at two in the morning. Looking from a non-technical perspective, Microsoft stuff isn't the right choice.

Here's the other kicker: Embedded Linux is going to be huge. You guys will be using Linux in your PLCs, motion controllers, HMIs, etc etc, and never
even knowing it. Montavista (www.mvista.com) and Lineo (www.lineo.com) have put together distributions, a support system, and runtime license requirement that absolutely put Windows CE to shame. There are variants of Linux like uCLinux (www.uclinux.org), which can run on little ARM processors without an MMU. I can grab ALL this stuff for free (or very low cost), take
a PC with Red Hat Linux on it and do my development, and kick an embedded device out the door with a fraction of the resources that it would take to do any other way.

Linux WILL be used in Automation.

 

At 12:07 12/07/01 -0400, Sam Moore Square D Company/Groupe Shneider wrote:
<clip>
>Depending on the project we may specify an interface of
>ModbusTCP, OPC or SQL.We use a COM object at the ModbusTCP interface point.

If you specify a ModbusTCP interface, then the operating system doesn't matter, true? A Modicon PLC would interface just as easily.

>Once you have the data in the NT environment, COM, then it is very easy to
>drive the data into desktop applications or custom applications that we
>have written.

>If we used Linux on the plant floor then we would have automation software
>tools to pick from. It would not be feasible to try to get the data
>directly into COM. We would then drive the data into an SQL server and
>access it from the NT desktop. This is an okay arrangement it is just less
>flexible.

I think you've skipped over the part I actually wanted to discuss. That is, once the data gets out of the machine, where does it go? I see two choices. The first is that it goes to one or more servers which are dedicated to providing the interface between the plant floor and the office systems. The second method is to allow the office systems to interigate the machines directly without an interposing layer.

The first method allows the administration and configuration of the data communications to be handled from a single point. It also allows you to separate the logical production process layout from the physical
configuration of the equipment which is used to implement it. The logical and physical layout should be separated to prevent building any unecessary assumptions into your data systems on how the plant is arranged. Derived values (e.g. efficiency and first pass yield) are also more properly centralised at this server.
The interposing servers are more correctly viewed as part of the office systems, rather than the plant systems. Therefore, the operating systems, data base, and other such factors would be selected for how readily they interface to the office systems. I would also place control of this hardware in the hands of whoever is responsible for the office systems.
Since this data server should be capable of communicating with the plant equipment in whatever protocol is required, the actual control
hardware can be selected to best suit the application. If for example, I believed that the best hardware to control the machines on a production line was Modicon PLCs, then I could use them. The problem of connecting the plant to the server has been solved for some time now.

The second method (direct communications) would get very messy and difficult to maintain unless your plant was very small and simple. Do I
really need to describe what I think all the problems with this method are?

>If I used Linux on the desktop I would probably use it on the plant floor.
>I drove a company to use UNIX on all desktops. The first was the
>DECstation. DEC discontinued the architecture after a couple of years. I
>then standardized on SPARCstations. I then switched to Linux and then very
>soon after that I switched to NT.
<clip>
>The mistake I made was driving the business by the selection of the
>technology. There was no question that UNIX was better. I think that Linux
>is better at core operating system functions than NT. However, *for me*
>this benefit is purely technical and if you look at the entire picture NT
>is the way to go.
>Just an opinion.
<clip>

You said "The mistake I made was driving the business by the selection of the technology". I think you are still making the same mistake,
just with Windows NT instead of Unix. I don't think there will ever be a situation where there is one best software solution to all problems. With modern communications technology, this is also completely unnecessary.

 

Sam,

I think this is Michael's point.

In at least one or two of the Modicon range, you have a 486 processor. Does this make it a "computer"? If so, do you want it to run an "OS"? Surely not. If you buy a machine with packaged control system, that has been running successfully in other applications with hardware system X, would you specify a new version with all its uncertainties for system Y. I know some people do, but in my experience there are always some teething troubles - as when someone who has spent 5 years programming Modicon has a go at converting the program to AB.

I think the Windows for automation argument is a bit like saying "Our accountants use red pencils for all their work so every pencil we buy has
to be red". The PC as a consumer commodity and an office commodity has found its way into an industrial environment. Most PC's come pre-packaged with an OS - Windows - and there is then a resistance to replacing it with another - but that's getting back to the monopoly argument.

Bottom line question - what is the highest priority for your control system - to keep the plant running or to pass numbers to the bean counters? If the first, I woulf think very hard before using Windows in any flavour as a basis - if the second, it's probably theoir call - but let's put up a big fat wall so that my controls system is not adversely affected by decisions
made for management information.

 

<clip>
Linux is not very tough. Try installing Linux, Red Hat Installation (i would recommend 7.1 as i have used it), it is a cake walk.
</clip>

I like playing with Linux. But every version since 5.X has not been a cake walk -- including 7.1. Everything from PCCard support to DVD Support and even graphics support has required extensive browsing on the web (after booting to Windows) to find "HowTo Documents" and drivers et cetera. Even the graphics install mode has not always worked. Plus Disk Druid is a little bit cantankerous. I should also note that almost every driver I find is version "0.9" and does not always work. Some of the OEM drivers are
written in the programmer's spare time and offered with no support. Plus since I only use laptops, the laptop "HowTo" pages are not always helpful since the author's English is quite often very shoddy. Also you have to customise the laptop "HowTo" since they might have a slightly different flavour of laptop than you (e.g., a Dell i8000 with nVIDIA graphics versus a Dell i8000 with ATI graphics). I have been using Linux not because any customer has ever even mentioned it but because I thought I should be aware of it.

My 7.0 version actually "died" after using the RedHat upgrade ending (running on a Dell 7500). At that time, however, I ordered my 7.1 upgrade
and also upgraded my machine to a Dell i8000. I am currently in the "research" mode for i8000 where I am collating "HowTo" files to cover the
DVD, PCCard, nVIDIA graphics, network et cetera and i8000 "HowTo" documented -- all by booting to WinNT 2000. I should note also that OEM support for Linux RedHat (the preferred flavour on the Dell) always seems to be in catch-up mode; I suspect this is a case of complete the Win2K and
WinXP drivers (or was that dribble) first and then write Linux.

Disclaimer: I am not implying that WinNT 2000 is better than Linux. I just happen to have better luck with it on Dell laptops than the RedHat Linux.

RJ

 

[email protected] wrote:

> What I have found is that NT integrates with NT better than Linux does. I
> have also found that if I have two operating systems to support then I need
> two talent pools. Is that understandable?

Ok, So why is it written in granite that NT is indispensible? I find that Linux integrates better with everything else than NT does and so do
you if you have worked with it. The exception to integration is NT. It only integrates well with NT. I also find that with Linux you need a
smaller talent pool.

> I made a good living implementing UNIX and Linux solutions. But once I gave
> NT a fair chance I found that it worked well. And, by using it I had the
> luxury of having so many software and hardware options that my life was
> made much easier. I also believe that the ability to interface with the
> enterprise is highly important. No, I don't think the CEO needs to see the
> status of a sensor. I never said that. I said that I find that NT provides
> me with a less expensive, more robust interface to the enterprise.

This is limited to the case where the enterprise system is NT. I'll take robustness at face value. Doubtless, NT works better with NT and the means are secret to ensure that. That is a poor substitute for cross platform compatibility which is what is really useful.

> I see
> NT, the software tools that are available today, and TCP enabled devices as
> a much needed key to closing the supply chain loop through the plant floor.

Once embedded in TCP/IP packets, if the top level protocol isn't secret, proprietary and non-standard, it shouldn't matter what the host runs.

(Personal comments deleted at request of moderator)

Perhaps you can rationalize the use of a poor engineering solution for compatibility's sake, but that doesn't make it a good engineering
solution. It's professionalism, not emotion. I can't declare bad to be good on the basis of popularity, that is marketing not engineering.

> That's the way I was when I tried to change
> the world to UNIX, so I understand what you are going through.

It is a shame that you capitulated so soon.

I was there for the first go round with UNIX. Proprietary excess destroyed most of the value and disintegrated the market. We have learned from that and got it right this time with the GPL. Some companies and other entities didn't learn from history and are doomed to repeat it. The automation industry is a prime example of proprietary balkanization.

Regards

cww

 

> > Even for you this is sort of unfair. It would be pointless to compare
a
> > system that is actually usable by virtually everyone to a system that
can
> > only be used by a very small group of very skilled people.
>
> Actually, it is unfair to continue spreading the FUD that our system is
> only usable by gurus. No basis.

So you currently have a usable RLL system in place? Until you have this and a way to do online programming you have nothing usable for GP automation in the real world.

>
> > The ABs of the
> > world are not competing against Linux, because its really no
competition
> > right now. The cost-benefit ratio is so far towards AB (at least for
> general
> > purpose PLCs) that it would be like comparing an ox cart to a modern
> diesel
> > truck.
>
> More FUD, no basis.

No. Its real. At present you have an idea, but nothing else. When you have a product that is usable then maybe you can get some of the PLC market. But you have to have a PLC first, which you do not have. And I would guess will not have any time soon.

>
> > Until there is a softplc like piece of software that runs on Linux, AB
> does
> > not have to worry about the tiny little piece of the market that they
are
> > losing to Linux.
>
> That much is true, but we weren't talking about what AB worries about,
> we were talking about the availability of objective information. The
trade
> press is demonstrably and obviously biased towards solutions that
> involve advertisers.

And it surprises you that this is the case? After watching such stalwart news organizations such as CNN, NBC, CBS, ABC, the NY Times, et al, stick by the most corrupt and venal president the nation has ever had? The fact that the trade press is more open about its biases should not surprise you at all.
And quite frankly they make no effort to hide the fact that they do not compare every possible solution, or solutions that might exist at some
future date.

Bob Peterson

 

At 12:07 12/07/01 -0400, Sam Moore Square D Company/Groupe Shneider wrote:
<clip>
>Depending on the project we may specify an interface of
>ModbusTCP, OPC or SQL.We use a COM object at the ModbusTCP interface
point.

Michael Griffin wrote:

MG- If you specify a ModbusTCP interface, then the operating system
MG- doesn't matter, true? A Modicon PLC would interface just as easily.

-> Agree and the PLC is a good choice in a lot of cases (opinion)

>Once you have the data in the NT environment, COM, then it is very easy to
>drive the data into desktop applications or custom applications that we
>have written.

>If we used Linux on the plant floor then we would have automation software
>tools to pick from. It would not be feasible to try to get the data
>directly into COM. We would then drive the data into an SQL server and
>access it from the NT desktop. This is an okay arrangement it is just less
>flexible.


MG- I think you've skipped over the part I actually wanted to
MG- discuss. That is, once the data gets out of the machine, where does it
MG- go? I see two choices. The first is that it goes to one or more
MG- servers which are dedicated to providing the interface between the
MG- plant floor and the office systems. The second method is to allow the
MG- office systems to interigate the machines directly without an
MG- interposing layer.
MG-
MG- The first method allows the administration and configuration of
MG- the data communications to be handled from a single point. It also
MG- allows you to separate the logical production process layout from the
MG- physical configuration of the equipment which is used to implement it.
MG- The logical and physical layout should be separated to prevent
MG- building any unecessary assumptions into your data systems on how the
MG- plant is arranged. Derived values (e.g. efficiency and first pass
MG- yield) are also more properly centralised at this server.
MG- The interposing servers are more correctly viewed as part of
MG- the office systems, rather than the plant systems. Therefore, the
MG- operating systems, data base, and other such factors would be selected
MG- for how readily they interface to the office systems. I would also
MG- place control of this hardware in the hands of whoever is responsible
MG- for the office systems.
MG- Since this data server should be capable of communicating with
MG- the plant equipment in whatever protocol is required, the actual
MG- control hardware can be selected to best suit the application. If for
MG- example, I believed that the best hardware to control the machines on
MG- a production line was Modicon PLCs, then I could use them. The problem
MG- of connecting the plant to the server has been solved for some time
MG- now.
MG-
MG- The second method (direct communications) would get very messy
MG- and difficult to maintain unless your plant was very small and simple.
MG- Do I really need to describe what I think all the problems with this
MG- method are?


-> I basically agree, but the line between the office and the automation is
blurred. For instance
-> you will have PCs on the plant floor for people to schedule work and do
other types of planning
-> and analysis work. You don't just have PLCs in the plant and PCs and
servers in the office.
-> If you use PC based control or PCs for supervisory control, even if you
use PLCs, then
-> you have further integration of the PC with automation.
-> You can slice and dice it anyway that you want, but for me the the
computer, PC, has become
-> an integral part of the automation picture. And, for me, it makes sense
to leverage the workforce
-> that I have for maintaining the office systems to maintain the PCs on
the plant floor. Other people
-> may have had a bad experience with people that support office systems,
but I have found that you
-> can get people that are capable of supporting the computes on the plant
floor. This does not mean that
-> you will not need PLC expertice, possibly, if you have a lot of PLCs. On
the otherhand your PLCs may
-> not need a lot of support. Like I said, this is my experience, I am not
suggesting that other ways
-> of doing it are not good for other people.

>If I used Linux on the desktop I would probably use it on the plant floor.
>I drove a company to use UNIX on all desktops. The first was the
>DECstation. DEC discontinued the architecture after a couple of years. I
>then standardized on SPARCstations. I then switched to Linux and then very
>soon after that I switched to NT.
<clip>
>The mistake I made was driving the business by the selection of the
>technology. There was no question that UNIX was better. I think that Linux
>is better at core operating system functions than NT. However, *for me*
>this benefit is purely technical and if you look at the entire picture NT
>is the way to go.
>Just an opinion.
<clip>

MG- You said "The mistake I made was driving the business by the
MG- selection of the technology". I think you are still making the same
MG- mistake, just with Windows NT instead of Unix. I don't think there
MG- will ever be a situation where there is one best software solution to
MG- all problems. With modern communications technology, this is also
MG- completely unnecessary.

-> I respect your observation, but I believe what I am doing is what the
industry is doing on a whole. There
-> is a general movement from specialized technology to off-the-shelf
technology. It is happening at the
-> data networking layer. It is happening at the software application
layer. It is happening at the operating
-> system layer. Actually, MS operatings systems may have always been found
more often on the plant floor
-> than UNIX.
-> What I am doing is trying to standardize on technology and sometimes I
may not get the best technology, but
-> it makes sense because it cuts down on the total cost of ownership.
-> When I read, "With modern communications technology, this is also
completely unecessary." I am reminded of the early -> 80's when "open
systems" meant we would have dosens of operating systems and a common data
communications
-> network will make life good.
-> I believe that if you follow that approach you will end up with a lot of
different types of technology
-> and you support burden will be higher than it should. People often say,
"Oh it doesn't take much to learn
-> how to support this operating system or that application.." For every
new piece of technology we have to
-> support we compound the support costs.
-> Again, that is my experience, but there might be a situation where
having a lot of diferent technologies is
-> a more cost affective plan.

 

Bruce Durdle wrote:

>Sam,
>
>I think this is Michael's point.
>
>In at least one or two of the Modicon range, you have a 486 processor.
>Does this make it a "computer"? If so, do you want it to run an "OS"?
>Surely not. If you buy a machine with packaged control system, that has
>been running successfully in other applications with hardware system X,
>would you specify a new version with all its uncertainties for system Y.
>I know some people do, but in my experience there are always some
>teething troubles - as when someone who has spent 5 years programkjing
>Modicon has a go at converting the program to AB.

-> I agree you can't always specify the PLC or the operating system.
Nevertheless,
-> you should have a standard. You work out with the vendor what makes
sense.

>I think the Windows for automation argument is a bit like saying "Our
>accountants use red pencils for all their work so every pencil we buy has
>to be red". The PC as a consumer commodity and an office commodity has
>found its way into an industrial environment. Most PC's come pre-packaged
>with an OS - Windows - and there is then a resistance to replacing it
>with another - but that's getting back to the monopoly argument.

-> If the red pencil will work for other groups then why not use it? It is
-> like Lean Manufacturing. You can say that you are going to be lean and
-> try to implement just one aspect, like kanban, but unless you push for
-> enterprise-wide lean processes then you are not going to be a lean
-> enterprise.
-> If your plan is to optimize each local function, or to have no plan
-> regarding technology standardization then you have a very good chance
-> of ending up with a lot of different types of technology to support
-> and barriers between support organizations like (automation and IT).
-> What I try to do is look at the entire value stream that runs through
-> the plant (automation) and develop a system that satisfies local
-> requirements (like automation), but it optimizes the entire flow.

>Bottom line question - what is the highest priority for your control
>system - to keep the plant running or to pass numbers to the bean
>counters? If the first, I woulf think very hard before using Windows in
>any flavour as a basis - if the second, it's probably theoir call - but
>let's put up a big fat wall so that my controls system is not adversely
>affected by decisions made for management information.

-> If you can't make a technology work then don't use it. I believe you
-> can deliver reliable control systems and close the supply chain loop
-> that goes through the plant floor. I believe that NT and other
-> technologies we have available to us allow this to be done where
-> it was not feasible in the past.
->
-> I am not proposing that NT replace all control systems. I have
-> found that NT is the best operating system to use when you use
-> computers in and around controls. There are times when it makes sense
-> to use a PLC. There are times when it makes sense to use PC-based
control.
->

 

Hi Ranjan

To be fair, a lot of the problems with peripherals are with very new
hardware. Many hardware vendors, including silicon vendors release
windows drivers, period. This is slowly changing as Linux users become
a economic force to be reckoned with. The community still provides most
of the drivers, while hardware vendors will actually pay Microsoft to
get their drivers included. Without getting back to the DOJ thing, this
is a very, very slanted playing field and I think the Linux folks do a
fantastic job providing the coverage they do. As someone who has tried
long and hard to even get chip vendors to release enough documentation
to write a driver, I think very few people understand the barriers that
Linux developers have overcome to achieve near parity with Windows on
peripheral support. Your dissapointment with Dell is shared by many in
the community as they have wavered in their support of Linux. IMHO they
were chiefly interested in Linux to get some leverage with Microsoft.
Still, I have a Dell laptop ( an old cpi d266xt ) and had a flawless
install with RH6.2. The bright spot has been IBM. They are backing up
their commottment to Linux with serious support and you can get PC's
and laptops that will run Linux out of the box, although you will still
probably pay the Microsoft tax and end up with a Wxx drink coaster when
you install Linux. I would suggest that folks who want to run Linux on
their new laptop do some research first. They will all run Wxx, but some
use software modems and software audio which are very difficult to
support in a free and open OS as the software is secret and proprietary
and Windows only. Desktops and servers are much less proprietary and
coverage is very good although there is still some Winjunk (software
modems, printers, and audio) foisted on the public. Most vendors will
replace them with real modems, etc. if you make a point of it. I build
generic machines and Linux loves them, I haven't had a real issue with the
last 50 or so and I avoid the Microsoft tax. In fact, the discards of the
Windows crowd, the machines that won't run the latest and greatest from
Redmond are a rich and easy to justify source of general purpose Linux
boxen. A 300 mhz K6 or Pentium is great plenty with 64mb of RAM. You
would never know its a second class machine unless you play games.

Regards

cww

 

[email protected] wrote:
>
> In a message dated 7/12/01 12:30:52 PM Central Daylight Time,
> [email protected] writes:
>
> > >
> > > Even for you this is sort of unfair. It would be pointless to compare a
> > > system that is actually usable by virtually everyone to a system that can
> > > only be used by a very small group of very skilled people.
> >
> > Actually, it is unfair to continue spreading the FUD that our system is
> > only usable by gurus. No basis.
>
> So you currently have a usable RLL system in place? Until you have this and
> a way to do online programming you have nothing usable for GP automation in
> the real world.

In your opinion. Actually systems other than RLL are doing just fine in
the "Real World". But, I agree that we need RLL soon. I am also certain
that someone has written the tools and has them gathering dust. We could
really use contributions of this sort, even if they need to be ported. I
expect chunks of this kind to be contributed along the way and they could
greatly accellerate our progress. I prefer C logic myself, but that's
because I like the language. When I get done with the Linux machining cell
we brought up this week, I may even take a shot at RLL tools. This is
something I want to do but have been too busy with Linux based automation
to start.

You would have a hard time convincing the president of our company that
Linux in automation isn't viable and very real. It saved this project
from the big losses column.

> > > The ABs of the
> > > world are not competing against Linux, because its really no competition
> > > right now. The cost-benefit ratio is so far towards AB (at least for
> > general
> > > purpose PLCs) that it would be like comparing an ox cart to a modern
> > diesel
> > > truck.
> >
> > More FUD, no basis.
>
> No. Its real. At present you have an idea, but nothing else. When you have
> a product that is usable then maybe you can get some of the PLC market. But
> you have to have a PLC first, which you do not have. And I would guess will
> not have any time soon.

It runs. We are approaching a developer's release, soon. Guess again.

>
> >
> > > Until there is a softplc like piece of software that runs on Linux, AB
> > does
> > > not have to worry about the tiny little piece of the market that they are
> > > losing to Linux.
> >
> > That much is true, but we weren't talking about what AB worries about,
> > we were talking about the availability of objective information. The trade
> > press is demonstrably and obviously biased towards solutions that
> > involve advertisers.
> >
>
> And it surprises you that this is the case? After watching such stalwart
> news organizations such as CNN, NBC, CBS, ABC, the NY Times, et al, stick by
> the most corrupt and venal president the nation has ever had? The fact that
> the trade press is more open about its biases should not surprise you at all.
> And quite frankly they make no effort to hide the fact that they do not
> compare every possible solution, or solutions that might exist at some future
> date.

Nope, didn't surprise me at all. What is unfortunate is that, to hear some
folks, all that is gospel. Many of the very strange and obviously wrong
things that I read here come from these partisan organs. We probably agree
on the general news media, but that is politics.

Regards

cww

>
> Bob Peterson

 

Bob Peterson:
> > > Even for you this is sort of unfair. It would be pointless to compare
> > > a system that is actually usable by virtually everyone to a system
> > > that can only be used by a very small group of very skilled people.

Curt Wuollet:
> > Actually, it is unfair to continue spreading the FUD that our system is
> > only usable by gurus. No basis.

Bob Peterson:
> So you currently have a usable RLL system in place?

Currently we personally only have mnemonics, and basic ones at that.

http://mat.sourceforge.net/manual/logic/il.html

However, other people, such as National Instruments with their LabView,
have systems that run under Linux with no problem. As far as I've gathered
it is no more difficult to set up and administer under Linux or under
Windows.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

 

---------- Forwarded message ----------
From: [email protected]
To: [email protected]
Subject: Re: SOFT: M$ vs Linux in Automation

[email protected] writes:
> However, other people, such as National Instruments with their LabView,
> have systems that run under Linux with no problem. As far as I've gathered
> it is no more difficult to set up and administer under Linux or under
> Windows.

Having had some basic expereince with labview I can tell you it is hardly a
good substitute for a general purpose PLC. It does some incredible things in
its own right I will grant, but it cannot even come close to doing the
control work of a PLC. of course, there is no way a PLC could do the things
Labview does in a heartbeat. They are completely different animals.

Bob Peterson

 

You are correct in stating LabVIEW and a PLC are completely different animals, one is hardware and the other is a programming language. But I would argue that LabVIEW is not capable of doing PLC-type control work. Once you have married LV to real-world I/O via Modbus, TCP/IP, GPIB, DeviceNet, I2C, Fieldbus, register level PC-104 (or any other protocol/hardware combination you could think of) the language is more than capable of handling simple PLC functions and a lot more. Want it robust? Load it into ROM on an embedded Linux SBC.


Alan Brause

 

Curt, the point is that I don't see a need for another operating systems.
You obviusly do. Like I said in my first posting on this latest thread of
the operating system wars (Hey, anyone watch the junk yard wars? That would
be better to talk about.) is that we have said enough on this subject.
Let's let the issue of the operating system go. Unless our concern is to
change everyone's mind then we aren't accomplishing anything. I say that I
can use one operating system in the entire enterprise and provide a
solution that works. You say that is impossible and that people need to use
Linux. We disagree. I believe that everyone on the list is capable of
figuring this one out. Let's give the subject a rest.

 

[email protected] said:
>>Like I said in my first posting on this latest thread of
>>the operating system wars (Hey, anyone watch the junk yard
>>wars? That would be better to talk about.) is that we have
>>said enough on this subject.

Yes. Junkyard wars is absolutely the best 'trash' on television (as they say)! And it's certainly a topic more interesting than continual OS wrangling. If only the OS wars were hosted in such an environment... but then there are those that prefer the Thunderdome approach... "Two OS's enter, one OS leaves." I just believe "We Don't Need Another Hero". (Now, I'll do everyone the favor of leaving the Mel Gibson/Tina Turner alone)

If you have not had the pleasure of watching a great television show made for engineering types, Junkyard Wars (Scrap heap Challenge in the UK) is a must see:
http://www.junkyard-wars.com/and
http://tlc.discovery.com/fansites/junkyard/junkyard.html
<Moderator's note: Okay, we're really off topic now... Any further
comments on Junkyard Wars, contact Jeff directly. --Jennifer>

Is Monday Over Yet,
Jeff

The best way to predict the future is to invent it.
- Alan Kay

 

The possibility of using one OS seems impossible today. This is because though the company's life could be in decades, the OS gets updated in less than years.
If we draw the life of MS WIN OS, we find that it is diminishing at an
exponential rate. If we extrapolate we soon arrive at a scene where the OS changes is days, ha.. ha.. ha...!!!

OS history:
MS win95 1995
MSwin 98 1998
Windows 2k 2000
Windows Xp 2001

Linux also has frequent updates.

Agree with the point that we have limited interest in the war of the OS's.

Anand

 

Silence has been all that's needed to get us into this situation.
I think it's unreasonable to think that it will change it.
I think Linux is a more robust and better OS to run even proprietary
tools on as well as a better engineering solution for automation tasks.
Isn't that what this list is about? This is your conduit into the
companies that build the products you use every day. I find it futile
to simply bitch about all the infelicities in tools and Windows problems
without proposing a solution. What's your solution?
If it weren't for silence and acceptance, there would be a far richer
and more diverse landscape, the Tower of Babel would never have been
and folks who produce buggy stuff would have a lot harder time selling
it. This list is the first step. Enabling users to communicate and share
notes publically saves others the work of finding all the bugs and
reinventing all the work arounds. How many millions have been saved by
a word of caution or a comment bad or good on the quality of a product?
We need a lot more communication on the issues and problems. I'm sure
you have benefited from it, I know I have.
Open is a serious issue. If it wasn't, you wouldn't have every automation
vendor paying lip service to the concept. Acceptance of empty words and
the parodox of "open" proprietary products and protocols will be as far
as it gets without producing any open products or protocols if silence
prevails. With a very few exceptions, all the hoopla about "openness"
has merely been a change in marketing strategy without any substance.
I, for one would like to see a little openness in exchange for enduring
the marketing barrage. _They_ said it, I didn't. When is it going to
start happening?

Regards

cww

 

Bruce Durdle <[email protected]> wrote:

<clip>

>-> If the red pencil will work for other groups then why not use it?
If the red pencil works, but the green one is better for one group then
why not use the green?


<clip>

>-> I am not proposing that NT replace all control systems. I have
>-> found that NT is the best operating system to use when you use
>-> computers in and around controls. There are times when it makes sense
>-> to use a PLC. There are times when it makes sense to use PC-based
>-> control.

It is probably one of the better (red pen), I don't privately
believe that it is the best (green pen). I am not entirely
sure Linux would be the green pen either but I think it have
a little bit higher chance ... but that is perhaps a little
bit in the future...
It does mostly depend on what you want to do, ie what you want
to control, what your sheduling criteria (ie how hard your
real-time requirements are), how bad a system down time is,
what you want to do more than control (HMI, communication,
statistics, whatever), and how (if) you want that distributed
among computers/PLC:s/...

I think there is a place for a lot of different alternatives,
and there will be for quite some years (ok the alternatives
will change over time, but there will still be many of them).


I have programmed mostly for windows platforms, I have need for
medium soft realtime. My applications are mostly for education
but they should work in real time, especially since they in many
cases are capable of simulating the PLC/PID/... and connect to a
real world process or the other way around (simulate the process
and connect to a real world controller). In my case nothing will
be blown to pieces if the computer crashes or if it takes too
long between two updates.
The "worst" case is at one site where we control a boiler, this
one could of course build up a too high pressure if the control
don't work, but as one teacher at the site said: It is good for
the education to excercise the safety valves occasionally.

This is why I can allow this to be running on plain windows,
actually even windows 9x as well as NT. But I would not like
to run a real plant on NT. I know there is extensions that make
NT a part of the control scheduler instead of the other way
around but that is a slighly different issue as I see it.

I am not sure I would like any more to run the control on
just any whatever linux installation either, but I see it as a
possibility in the future to have distributions and definitely
embedded in a pre configured PLC-style hardware. And as far as
I have heard there is more possibilities to have the scheduler
do what I want it to do (RTlinux and similar).


Ok here is much about possible future here, what about right now?
Well I guess it depends on the case but I personally think it is
quite equal in average.


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

[email protected] wrote:

>In the end we all have the same concern - making money. Your approach is
>to emphasize the differences between automated control and the rest of
>the enterprise. At the same time the industry is seeing the benefit of
>seamless I/O between controls and the rest of the enterprise. Your
>approach quickly >creates a separation between the enterprise and
>controls, because you limit the integration between the enterprise and
>controls by picking a different operating platform than the rest of the
>enterprise.

Just because they have different operating systems does
not men they can't comunicate with each other!
It does actually not even mean that it will be any more
difficult than it would be if they had the same os.


>The other approach is to try to make the same operating platform work for
>both worlds. The people that are successful at that get a huge gain,
>because they have a much tighter integration between controls and the
>enterprise. The cost of doing business is lower because there is less work
>required to integrate the information flow. The cost of support is less
>because there isn't a need to have a separate group of people to support
>the controls operating platform.

That might be right, but the first question: should
the same people support both systems? I am not sure
that actually is desireable since the knowlege about
automation isn't really the same as the knowlege about
office/file-sharing/mail/etc.


<clip>


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H=E4ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

Hi Bob,

But something like Labview, sharing a map with an embedded PLC would
be powerful medicine for a lot of solutions not served well by either
alone. The PLC would handle the parallel part and the Labview would
handle those things that are difficult or impractical to do with the
PLC alone. This is similar to the model I have found works wonders
for communications heavy integration projects and similar to what is
in the future for LPLC. No adding ascii modules or basic modules or
external systems to get the functionality needed to do the _whole_
project. Is that a step in the right direction? It has sure worked
well for me.

Regards

cww


[email protected] wrote:
>
> > You are correct in stating LabVIEW and a PLC are completely different
> > animals, one is hardware and the other is a programming language. But I
> > would argue that LabVIEW is not capable of doing PLC-type control
> > work. Once you have married LV to real-world I/O via Modbus, TCP/IP,
> > GPIB, DeviceNet, I2C, Fieldbus, register level PC-104 (or any other
> > protocol/hardware combination you could think of) the language is more
> > than capable of handling simple PLC functions and a lot more. Want it
> > robust? Load it into ROM on an embedded Linux SBC.
> >
> >
>
> Horse hockey. Try to get it to do the things that real PLCs (RLL) do very
> simply (like 100s of rungs of digital code that execute in parallel). Its
> completely unusable for this type of application. You are right that you can
> get it to do "simple" PLC type control, but anything past very simple and it
> becomes almost unusable and near impossible to debug.
>
> For sequential stuff, that has a defined beginning and ending, it is pretty
> good and its data collection features are just astounding. But the stuff
> that PLCs are really good at, it is terrible at.
>
> Bob Peterson