Communicating and moving data from S5 to S7 PLC

russg

Member
Join Date
Aug 2012
Location
UK
Posts
275
Hi,

I've been given a task of loading all the data from 3 S5 PLC's to one S7 PLC which will be used as a bridge to help speed up the communication with the Wonderware Scada system. I have been told the scada has a very slow response time which can be up to 7 seconds.

Apparently the 3 S5 PLC's are each using a H1 to Ethernet convertor which are all linked to a switch. The 3 S5's are then communicating with each other and the Scada system.

My task is to bring in a S7-300 PLC, communicate with all the S5 PLC's via Ethernet and load the data from it to the S7-300. The scada will then speak directly to the S7 instead of the S5 PLC.

Any advice on how I would move the data from the S5 to the S7 would be greatly appreciated. I'm assuming I'll create identical datablocks in the S7 and then transfer the information over the network from the S5. The scada will then need addressing for each tag.

Do you think this is the fastest way to communicate with the S5's and do you think it will solve the problem?

Many thanks
 
Good Morning,

A couple of years ago I had to do just what you desicribe.
I did it with a S7-300 with a CP343 card and a S5 with a CP1430TCP.

It is not really straight forward coding as it involve changes in the code of both PLCs. The S5 part is a bit tricky as I had to use COM1430.

Siemens has the following examples to help with that:
ISO communication
TCP communication

However, I came across a solution recently that is an embeded OPC-UA server that can draw data from S5.
I believe that in your case where you need only visualisation, this is a more attractive solution.
I have used IBHsoftec products in the past but not this one:
IBHsoftec OPC-UA server

I hope that you will use this and then come back and give some feedback ;). It looks very interesting.
 
Great. Thank you for all information. The IBH OPC-UA server looks very interesting.

I'm going to site today to look at the hardware they have and to get a better picture of the whole job. I'm hoping (praying) I can set up a test rig in the office so I can solve any problems I may encounter before I try the real thing. I have some S5 experience, but it was a long time ago.

I understand they are using a Black Box 10BaseT-to-AUI Transceiver to convert the S5 communications to the new scada system. This is one thing I need to look into today.

When you had a similar job, was it because of the same problem with the lag in communications / scada system?

Of course when I've finished this job I will update with all my findings.

Thanks again
 
By the way. I have a feeling the lag could be from using the Black Box 10BaseT-to-AUI Transceiver. If so, I may look into alternatives before going ahead with this method.
 
When I came into that project they had already used the CP1430TCP card. The reason they used this card was that the system was setup using Sinec L1 and it was very slow transmitting data to the SCADA system (Coros & then WinCC).
My guess would be that the your data transmision is delayed because of the Black Box 10BaseT-to-AUI.
The reason we had to do the S5<->S7 communication was that we had to do complex math with the S5 Data. So we chose to Fetch the data from the S5 and process it in the S7.
You can use this adapter Coupled with the IBHsoftec for a complete solution. As I mentioned before, I have used IBH products and I think very highly of them, however I have not used the OPC-UA server before.
I am off to a site tomorrow to look into a project where I need to connect an S5 with an ABB AC500 PLC. I hope there will be an opportunity to use it there.

Regards
Nik
 
By the way. I have a feeling the lag could be from using the Black Box 10BaseT-to-AUI Transceiver. If so, I may look into alternatives before going ahead with this method.

If the AUI converter isn't malfunctioning, that S5-configuration should be quite capable.
It could be that the data areas polled(?) from the Scada are fragmented and many requests are needed.

Check the cycle time of the S5.

Try to call the communication FBs (SEND/RECIVE or SEND-A/RECV-A) several times, spread in OB1.



My 2 öre.

Kalle
 
When I came into that project they had already used the CP1430TCP card. The reason they used this card was that the system was setup using Sinec L1 and it was very slow transmitting data to the SCADA system (Coros & then WinCC).
My guess would be that the your data transmision is delayed because of the Black Box 10BaseT-to-AUI.
The reason we had to do the S5<->S7 communication was that we had to do complex math with the S5 Data. So we chose to Fetch the data from the S5 and process it in the S7.
You can use this adapter Coupled with the IBHsoftec for a complete solution. As I mentioned before, I have used IBH products and I think very highly of them, however I have not used the OPC-UA server before.
I am off to a site tomorrow to look into a project where I need to connect an S5 with an ABB AC500 PLC. I hope there will be an opportunity to use it there.

Regards
Nik

Thanks Nik,

That sounds like a very interesting project, and you've definitely highlighted some things I will be sure to look into.

I visited the site yesterday and have more information on their set up. They are using:

115U CPU 934B
and what I think is a CP143 Sinec H1 Module

They have 3 of these CPU'S and CP143 cards all using the black boxes I mentioned which are going to one switch that is then going to two PC's running almost identical Wonderware Scada control. These Wonderware packages are running through a virtual machine.

We actually replaced one of the PC's yesterday which failed to respond when any functions were pressed. Both Pc's then had to be rebooted and all was OK.

The hardware I've been told we are going to use for the project is:

- S7-300 Mounting Rail 160MM

- SITOP PS307 PSU 120/230VAC 5A

- S7-300 CPU317-2PN/DP 1MB [MMC REQ'D]

- S7-300 CP343-1 2PORT Ethernet Module

- SCALANCE XB008 Unmanaged IE Switch

- SCALANCE X101-1AUI IE M/CON

And I'm assuming the SCALANCE X101-1AUI IE M/CON will replace all 3 of the black boxes reconnecting the original Sinec H1 network to this point. If so, this sounds like it could solve the problem. I hope you think so too?
 
If the AUI converter isn't malfunctioning, that S5-configuration should be quite capable.
It could be that the data areas polled(?) from the Scada are fragmented and many requests are needed.

Check the cycle time of the S5.

Try to call the communication FBs (SEND/RECIVE or SEND-A/RECV-A) several times, spread in OB1.



My 2 öre.

Kalle

Thanks Kalle for your response,

I was wondering yesterday if they have tried replacing any of these black boxes, and I am thinking of asking them to replace them one at a time if they have spares.

From my visit yesterday, I now understand there are two PC's running the same Wonderware package which is making me curious if there is some conflict between them. Or if the introduction of the black boxes has slowed down the network speed just a bit too much for two scada systems.

Oh, and thank you, I will check the cycle time of the S5 when I get a copy of the PLC program.

Thanks again

Russ
 
Lot of effort to keep obsolete S5 PLCs.
The proper solution would be to replace the S5 PLCs.
That will as a side effect solve any communication problem.

Yes, this is the long term plan for the site as well as replacing the scada systems with two HMI's.

Thanks for the advice Jesper

Russ
 
Just so that you are aware of this, on IBHs website it says for the IBH Link UA module:
Connection to S5-PLCs over IBH Link S5++
This means that it needs the mentioned device that connects to the PG port of the S5 PLCs.
The performance is very low because the PG ports communicate with 9600 baud.
 
Dear Jesper,

In my country among other very important things there is a lack of an industrial modernisation mentality. Combine that with the fiscal crisis we are going through and you realise how little opportunity is out there for retrofits.
In most of the cases the mentality is to never change a system if it operates. Then comes a time where the whole production collapses and managers seek explainations on why this the production was not modernized in time (when it was them complaining that they dont have a budget).

Our Company is only involved in S5 projects when they are migrated to modern control systems.
However I can understand other colleagues & companies from countries like mine, where there isn't much buisness opportunity, and they get involved in S5 or other obsolete system projects. They are just trying to make a living out of it. I don't believe that any professional chooses to support an old "finished" system rather than installing a brand new top of the notch PLC.

Regarding the need for IBH Link S5++ I think I mentioned it, but it is a good thing to mention it again.

Regarding the responce time, I quote this from the IBH Link S5++ manual:

  • If optimization can fully work, refresh rates from 200-300ms are realistic. If there is no optimization possible, reading may take a few seconds. An average refresh rate of a second should be a good point to start.
I am not saying that IBHsoftec's is the best solution, but it may be a solution.

@russg
If you transfer data from the S5 to the S7 keep this in mind (Very well typed here):
DB addresses are word oriented in S5. The DW0 in a S5 is equivalent to the DBW0 of a S7. The DW5 of a S5 is equivalent to the DBW10 of a S7. All other addresses within DBs follow this logic.

S5 S7 DL 0 DBB 0 DR 0 DBB 1 DL 1 DBB 2 DR 1 DBB 3 DL 2 DBB 4 DR 2 DBB 5 oder
DW 0 DBW 0 DW 1 DBW 2 DW 1 DBW 4 ... ...
 
RussG has an ethernet-based system already (CP143 Sinec H1), with some kind of unknown bandwidth problem. So I am guessing he is pulling a not-so-small amount of data from the S5 PLCs.

So I doubt that a solution based on anything that goes via the 9600 baud PG port will be faster than what RussG has already got. 200-300 ms will only be possible with very small data volumes.

To get temporary relief, I suggest that RussG aggregate the data via 1 PC, that then distributes the data to the other PC. That can cut the data volume in half.
Depending on what software is used it may be possible or not. With OPC it is possible.
 
From the IBHsoftec OPC-UA description:
"The communication to the S5 and S7 PLC is established over Ethernet. If the PLC has no Ethernet port, our well known gateways IBH Link S7++ or IBH Link S5++ can be used. There are three Ethernet Ports for machine level on the IBH Link UA and one Ethernet Port for the supervision level. On the supervision level only OPC access is allowed. Between both levels there is a firewall integrated."

Later in the same page:
Connection to S5-PLCs over IBH Link S5++.

It is not clear if the OPC can only work with IBH Link S5++. Maybe an email to IBH will give a definate answer. I agree that If there is a big volume of data to be transfered a 9.6kbps solution will be no good.
 

Similar Topics

Dear All Please help me about Below picture problem.PLC not communicating proper.
Replies
4
Views
161
I need to recommend a PC to replace a customer's old Windows 7 computer. The only thing I need to think through is the serial com port to...
Replies
21
Views
640
Hello Friends, We have a powerflex that stopped working sometime last week. It doesn't communicate over the network, or use CCW directly from my...
Replies
1
Views
403
Hi All I'm trying to connect two zebra printers to th PLC through Ethernet. I can ping the Printer through my laptop connected to the private...
Replies
0
Views
338
Have a customer that has a running 1756-l83es, communicating to redundant ABCIP IO servers for Wonderware 2020. This configuration has been...
Replies
7
Views
840
Back
Top Bottom