Simatic Manager question - Netpro and another question?

Hi all,

I was recently working on a production line that had 4 old TP170A HMIs on it.

I had to make a change to one of them. They were all connected via profibus to one CPU 315 PLC.

So, I connected to the PLC, upgraded the old HMI protool software of one of them to WinCC Flex, and then went to try and download to one of the HMI's in order to check I was talking to it okay.

I had the message about "upgrading the OS" so I did that and, once complete, the line stopped working due to a profibus fault.

I realised that by updating the OS the HMI had reverted back to address '1' (it should have been address '8') so I set it to address '8' locally on the screen (ie. through the control panel) but I still had the profibus problem.

I rebooted the screen and it reverted back to address '1' (no idea why it wouldn't 'remember' it's setting).

So, because I didn't have a lead that would connect to it locally, I decided to remove it from the 'hardware config', unplug it and then hopefully get the line running again.

I went into NetPro and the screen was in there but not 'connected' to the profibus line, it was just floating. In fact, all the screens were listed in there but none of them were connected to anything??

In the end I just physically disconnected profibus plug from the screen and luckily the line sprang back to life.

Since then I've managed to get a basic RS232 lead and a USB to serial converter and downloaded the software back into the screen via it's local port. I've plugged it back in and all is well with the world, its communicating again.

My questions are these:

1) Why, when I set the addrses to '8' on the screen after an OS update, did the screen still bring down the profibus network and also why did it not remember that it was set to '8' after I cycled the power??

2) What is the point of Netpro? Is it just a visual representation of the network purely for the users benefit? (i.e. it doesn't matter if things are connected or not in Netpro) ?

3) If the screens aren't connected in Netpro, and they aren't in the hardware config, how is it that it managed to bring the profibus network into fault? It defaulted to address '1' after the OS upgrade and there was another screen with address '1'. But, surely if the PLC has no record of these HMIs within its memory how can it know there is a conflict? Why didn't it just ignore them?

I hope my questions make sense and apologies for the long post but I wasn't sure if any of the events leading up to this would be relevant so thought I'd give a full 'history'.

Cheers

;-)

1: Dont understand that you had this problem. But I dont ever use TP170A.

2: NetPro is an overview of the entire installation. In your case it is required to use NetPro in order to properly calculate the TTR of Profibus.

3: I am guesing that Profibus is ONLY used for the TP170A panels ? If so, it could work even if TTR is not properly calculated. But it isnt perfect. It will fall over at a disturbance such as network roblems due to duplicate station addresses. If there are DP slaves connected as well, then I cannot understand how it could ever have worked.

I recommend that you connect everything to the Profibus network in NetPro, compile in NetPro and download again to ALL the stations, panels as well as CPUs. As an excercise, check TTR before and after you conmpile.

Jesper,

Thank you for your answers.

1. The TP170As are existing. They've been on the line for years. It is certainly not something I would use if we were buying new panels.

2. I have no experience of calculating 'TTR'. Could you briefly explain this?

3. No, from the CPU there are other devices (inverters and such) hanging from the profibus line. I've posted some screenshots of the hardware config and a zoomed out / zoomed in of the netpro. I would like to get all the hardware config/netpro correct.

Here's the hardware config:



Here's a zoomed out version of Netpro:



Here's a screenshot showing the HMI's (and other stuff) 'floating' ??:






Thanks again for your help

cheers

John ;-)

TTR: Token Target Rotation time. It is the time that the token must return to a station after it has released it to the next station. It is calculated depending on the number of stations and their type.
You can find the TTR under the Bus Parameters. It is a very important factor and should be checked as you need to know if your i/o will update every 15 ms (as with only master-slave datatransfer and a few stations) or every 700 ms (as with mixed master-slave and master-master and many stations).

I think I know what has happened in your project.
Basically the profibus layout is totally messed up. So many DP slave stations and so many HMI stations together would have resulted in a very long TTR. The "solution" has been to not add the HMI stations to the profibus network. In this way a reasonably short TTR is calculated. The HMI stations will then kind-of work because there is always some token rotation time left after the DP slaves have updated. But any problem on the network can make it fall over.

I totally hate when HMIs are mixed with DP slaves on a Profibus network. Even if it is possible, it is one of these things that one should avoid for a number of reasons.
Nowadays, everything is either on ethernet (Profinet), or you split up in Profibus DP for the DP slaves and ethernet for the HMIs.

I notice that in addition to the HMIs, there are even further DP slaves and another CPU that isnt attached to the Profibus network, despite that in reality they probably are.
This is a mess.

Thank you for the great TTR explaination. I will look into it.

The line has got 6 old HMIs on that I want to use for a project that I'm doing.

I originally just wanted to get the old Protool software converted to WinCC Flex and then update all the OS's of the HMIs and establish comms to them all before I then started writing the software.

Unfortunately I had the comms problem which led me to the issues I've got now. The config is a complete mess as you rightly say.

So I want to sort it all out and get Netpro correct with everything hanging off the correct network etc.

The problem now is, following your post, I'm worried that if I attach everything to the profibus network I will negatively affect everything else on the line as I will be increasing the TTR too much??

Do you think this would be a problem or not?

I can always try it and then just download the old hardware config if there's a problem I suppose but would love your thoughts on the best way to go to start sorting this out.

Many thanks Jesper,

John ;-)

So you plan to remove the TP170A HMIs and use them somewhere else ?
Or .. ?
edit: I count 8 HMIs. How many HMIs are really connected to the 315-2DP ?

I would be very cautios by making any changes to your system. It shouldnt work, and that it seems to work may only hide that there is a fundamental problem that may surface at any time.
If I were you I would try to make it right. Possible solutions could be:
1. The best but also most expensive solution: Exchange 315-2DP CPU for a 315-2PN/DP CPU. Exchange all the TP170A panels for ethernet panels. Move all the HMIs to Ethernet.
2. Make do with what you have got: Add a repeater to the MPI port on the 315-2DP. Move all the TP170A panels to MPI. Due to that the MPI network will be slow, the panels will update slowly, but probably not worse than what they do today.
3. Accept an extremely long TTR time. Connect everything on the same Profibus network. Make sure the HW config and NetPro mirrors the reality.

There are 6 of the HMIs that used to be used for a product counting system.

My goal is to redesign the product counting system and get it working again.

I think I will go with your number 3 suggestion. I would love to replace the panels and PLC and run the network on ethernet but this has to happen on zero budget unfortunately.

I'll try getting the netpro to mirror the real world, download the hw config and see if that works. If there's issues then I'll have to go back to the old config and try the MPI network route.

A big thank you once again for all your help.

Be sure to check TTR before and after.
Depending on your bus speed, I am guesstimating with 15 DP slaves you have either TTR~40ms @1.5Mbps or TTR~250ms @187.5kbps.
If you add 6 HMIs you will land at either TTR~300ms @1.5Mbps or TTR~1500ms @187.5kbps.

Will do. Thanks ;-)