Is Siemens PPI a closed protocol

R

Thread Starter

Roger Irwin

I have these great little S7-200 PLC's from Siemens. I know these boxes have powerfull single master (PPI) and multi-master (MPI) interfaces
built into them.

I know these interfaces are capable of doing what I want to do.

Siemens go on about thier 'open standard vendor independent networking solutions', but the only way of accessing a S7-200 with PPI/MPI appears
to be via thier proprietry drivers, which are only available for windows.

I need to do some fairly straightforward communications with my S7-200's from an RTOS, whilst also having other connections, such as
Step7/Micro-win.

Looking at the way Micro-Win can work alongside e.g. a TD700, there appears to be no technical reason why this should not work. Except no
technical details appear to be available.

Am I blind, or do Siemens delibrately hide this information?
 
C

Curt Wuollet

Hi Roger

You have fallen victim to one of my pet peeves. This whole industry thinks nothing of simply declaring a product "Open" with no other changes in their attitudes or

policy. In fact, for many of them, the only change is to put the word "open" in every sentence of every communication. They like "standards" and "vendor independant" also. What this typically means is that it will work with any of _their_ products. After all, why would you want it to work with anything else? By the way, did you know that Windows NT is "Open"? I bet Bill Gates doesn't know that! Another case is all the "Open" associations that typically push proprietary standards to a members only audience. In this particular industry, it's safe to assume that open has no meaning or, as likely, is a deliberate attempt to deceive. They
would like the PR value of being Open without actually giving up anything..

Go ahead guys, tell me where I'm wrong, this is a debate that's sorely needed.

Curt Wuollet,
Wide Open Technologies
 
D

Darryl L. Palmer

I have some rantings about this Open stuff.

I was going through some papers from the ISA and there were actually some that not only referred to Windows NT as being "Open" but also Microsoft
Office. What the heck is this? One of the authors went to say that the reason that Office was "Open" is because it is prominently used.

I wish for the good old days of "Open" computing, when the only coices for hardware was a PDP-11 or IBM 360.

The coolest thing I have seen is that one of the companies we work with not only use the word "Open" in their company motto, but also in the names of some of their products. Needless to say the last thing they are interested in is being Open.

Darryl Palmer
Cleveland State University
 
M

Michael Griffin

Peeve away, but I don't think that Siemens ever claimed that PPI or MPI were "open". Profibus and ASI are the "open" networks that Siemens supports.
If you want to complain about Siemens networks, protocols and other communications methods, then complain about the fact that they seem to have more different incompatable forms of these any any several other companies put together. They don't offer any means of bridging between their multiple systems that I have been able to find.

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

Curt Wuollet

That's all part of the same problem. Rather than use the same proto as someone else and take the chance that things might interoperate, every new product must have a new and incompatible protocol. Microsoft uses this also to force an
upgrade every time they need some revenue. In most cases, there is nothing in the new offering that couldn't be done with existing schemes, it's simple extortion. Profibus is one of those "Open" protocols for members only. ControlNet is the latest attempt to decommoditize TCP/IP and Ethernet. If you check, it's being pushed by the same crew that decommoditized CAN with DeviceNet. The only specifications I have been able to obtain without joining something or buying
something or signing rights away have been Modbus, Modbus/TCP and an OPTO IEEE1394 block transfer protocol. That last one seems kinda like a new proto simply for the sake of a new proto also but, at least they publish it. I have all kinds of GEF equipment, none of which shares any reasonable means of communication. It's just crazy.

Regards
cww
 
R

Ralph Mackiewicz

> I was going through some papers from the ISA and there were actually
> some that not only referred to Windows NT as being "Open" but also
> Microsoft Office. What the heck is this? One of the authors went to
> say that the reason that Office was "Open" is because it is prominently
> used.

We really shouldn't be that upset about misues of the word "open". There are many other words that are misused, why is "open" any different? Here are a few more misused words (IMHO):

leading/leader
state-of-the-art
easy-to-use
integrated
dominant

The common element is that these are all qualitative terms that will, by their nature, mean something different to everybody but generally have positive connotations. That is why they are used in the first place.

Knowledge is power. It is usually obvious whether something is indeed "open" or not (per whatever your definition of "open" is). You make your judgement and that tells you how much you can believe of the other stuff that the company/person presents.

> I wish for the good old days of "Open" computing, when the only coices
> for hardware was a PDP-11 or IBM 360.

You can't be serious, can you? I think you meant to put a ;-) at the end of this didn't you? I would love to hear of a definition of "open" that would apply to a PDP-11...other than the fact that if you removed the front cover the rack was "open" for inspection. ;-)

Regards,
Ralph Mackiewicz
SISCO, Inc.

Ralph Mackiewicz
SISCO, Inc.
6605 19-1/2 Mile Road
Sterling Heights, MI 48314-1408 USA
T: +810-254-0020 F: +810-254-0053
mailto:[email protected] http://www.sisconet.com
 
S

Schaminee, Bart

Hello Curt,

From your e-mail I understand you are fed with suppliers callin themselves "Open". The hardware is all standardised already. The application-layers of protocols aren't all.

There is a specific reason for this. Market and history. Modbus-RTU was a good start and is still accepted in a lot of industries. CAN is a more or less a motion-protocol, with message-priorities. Ethernet TCP/IP can use the world-accepted networks and devices (cheap and understood), howver, has limited diagnostics and is not realy real-time. Profibus-DP is a way to approach market-needs. So is Fieldbus-foundation. Genius form GE is industrial-proof. Lonworks is cheap. I can go on untill I have written an A-4.

Here is my personal conclusion:
The office automation once had the same issues. You might blame Microsoft, but they forced the standards by good marketing. The Microsoft reliablity for industrial envioronments is a discussion I want to avoid in this matter. The Industrial applications are different in every application. Therefore any protocol can be justified over the years. The life-cycle of industrial IT and controllers ia approx. 5 times longer than office automation. We will get there at the end. If the endusers and system integrators define their standard, the suppliers will follow.

Maybe we will be both retired by than. We will talk about integration in the od days as they do now about the mainframes, developped in the 70's.

Kind regards,

Bart Schaminee.

P.S. Proprietery networks are not loved, but can offer some applications better solutions than others. When processors get faster and communication gets more and more cristalised, propriety networks will disappear at the
end.

This statement above is personal.
 
R

Ralph Mackiewicz

There seems to be a tendency to attribute sinister and evil motives to situations that arise due to causes that are much more mundane and
much more insidious than a conspiracy to deprive automation engineers of their hard-earned wealth with a threat of violence (i.e. extortion). Anyone who has worked at a large organization, like Siemens, can attest to the fact that these large companies are organized into mostly independent groups that do their own development. A company like Siemens could have hundreds of these groups. It really should come as no surprise to anyone that these groups may not communicate much with each other. I suspect that the myriad of incompatible protocols from Siemens is more likely the result of accident than design. It says more about the style of their
executive management than it does about their talent for engineering conspiracies.

> Profibus is one of those "Open" protocols for members only.
> ControlNet is the latest attempt to decommoditize TCP/IP and
> Ethernet. If you check, it's being pushed by the same crew that
> decommoditized CAN with DeviceNet.

Again, the desire to define a communication framework based upon CAN or TCP/IP that could hope to acheive interoperability is demonized
into some conspiracy to "decommoditize" the free way of doing it. Neglected in this argument is the fact that neither CAN nor TCP/IP are sufficiently defined by themselves to allow the manufacturer of any piece of industrial control equipment to have any hope of interoperating with anyone else. For instance, how does the
commoditized version of TCP/IP using a standard TCP socket provide a service for reading a variable? I'm no fan of Controlnet but these
accusations are a bit over the top. BTW: Controlnet did not start out embracing TCP/IP or Ethernet. It ended up there because of demand for
it from the market.

> The only specifications I have been able to obtain without joining
> something or buying something or signing rights away have been
> Modbus, Modbus/TCP and an OPTO IEEE1394 block transfer protocol.
> That last one seems kinda like a new proto simply for the sake of a
> new proto also but, at least they publish it.

I don't get it. Why is paying a few hundred dollars for a specification such a big deal? I can't speak to the OPTO protocol but Modbus and these other protocols you refer to is an apples and organges comparison. There are numerous devices that all implement Modbus but do not interoperate. Most power meters, for instance, have rather arcane methods of retrieving waveform data from them that are well beyond the functionality offered by the trivial Modbus
specifications. The probability of two companies accidentally deciding to use Modbus, CAN, TCP/IP, etc. in exactly the same way to provide a service that they don't inherently support is probably
equivalent to me being killed by a flying saucer from Mars crashing on my house. You may not like the way the standards are written but these kinds of standards (DeviceNet, Profibus, UCA, etc.) are needed if interoperability is going to be acheived using underlying technologies such as TCP/IP, CAN, RS-485, etc.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R
Of course MODBUS is the 'obvious' RS485 protocol of the sort we all used to write before standards came along, MODICON did the right thing by publishing it, so now if we do decide to knock up a 485 at least we can do the same as everybody else. And they get their name banded about for free!
 
R
Michael Griffin wrote:

> Peeve away, but I don't think that Siemens ever claimed that PPI or
> MPI were "open"=2E Profibus and ASI are the "open" networks that Siemens supports.

The S7-200 blurb is full of open, but ASI and Profibus are more like add-ons than integral features

A case of clouding the issue.

> If you want to complain about Siemens networks, protocols and other
> communications methods, then complain about the fact that they seem to have
> more different incompatable forms of these any any several other companies
> put together=2E They don't offer any means of bridging between their multiple
> systems that I have been able to find.

A PC with PRODAVE? One of these new micro PC's such as 'PC on STICK/DIMM/STAP/CREDIT CARD whatever' would be ideal for such a task, and
many others, but of course such little headless PC's are designed for running the likes of RT DOS variants, or QNX or embedded LINUX.

Siemens, with PRODAVE and other software, only seems capable of supporting Windows. Quite amazing when one thinks of how many automation and control equipment is a)Headless, b)Requires robust RT OS, and c)requires easy app
development. And before anybody tells me it is easy to develop under windows, it is easy to develop Office Automation applications. Now do an RPC that will work with the rest of the world!

Hence my problem, linking S7-200's to the 'real-world' of TCP/IP and information systems through a black box with realistic costs. There are a lot of possible solutions, but all lack one little ingredient, the PPI protocol.

Even the EN50170 is illusive. CENELEC do not let mere mortals download it. Our local CENELEC 'reps' do not actually sell it, but they refer us to a bookshop who is authorised to sell it. But they have not actually recieved any copies of the
standards.

My boss is keen to use Siemens because the hardware is robust, and I would go along with his logic, but it would appear we will be forced away because it is simply not possible to deploy. For all that Siemnes hardware is good, their software is a disaster. Pretty gold plated lego. Looks great, costs a fortune, and it can be pieced together in a variety of ways that will ALMOST meet your requirements, but not quite. Do it our way or not at all. Is this a virus that has
spread from Redmond?

I have been having great fun with the Step 7 micro Win, which appears to be the only way of programming the 200 series. I should point out that this is, amazingly for Siemens, free, that is free as in free beer, not free as in free
speech aka Open Source. I can have up to 64 subroutines, so thank heavens I can name them, but I cannot actually call them by that name, I have to go and look up the number. I cannot define arbitary symbols or macros (aka #define,
or equ in assembler), and if I try and use Symbolic names with pointer syntax I get errors.

Any third rate programmer could write a pre-processor in a matter of hours. Siemens apparently cannot.Yet another great piece of Siemens hardware, at a great price, destroyed by programmers apparently incapable of doing anything
more than dragging and dropping MFC classes onto a dialog.

Then there are the licences, I am not moaning about paying them, thats not my problem! The problem is the sheer volume. Seems like every way you turn you get asked for an Authorisation, a collegue recently quipped that we should set up a warehouse and inventory control system for the Siemens licences.
 
P

Paul Goodwin

Hello All!
At the risk of getting flamed :)

The published PPI protocol part number is 6ES7 298-8GA00-8XH0.

Regards,
Paul Goodwin
Siemens Technical Support.
 
R
Great, will try ordering. And if I actually get the protocol then I take back all that I have said and start moaning about Siemens reps and catalogs instead!!!

Thanks.
 
J

Jerry Miille

RIGHT!

Only $1,500 plus a license you have to sign. Really an "open" protocol if I ever saw one ;>)
 
N

Nacho de los Rios Tormo

<snip>
> I don't get it. Why is paying a few hundred dollars for a
> specification such a big deal?
<snip>

Paying a few hundred dollars for A specification is not a big deal, unless you are SEEKING the specification that suits your application: then you find you have to shell out those few hundred dollars to twenty different organisations that publish twenty protocols, and it adds up to quite a deal.

<snip>
> You may not like the way the standards are written but
> these kinds of standards (DeviceNet, Profibus, UCA, etc.) are needed
> if interoperability is going to be acheived using underlying
> technologies such as TCP/IP, CAN, RS-485, etc.
<snip>

Cannot argue about that!

Regards,

Nacho de los Rios Tormo
Procedimientos Integrados
[email protected]
 
M

Michael Griffin

Roger Irwin wrote:

<clip>
>Siemens, with PRODAVE and other software, only seems capable of supporting
>Windows. Quite amazing when one thinks of how many automation and control
>equipment is a)Headless, b)Requires robust RT OS, and c)requires easy app
>development <clip>
>Hence my problem, linking S7-200's to the 'real-world' of TCP/IP and
>information systems througth a black box with realistic costs. There
>are a lot of possible solutions, but all lack one little ingredient,
>the PPI protocol.
<clip>
I have a similar requirement, with the stipulation that I want to buy a 'magic box' that does it all off the shelf - I have no interest in
doing any development work for this.

Something that has just now occured to me though, is that it is supposed to be possible to write a subroutine which you can load into your
S7-200 which lets it talk Modbus using Freeport mode (there is supposedly a free Modbus example in the 'S7-200 Tips and Tricks' download, although I have only looked at it briefly). There are several dedicated 'black boxes' which let you talk Modbus via ethernet (Modbus to Modicon TCP/IP). Some of these sell for well under $1000.

If you need to talk to Profibus (for S5 or S7-300), SST has their 'X-Link' box, which does support Profibus (and almost everything else as well). Unfortunately it doesn't support the Siemens flavour of ethernet (not much demand for it apparently). However, this amazing little box does support Modicon's flavour of ethernet. You can actually have Modicon ethernet (Modicon TCP/IP) go in one end of the box, and Profibus come out the other.

Aha! You can easily network your Siemens PLCs to higher levels provided you disguise them as Modicon PLCs! I wonder why this solution, odd
as it seems, would appear to be so much easier and less expensive than using Siemen's own protocols directly?

>I have been having great fun with the Step 7 micro Win, which appears to be
>the only way of programming the 200 series. I should point out that this is,
>amazingly for Siemens, free, that is free as in free beer, not free as in free
>speech aka Open Source. I can have up to 64 subroutines, so thank heavens
>I can name them, but I cannot actually call them by that name, I have to go
>and look up the number.
<clip>

What version are you using? Version 3 was completely rewritten, and is a big improvement over the older versions. There's not much resemblance between version 3 and the previous versions. The original software was something which the S7-200 crew scrambled to put out after they gave up on ever seeing the software they were promised from Germany. The S7-200 is made
by what used to be the TI PLC division.

By the way, the type of "free" you may have might be "free" as in "here's the software, just make sure you buy lots of hardware". That doesn't necessarily mean it's an official Siemens policy though.

**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
R
I have found that the Siemens order code for the protocol really does exist on the price list, despite catalogs and reps apparently knowing nothing about it (leastways the Italian ones;-). But, yes, it is expensive, and states one must agree to the condistions of use before reading it.

This leaves me perplexed. If it really tells me what I need, and the agreement really allows me to deploy, then it is worth it. But how does one know 'a priori'?

Does anybody know this document? Is it, on it's own, able to furnish all one needs to know about interfacing to an S7-200? Does it miss bits out, like the underlying Profibus like mesage container. Does it furnish all details, i.e. would I be able to do everything e.g MicroWin does?

And what are the licsensing restrictions?
 
M
Guys,
There is a PPI DDE server available from and independent company for a lot less money than you would pay for the PPI specification. Maybe this would fill your needs and save you some development time. They have a free demo for downloading. Check it out at http://www.usit.com/seiftc/ .

Mark Ramey
 
C
Hi all,

Somehow, a binary only driver for a proprietary operating system for a proprietary protocol doesn't seem to solve many "openness" problems.

Curt Wuollet,
WOT
 
R
Especially as one of my requirements was to use PPI with (yes, I confess, I am out of the closet)
A NON WINDOWS PLATFORM.

Other great things I have discovered during my Siemens protocols forays is that the S5 has MANY
different flavors of protocol, but the 3964, which it uses on its basic port, IS documented. Now the site where I have to use these protocols contains some OMRONS some S7's, and quite a lot of
S5's. The PRODAVE package that supports the S5 only runs on Windows 3.1 and DOS, whereas the
PRODAVE that supports the S7's only works on W9x or NT, except in the case of S7-200's with a
display unit where NT will not work with the standard adapter capable, you need a much more
expensive intelligent interface despite the blistering speed of 19,200 baud.

Now some irony. When I was first presented with the project there was much Umming and ahhing over
the OMRON units. Everybody KNOWS that Siemens uses open protocols...so no problems there, but
would we be able to connect to the OMRONS? Whould we need to modify the program...add a
communications processor. Well, being a potential thorn I investigated thisproblem first. I
downloaded the protocoll from the OMROM site (free to all, not even required to register), and
found that I could talk to the omron directly through the port used for programming with a simple straightforward protocol that allowed me to read and write all areas of memory (including program) and do a lot of other things besides, all while the CPU was running.

I had a test program up and running THE SAME DAY. No special software, no runtimes, no license
agreements or NDA's.

Wake up to the real world Siemens!
 
Top