Importance of subnet configurations done with NetPro (Step 7)?

[FONT=&quot]Sorry for the long post but I want to provide some background info for the sake of completeness. First of all, this is an existing, all-Siemens all-Profibus S7/WinCC factory that has been running successfully for the past decade. I am merely wondering about Step 7 NetPro configuration data.[/FONT]

[FONT=&quot]Background: each of the factory's main S7 300 racks has a CP342-5 connected to a plant-wide Profibus subnet for the sole purpose of communicating with a WinCC 6.0 server (all CP's set up in the hardware config as "No DP mode", "Save config data on CPU", no program stored in the CP).[/FONT]

[FONT=&quot]The WinCC project is configured as server v. client-without-project, no Step 7 integration (the old fashioned way as this started under WinCC 4). In Step 7, each PLC is it's own project.[/FONT]

[FONT=&quot]In the process of replacing the server last weekend I re-evaluated the setup and combined the Step 7 projects into one multi-project. Then I noticed that most Step 7 projects had a mismatch in NetPro between the configured and actual WinCC server Profibus station address. Some PLC's also had a mismatching subnet ID for the plant-wide WinCC Profibus and a mismatching subnet ID for (another) plant-wide MPI network.[/FONT]

[FONT=&quot]Again, all is well in this plant.[/FONT]

[FONT=&quot]There are many cases where the configuration in NetPro can make or break your project but I am wondering why in this case it never seemed to have made a noticeable difference. Does anyone know what the CPU is actually doing with the WinCC server's station address and WinCC subnet ID?[/FONT]

Thanks,

Stephan Planken

Then I noticed that most Step 7 projects had a mismatch in NetPro between the configured and actual WinCC server Profibus station address. Some PLC's also had a mismatching subnet ID for the plant-wide WinCC Profibus and a mismatching subnet ID for (another) plant-wide MPI network.

Click to expand...

Can you post some screenshots of these 'mismatch' situations ?
Are these 'mismatches' still there, or did you do something to clear them ?

Does anyone know what the CPU is actually doing with the WinCC server's station address[..]

Click to expand...

If WinCC is doing the polling of the data, then it does not matter for the S7 CPU what the WinCC Profibus station number is.

[..] and WinCC subnet ID?

Click to expand...

I think this is really only important when there is routing involved.

Besides, using Profibus as the backbone for a plantwide SCADA network makes me cringe. But OK, that was maybe the way to do it 10 years ago.

One thing is for certain, by integrating everything into one project, the calculation and managing of the profibus bus parameters becomes much more easy.

Jesper,

Thanks for your reply. I believe you are right: these CP342-5's are not doing any real routing and just allow the WinCC server to send/receive data from the local CPU. Since it does this without code in the CP (no send/receive jobs) I believe that the server station number is irrelevant.

I did have the chance to correct one of the PLC's this week to the right WinCC station address. Later this week I will run a test in a lab.

I had a hard time inserting an image, so here's a link to a screen shot:

http://www.flickr.com/photos/stplanken/4871401059/

The relevant Profibus subnet is highlighted (center subnet). The CPU "UFO_PLC_3" has station address 44, the server has station address 22 (while it has always been set to 0 on the server).

From your description and the screenshot, it is almost certainly of zero importance to the S7 CPU that the WinCC Stations address is incorrect.
But for correctness sake, you should set it correctly.

Btw. Since the S7 CPU is a 317, the project cannot be that old. It would have cost the same to install a CP343-1 LEAN or get a PN CPU. Same price but much betterer.

N.B. Profibus station address "0" is normally reserved for a PG.

This particular PLC originally had an old style -316 that I replaced a few years back after the scan time became unacceptable (>85ms). This switch required less down time than to rethink the entire plant configuration. Come to think of it, most of the CPU's have been replaced from old style 315's and 316's to 318's, 317's, and recently a new style 316.

There are three subnets from a server room to the plant through OLM's (Profibus - fiber optics), making changes to that would require much more cost and down time than replacing a single CP. Although I am still thinking about introducing ethernet at some point.

To answer my own question...

Just to follow up on this: I had time to set up a simple test rack with an old-style 316 and a CP342-5. I set up my laptop as the Simatic PC station, with a CP5512, similar to the plant screen shot. The CP had no blocks loaded and its sole purpose was to prove that I can access the CPU through the CP.

I can confirm that the station address of the pc station in this case is irrelevant.