Where does MPI fit in?

R

Thread Starter

roger Irwin

Given Siemens dedication to Profibus, one would expect that the MPI protocol used to communicate with 300/400 series PLC's is based on the
profibus FMS transport.

None of the documentation I have either confirms or denies this proposition. I put the question to a local Siemens chap who said he does not know but it does not matter because all Siemens equipment can talk to each other using one protocol or another. Quite.

Well, suppose I had a 'generic' (i.e. non Siemens) profibus FMS device, could I do SEND/RECIEVE messaging with any 300/400 series PLC? Or the 200 series come to that, as they support MPI in addition to PPI.

Perhaps I am just being naive believing that 'a dedication to open protocol standards' means I can interconnect devices from different
manufacturers without expensive gateways;-)
 
C

Curt Wuollet

Hi Roger;

We were evaluating Siemens because of their fast Profibus networking. We eventually showed them the door because of this same issue. That and it was Windows or nothing for tools. When I asked about alternatives and protocol docs thay actually got angry. And I got the same line, "It doesn't matter" I would hope the lack of
business serves to inform them that it does matter, it matters a lot. We are acutely aware of the damage proprietary solutions do to our business in wasted time and reinventing the wheel. Why would we do that again? I hope to hold out with as few purchases as possible until the Linux PLC is viable, changing vendors is just
getting screwed all over again.

Curt Wuollet
Wide Open Technologies
 
M

Michael Griffin

At 00:14 03/10/00 +0200, roger Irwin wrote:
> Given Siemens dedication to Profibus, one would expect that the MPI
>protocol used to communicate with 300/400 series PLC's is based on the
>profibus FMS transport.
>
>None of the documentation I have either confirms or denies this
>proposition. I put the question to a local Siemens chap who said he does
>not know

Please note that the following is my opinion only. I don't have any special sources of information. I understand (unofficially) that MPI is actually sort of a subset of Profibus. I also understand that it is also a slightly different subset than what was implemented on S5 PLCs, which it turns out didn't really always talk true Profibus either. I believe that the intent of MPI was to provide a less expensive interface than full Profibus FMS for use as a programming port, connecting operator panels, limited networking between a few PLCs, etc.
My impression is that Siemens intends to keep MPI as a closed proprietary low end network. I suspect that this is to keep third party
hardware and software from being connected to their PLCs except in a manner which Siemens can control. Where MPI fits in is as a replacement for the old S5 programming port protocol.

>but it does not matter because all Siemens equipment can talk
>to each other using one protocol or another. Quite.

Of course you may have to use several different protocols over different networks at the same time. There is no one protocol which will
work with all Siemens PLCs at the same time.

>Well, suppose I had a 'generic' (i.e. non Siemens) profibus FMS device,
>could I do SEND/RECIEVE messaging with any 300/400 series PLC? Or the
>200 series come to that, as they support MPI in addition to PPI.

I was told that if I wanted to interface an S5 PLC to an S7-300 then I should use a Profibus CP module in the S7-300. I was also told to not mistake MPI for being a very capable network. Whatever the addressing limits may be, half a dozen nodes is the practical limit for typical applications. I haven't tried this for myself to confirm it.

The S7-200 series supports MPI as slave nodes only. They also have a Profibus DP slave module (i.e. PLC is a DP slave via module).


>Perhaps I am just being naive believing that 'a dedication to open
>protocol standards' means I can interconnect devices from different
>manufacturers without expensive gateways;-)

As for Siemens' "dedication to open protocol standards", no doubt they are also dedicated to world peace. I'm not sure what that really means in practice though. They are probably one of the few (if not the only) major
PLC manufacturers who do not offer an Ethernet gateway to 'their own' higher level network (Profibus FMS).

You mentioned FMS at the beginning of your message. I am finding that FMS support from anyone other than Siemens seems to be very limited, although quite a few companies do support DP. If you can find even expensive
gateways for FMS I would like to hear about them as I am looking for some. I am beginning to suspect that Profibus FMS is going to fade away before too long. Its role as a higher level coordination protocol may be assumed by some form of protocol running on Ethernet. In particular, the "Profibus Technical Description" (which can be downloaded from their site) states that:
"However, as a result of the further technical development of PROFIBUS and the use of TCP/IP at cell level, FMS will play an increasingly less significant role in the future."

I have a few things to mention with regards to Profibus which I would ask others to answer. I recently read the Profibus organisation's news release on their web site (http://www.profibus.com/) regarding "Profinet"
(profibus on ethernet). I must admit that after reading this I find myself no more enlighted than I was before.
Was something actually accomplished, or did everyone just agree that it would be a good idea to have something like this? I must admit that I could read the release either way.

Two items from this news release deserve particular notice though. One states that:
"PROFIBUS International is promoting a rapid, worldwide market acceptance through the open source concept, which makes PROFINet universally available."
Does this "open source" code actually exist anywhere or are they hoping that someone else is going to write it? I couldn't find any mention of where it is located or how to get it. I don't actually want it for myself, as I don't really know what I would do with it. However, I would like to know if this really exists.

The other statement was:
"...PROFINet can also be used to implement communications between any other fieldbus system and Ethernet..."

I believe they are implying that "Profinet" is suitable as a universal protocol to connect otherwise incompatable networks. I'm not really sure how this would work without additional software.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
R

Rob Hulsebos

>Given Siemens dedication to Profibus, one would expect that the MPI
>protocol used to communicate with 300/400 series PLC's is based on the
>profibus FMS transport.

>None of the documentation I have either confirms or denies this
>proposition. I put the question to a local Siemens chap who said
>he does
>not know but it does not matter because all Siemens equipment can
>talk to each other using one protocol or another. Quite.

What I know about MPI is not much: it seems to be based on Profibus, but only the FDL part. This means that the token-ring structure is there, allowing multi-master operation. It is said to work at 187.5 Kbit/s, this used to be the highest speed a Siemens S5 could work on about 5 years ago. I assume that has changed now.

FMS is a layer on top of FDL, so probably bad luck. Siemens S7 PLC's with the SEND/RECEIVE functionblocks communicate amongst each other using FDL, because FMS does not support the
messages needed for SEND/RECEIVE, and FDL does. Unfortunately this assures that a Siemens S7 can not communicate with other brands of PLC's via these function blocks.

Greetings,
Rob Hulsebos
 
My company will do the same thing with Siemens...give them the boot that is. We will do it for the same reason. My company is an OEM for the envelope business. We use an operator interface on Windows 98 and it crashes
periodically on every machine we have built. Most of our customers run 24x7 and the lost production time hurts, especially since it happens often. So,
the decision was made to migrate off of Windows. We invited Siemens and Allen Bradley to give us some alternatives. Siemens got angry and Allen
Bradley just said no.

We use both. We also buy many of both each year (100+ each of SLC, PLC5, S7 300, S7 200) and related items such as switches, motor starters, relays, communication cards, etc.

It is clear that these vendors are only interested in treating us as continuing cash cows. They sing the Microsoft upgrade and licensing songs very loud.

We like Profibus so we are turning to other vendors. Our desire is to migrate to an industrial pc. We do not have problems with using either Siemens or Allen Bradley hardware. Our problems have all been related to their software and its underlying OS.
 
R

Rob Hulsebos Philips CFT

>I have a few things to mention with regards to Profibus which I
>would ask others to answer. I recently read the Profibus organisation's news
>release on their web site (http://www.profibus.com/) regarding "Profinet"
>(profibus on ethernet). I must admit that after reading this I find myself
>no more enlighted than I was before.

The same holds for me.

To me it looks like the Profibus organisation is scared like hell by all the Ethernet developments in the rest of the world, and this press release
is just issued to calm things down, apparently because many potential users delay their usage of Profibus, assuming it is to be replaced soon
by something modern (industrial Ethernet).

>Was something actually accomplished, or did >everyone just agree that it would be a good idea >to have something like this? I must admit that I
>could read the release either way.
As far as I know nothing is accomplished yet, and it is a bunch of good ideas.

Talking about DCOM and such is fine, but the restricted availability of DCOM on many automation platforms limits it usefulness, I guess. For me it is unclear how DCOM will work together with Profibus. But I might have missed
something here, I'm not a DCOM expert.

>Two items from this news release deserve >particular notice though.
>One states that:"PROFIBUS International is >promoting a rapid, worldwide market
>acceptance through the open source concept, >which makes PROFINet universally available."
>Does this "open source" code actually exist >anywhere or are they hoping that someone else is >going to write it?

Profibus (and most other systems) have never issued 'open source'. Currently Ethernet/IP is the only one I known of, and even there it is a limited implementation. And, "open source" does not mean "free".

>I couldn't find any mention
>of where it is located or how to get it. I don't >actually want it for myself, as I don't really >know what I would do with it. However, I would
>like to know if this really exists.

I don't think there is anything yet and if there is, I assume you'll only get something if you become a member of the Profibus association.

Greetings,
Rob
 
D

D. C. Pittendrigh

Hi All

I am having some real problems coming to grips with the real issue of this MPI thread and would appreciate it if some one could explain what the real issue is here.

I am a dedicated Siemens fan and don't really care if I never work on another PLC other than Siemens S7.

As to the issue of the MPI thing, Siemens produces a Profibus interface which can and does talk all flavours of Profibus to whoever else cares to interface on this system. I have connected a number of non-Siemens devices
on Profibus DP and have done 2 projects with FMS interfaces (admittedly both to Siemens PLC's, 1 S5 and 1 S7) and it was really very easy.

In addition, there is an Ethernet interface available in various flavours as well, it is capable of both ISO and TCP and works very well up to 100Meg, I have recently used the IT version of the S7-400 Ethernet interface, it acts as a web server and can store HTML pages and has the ability to communicate with the mail server on your network with obvious advantages.

As to the Noah's ark technology, there is an RS232/485 interface which has a set of non-Siemens drivers available, one of which does Modbus and which I have used very successfully on a project to communicate with an Xcell data
concentrator.

I just don't understand why anyone would want to use MPI as an inter-PLC comunications interface in the light of the available alternatives. In the
old days we used to use the small S5's and implement comms links over the programmer port, it was a disaster, there is nowhere to plug your
programmer interface in so how do you commission the interface. MPI does allow you to plug in your programmer as well as some other device, but the
end result is your Programmer runs so slowly, you get old while you wait for things to happen.

Maybe I am missing something, if so I would be grateful for the correction, please don't tell me it is the financial thing, I live in South Africa and we suffer from a down trodden and inflation ridden badly managed economy, and my clients can still afford the use of quality equipment, I cannot believe this is a consideration in a country like the USA which is undoubtedly the
most affluent economy in the world.

Regards
Donald Pittendrigh
 
M
You could do worse than try QNX : http://www.qnx.com

support for Profibus on QNX is available at http://www.steinhoff.de/

Caveat : QNX is great, but I've never used Armins' stuff at the steinhoff URL

HTH
Mike
(my opinions, not my employers')

> My company will do the same thing with Siemens...give them the boot that is. We will do it for the same reason. My company is an OEM for the envelope business. We use an operator interface on Windows 98 and it crashes

> periodically on every machine we have built. Most of our customers run 24x7 and the lost production time hurts, especially since it happens often. So,

> the decision was made to migrate off of Windows. We invited Siemens and Allen Bradley to give us some alternatives. Siemens got angry and Allen

> Bradley just said no.

> We use both. We also buy many of both each year (100+ each of SLC, PLC5, S7 300, S7 200) and related items such as switches, motor starters, relays, communication cards, etc.

It is clear that these vendors are only interested in treating us as continuing cash cows. They sing the Microsoft upgrade and licensing songs very loud.

> We like Profibus so we are turning to other vendors. Our desire is to migrate to an industrial pc. We do not have problems with using either Siemens or Allen Bradley hardware. Our problems have all been related to their software and its underlying OS.
 
R
> Talking about DCOM and such is fine, but the restricted availability of DCOM
> on many automation platforms limits it usefulness, I guess. For me it is
> unclear how DCOM will work together with Profibus. But I might have missed
> something here, I'm not a DCOM expert.

Oh I have looked into this. With all the buzz about DCOM I also thought I was missing something, so I did my homework;-)

Basically, using OPC with profibus means connecting the profibus to a PC running windows NT4.0 and an appropriate OPC server. In the case of Siemens, their OPC server software requires the use of one of their PC cards (along with the software licence for the 'driver', plus a license for each OPC server (note that you need a separate license for FMS and DP).

Let's say this another way, In order to access profibus from OPC, you will need a bulky gateway (a PC) which, including license fees and interface card, will cost you several thousand dollars.

This is progress folks!
 
R
> I am having some real problems coming to grips with the real issue of this
> MPI thread and would appreciate it if some one could explain what the real
> issue is here.
>
> I am a dedicated Siemens fan and don't really care if I never work on
> another PLC other than Siemens S7.
>
> As to the issue of the MPI thing, Siemens produces a Profibus interface
> which can and does talk all flavours of Profibus to whoever else cares to
> interface on this system. I have connected a number of non-Siemens devices
> on Profibus DP and have done 2 projects with FMS interfaces (admittedly
> both to Siemens PLC's, 1 S5 and 1 S7) and it was really very easy.


Clearly you implement individual systems, as you get to choose which PLC;-) Put yourself in my shoes. I join up lots of little systems, and make them into bigger ones, I do not get to choose the
equipment used on the individual systems (well, I do sometimes, but even then others often have different opinions). Basically I must take what I have got and make it communicate.

Profibus is not available on all Siemens equipment. For example on the S7 it is on the 315 up, whilst on the 200 there is an option of
a DP slave on a couple of models, or the communications gateway.

Profibus DP is very simple to use but is totally unsuitable for large systems, FMS like request based protocols must be used. My original
question was wether MPI is implemented using FMS requests.


> In addition, there is an Ethernet interface available in various flavours as
> well, it is capable of both ISO and TCP

Well I would have expected TCP messages inside IP packets on an ISO ethernet, I was not aware we had 'options'

> and works very well up to 100Meg, I
> have recently used the IT version of the S7-400 Ethernet interface, it acts
> as a web server and can store HTML pages and has the ability to communicate
> with the mail server on your network with obvious advantages.

I also know how much it costs, and I know I can do better with a much cheaper embedded Linux controller, which can handle more protocols, do routing, and run industry standard HTML scripts/active pages and a whole host of other things (for instance I can BE the mail server), but I need some way to access the data in the PLC;-)

> I just don't understand why anyone would want to use MPI as an inter-PLC
> comunications interface

I want to use it to go from the PLC to a higher level.

> Maybe I am missing something, if so I would be grateful for the correction,
> please don't tell me it is the financial thing, I live in South Africa and we
> suffer from a down trodden and inflation ridden badly managed economy, and
> my clients can still afford the use of quality equipment, I cannot believe
> this is a consideration in a country like the USA which is undoubtedly the
> most affluent economy in the world.


What a ridiculous proclamation! Yes it is the financial thing, but first a couple of other points. Firstly, I am not in the US, I am not
American, and I am sitting due north of you in central Europe (Piedmonte, NW Italy, South of Gineva, East of Lyons, slap bang on the 45th parallel to be precise). Secondly, the US economy is affluent because of its large size and the high efficiency of its industry, you do not get rich by wasting money.

Having said that, YOU are doing the right thing. An automation engineer implementing a specific system will save money by using a ready made
plug and play communications technique as, allthougth the equipment and licences cost, writing your own comms software would be a time consuming tasks, and likely will cause you some problems.

On the other hand my situation (and that of many others) is different. I have spent a large part of my career implementing comms, and have worked in the telecomms sector and security sector, I am more of a comms engineer than an automation engineer (actually most of my work has been as an electronics hardware/firmware engineer on embedded systems). I now implement large systems, for example one system I am working on will involve around 70 PLC's, and will then be replicated on at least one other site. Now with my comms experience and the baggage of code
snippets I have built up over the years for e.g. handling serial ports, calculating CRC's etc, I can write build and test an interface for a documented protocol like Modbus in less than a day. A more complicated token passing protocol might take me a few days. But the end product will be specifically tailored to my requirements, fast, and robust, and not require the exorbitant software fees that are commonly requested.

Putting aside the financial constrainsts, there is also the compatibility issue. I make use of headless embedded PC's. Microsoft simply do not
make an OS suitable for such systems, and, AFAIK, have no intention of doing so, it is not their market. Yet so many manufacturers only make
available software for windows. In addition, I must often work in conjunction with the clients 'data centre', who may be using UNIX
servers, AS400's, whatever. It is very messy sticking windows boxes everywhere to act as gateways, and less Reliable. NOTE: by reliable
I am not making any insinuations about blue screens of death etc, but the simple fact that introducing additional elements into a system make
it inherently less reliable. In fact I am always working to simplify as much as possible.

These comms protocolls such as MPI are not particularly difficult to implement, or deploy. There is no justification for the secration of
these protocols. I feel that the reason there is such a plethora of incompatible 'open' comms options in the automation marketplace is
because manufacturers rely on the ignorance of automation engineers in order to generate cash cows in the form of their comms products.

BTW, OMRON do publish their protocol, which is pretty much the same across the whole range. You can use it on the onboard port or via an add-on module, the same is true for connecting the PC for programming. So, you can just stick on a comms module when you need to work on the
software. Using their standard software or rolling your own is optional, as it should be.
 
C
The real issue is that Siemens says open and does something else. And the Profibus support _is_ good. I need a protocol that I can use to interface my Linux Vision System and to GE PLC's. For the PC the obvious choice is Ethernet. So I asked them what I can do with their Ethernet. After several shovels full of BS it turns out that all I can do with their Ethernet is talk to another Siemens product. The protocol is proprietary. OK, what can I do to talk to the GE series 90 stuff. For various reasons none of the options is good. Usable in an emergency perhaps, but not something I'd
switch over to get. That part is not just Siemens, GE plays the same game "We're Open!, We're Open!" but when it comes right down to it, the only thing they are open to is selling you more of their equipment. The Ethernet part really irks me, everybody supports Ethernet now, yet putting them all together on an Ethernet network brings you no closer to interoperating as the wire is the only thing they have in common. They just don't get it that the reason people would buy Ethernet is because they expect to be
able to interoperate like the rest of the world. Ethernet by itself only solves the cost issues.
And MPI was one of the options I asked about and they said they didn't know how it worked and sure couldn't tell me. You may ask, "What's wrong with that?" The point is that those were the problems I was attempting to solve. Being open would solve my problems. Saying you're open without any change in reality simply wasted my time. And having to run Windows to do anything with their
equipment was simply the icing on the cake, selling unreliable tools doesn't impress me.

Regards

Curt Wuollet
Wide Open Technology
 
M

Michael Griffin

<clip>
>Basically, using OPC with profibus means connecting the profibus to a PC running
>windows NT4.0 and an appropriate OPC server. In the case of Siemens, their
>OPC server software requires the use of one of thier PC cards (along with
>the software licence for the 'driver', plus a license for each OPC server
>(note that you need a separate license for FMS and DP).
<clip>
I looked (briefly) into Siemens' Ethernet OPC server a few months ago. I believe it had a limit of only 64 nodes. If you had a situation where you were connecting PLCs directly to Ethernet you can run out of nodes pretty quickly.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
D

D. C. Pittendrigh

Hi All

I understand the frustration of getting access to information in this regard, I suggest that you don't write the Ethernet thing off so fast, you may have been advised by someone who is not too well informed. Take a look at the Siemens part number

6GK1 704-1CC02-0EA0

This is a software tool called softnet for SCO-Unix, in the same range there is a similar product for HP-UX, Solaris Sparc, Solaris X86 and Linux. In the manuals there should be (I haven't used the specific product) a complete description
of the S7 protocol stack and how to employ it with examples. I say should be as I have not used the Unix flavours of this product only the Bill Gates ones, and the description is quite complete. You should be able to use this product to solve the Siemens problem.

Sorry I can't help with the GE equipment.

Incidently there are also softnet products for Profibus, and if you ask your local Siemens Rep to track it down, I am sure if he finds the above part no. in his catalog he can also find the Profibus number. If this does not solve your
problem then let me know.

emailto:[email protected]

The statement that Siemens can only talk to another Simatic is totally untrue, in my environment there are a number of non-siemens products talking quite happily on Ethernet and if you contact me off the list, I will be happy to let you know what and how. The fact that the protocol (or a part thereof) is proprietry is
undeniable, if you ask your GE PLC to produce data from DB30.dbx0.0 of 30 bytes long, I doubt that you will get an intelligent response, I.E. there is a certain degree of PLC architecture involved in moving data between devices, and as you probably know, PLC architecture differs from manufacturer to manufacturer. There is a degree of standardisation provided by OPC servers, I am however not sure that an OPC server exists for Unix flavoured products, or if it is even a viable
proposal.

Good luck.
Donald Pittendrigh

> The real issue is that Siemens says open and does something else. And the
> Profibus support _is_ good. I need a protocol that I can use to interface
> my Linux Vision System and to GE PLC's. For the PC the obvious choice is
> Ethernet. So I asked them what I can do with their Ethernet. After several
> shovels full of BS it turns out that all I can do with their Ethernet is
> talk to another Siemens product. The protocol is proprietary.
 
L

Lizotte Chris-FCL005

> I am having some real problems coming to grips with the real issue of this
> MPI thread and would appreciate it if some one could explain what the real
> issue is here.
>
> I am a dedicated Siemens fan and don't really care if I never work on
> another PLC other than Siemens S7.

Think of the "open" technology argument this way;
(use your imagination)

Assume you are a dedicated Chevrolet fan, and you only drove Chevrolet vehicles. Because Chevrolet only builds rail cars, you are limited to travelling on proprietary Chevrolet railroad tracks. This is not too big an issue, because you can go to ALMOST all the places you NEED to go (even though the salesman told you you could go anywhere) , and you build your life around destinations w/in walking distance of a railroad station. The other little_minor_issue is that Chevy's only run on genuine Chevrolet propane ( which costs 4X "non-genuine" propane) and you can only fuel up at the Chevy propane stations purpose-built in close proximity to a railroad
track.

Your buddy is constantly telling you what a fool you are because:

He is a dedicated Ford fan and only drives Ford vehicles. Because Ford only builds boats, he laments your inability to see all the benefits of life on the seas. He does't mind travelling on the water or having to buy "genuine" FordMoCo Diesel fuel at the Ford gas stations on the water's edge. He loves the fact that just like his salesman told him, he can go anywhere he wants
in his Ford vehicle (since he never leaves the water, why would he ever need a rail car?)

Your dad thinks you both are idiots because:

He's been trying for years to get Ford and Chevy to build their vehicles w/round, rubber, inflatable wheels so they could both travel on his new invention, the all-purpose, "road.com" He has convinced the Government.com to build and maintain these roads.com. He even suggested having both manufacturers design their vehicles to run on mogas.com so that their customers.com could save money. He has gotten nowhere because neither Ford nor Chevy wishes to compete against each other, nor potentially sabotage their own current markets. Screw the customers, because, what else are they gonna do?

Chevy = Rockwell + Nintendo
Ford = Seimens + Sony PlayStation

Go LinuxPLC!

TOAMOADNRTOME

Sincerely,
Christopher G. Lizotte Phone: (815) 884-0290
Sr. Automation Engineer Pager: 1-800-skytel2 pin 7398083
Motorola PCS EMail: [email protected]
 
C
Hi Don and all

I did check the reference, but, will need to do some more digging. It appears this stuff is quite new. But, it is constructive and an effort to solve the problem. Source would be great, but even a binary gives me an in.

More on this later.

Regards

cww
 
D

D. C. Pittendrigh

Hi All

I am dead keen to hear how you fare if you do decide to use this route. It could change a lot of my thinking if you are successful. At the moment it is a bit difficult to introduce Linux in my area as my clients still associate it with a downloadable freeware program and most aren't even prepared to consider it for industrial applications, a big mistake in my opinion.

Cheers
Donald P.
 
C
Hi Don

You don't need to wait for that, I am already using Linux in an industrial environment with good results. Usually, I am combining machine vision with comm service. The only commonality in various types of equipment are RS232 ports. It's no trick at all to set up a Linux box with 8 or 16 serial ports and have it handle communications so that each piece of equipment needs only one port. This is very cost effective compared to the cost of extra ports on PLC's and CNC's etc. I use Rocketport boards that are very well supported as Ted T'so, the guy who maintains the Linux serial code works for Comtrol on the drivers. It's the "last man standing" when there are problems so I'd say it's at least as reliable as the PLC's in this mode. With a wide range of comm options it would make a great gateway between wire specs and protocols if only more fieldbus drivers were available. We're working on that with the Linux PLC project. Going forward, all our cells will probably include a Linux box as a go between and to solve some interoperability problems. The ports are less than $50.00 and the programming seems considerably less challanging than the alternatives. Once the box is in the cell, it finds many uses. HMI, remote logging and monitoring, backup, print service, barcode reading, remote access for troubleshooting, all kinds of things. In short it provides the sort
of connectivity that automation equipment sorely lacks. And you don't have to replace many PLC modules and "special" functions before you have
paid for the box.(1?) You should use a hostname of Excedrin for all the headaches it cures, especially when integrating old and new equipment.
I think of it as a huge toolbox stuffed full of serial, ethernet, display and datahandling tools. Every cell should have one. And it can do all
of this at once, which really begins to lower unit count. All I need to complete the picture is some way to deal with PLC's in near-realtime and
that's what brings us to things like MPI and fieldbusses. Other people have seen this potential to work around the built-in and crippling "islands of automation" problem in a cost-effective manner. Makes the programming for the other stuff easier as well.

Regards

Curt Wuollet
Wide Open Technologies
 
R
Personally I do not tell them. My Linux boxes are headless and used for dedicated embedded tasks. Does your ISP tell you that most of the services you will use on the internet are using free open source downloadable software?

Do you tell your customer about the underlying technology in an HMI or PLC.

My customers just want something they switch on and works.
 
D

D. C. Pittendrigh

Hi Curt

Thanks for your response, just one thing, I am not going to interface 150 PLC's on my clients plant to a Linux machine on serial, the PLC's are Siemens S5's and S7's as I try damn hard not to work on anything else, so the only way to do this is via 150 serial interface ports, that's not for me, which is why the debate was about Linux
talking S7 functions on industrial ethernet. For this a product called Softnet is required on the "unix" side, the product costs a fair bit of money, and I can't justify buying to play with, my client won't use linux because he accords it the importance of pornographic spam as it is available as freeware on the internet and therefore I reach an impasse where I find it a little difficult to convince the client of the Linux route as I can't show him anything special to make him change his mind.

As regards the Linux PLC, I wish you good luck with this one I am sure it will make many people happy to go this route, it is however not an option for me, I intend to retire in the next 8 years at 50, it is a life long ambition to travel from Cape (as in Cape Town, South Africa) to Cairo by 4 x 4 and I cannot convince myself, try as I might, that the linux PLC will produce the
24 hour/7 days a week reliability that the PLC's I deal with do already. By the time this has been achieved I intend to be too old and tired to learn new tricks. My interest in Linux stems from the convenience of a Unix networking environement, and the stability of the core
for industrial HMI applications - not control.

Regards
Donald Pittendrigh
 
Top