A few questions about S5<->WinCC communication.

Dear Users,

First and foremost I would like to greet every single one of you, for this is my first post on this forum

What I have is a system consisting of:
a) Several S5 and several S7 PLCs;
b) WinCC V7.0, as an OPC DA Server, communicating with mentioned PLCs via Simatic S5 Ethernet Layer 4, S5-Transport (CP1413-1);
c) External OPC Client that reads values from both S5 and S7.
The CP used is CP1430 TF.
Below I will post the questions I have about the S5 <-> WinCC (working as an OPC Server):

1) If I use Write/Fetch job type and configure WinCC as 'active', does it mean that I can read from every single memory area of my PLC without 'preparing' the data in a specified DB? For example - can I read hardware inputs, outputs or flags directly?
2) Is the action of adding a tag to WinCC enough to enable reading from PLC, given that the communication was configured properly?
3) When going through Com1430 manuals I noticed that Handling Data Block - FB120 is used to 'send' data for both job types: Send and Write. But if it is true that while using Write/Fetch one does not have to specify any data area and one can access the data directly, then what was the point of using FB120(HDB:SEND) or FB122 (HDB: FETCH) with job type: Write/Fetch?
4) Is there any way to communicate with WinCC (working as OPC Server) using job type: Send/Receive? If yes, then how to configure WinCC to act as an initiator of the action (WinCC reads from PLC).
5) Is it possible for gathering all the data to be used in a job type: Write/Fetch in a specified DB to reduce the load on the communication? For example: instead of reading I20.0, F45.0, I23.0, I transfer their values to some DB and use these DB tags on WinCC.

And now the most important!!
6) All the questions lead to the main problem I've been having lately. The communication with all the S7, S5 PLCs, WinCC and some other visualization system (which I don't have access to) seems to be configured fine - data exchange between PLCs works good, data exchange on the line S7 - WinCC works good, but there are some problems with communication S5 - WinCC.
Some tag values read S5 on WinCC simply don't appear or appear only sometimes. For example: I have several Hot Metal Detector sensors and when they detect said hot metal, they give logical '1'. The values are correct on the S5, but when being transfered to WinCC, not only do they not work correctly, but also they come intermittently.

Knowing all that, do you guys have any idea about where to even start looking for a solution? Is there a chance to solve this problem on the 'programming and configuration' level or does it look like more of a hardware problem?

Hoping you can help me find a solution, I remain

Truly yours,
Nattana

Hi and welcome to the forum!


I'll try to answer some of the questions. All based on my fainting memory. (It's at least > 1.5e+01 years since i worked with the S5.)


1) If I use Write/Fetch job type and configure WinCC as 'active', does it mean that I can read from every single memory area of my PLC without 'preparing' the data in a specified DB? For example - can I read hardware inputs, outputs or flags directly?

'Active' means that the WinCC initializes the connection.
In the S5 you must run 3 FB's even if it is passive:
- FB "Synchron" to initiate the CP-card, called from OB20/21/22.

- FB "Send-A" and FB "Receive-A" from OB1.
Alternatively
- FB "Send" with Auftragsnr 0 (==send all)
and FB "Receive" with Auftragsnr 0 (==receive all).

Note that these FB-calls MUST be proceeded by VKE = TRUE.
O M 199.0
ON M 199.0
SPA FB120
..





2) Is the action of adding a tag to WinCC enough to enable reading from PLC, given that the communication was configured properly?
Cannot remember/don't know.

3) When going through Com1430 manuals I noticed that Handling Data Block - FB120 is used to 'send' data for both job types: Send and Write. But if it is true that while using Write/Fetch one does not have to specify any data area and one can access the data directly, then what was the point of using FB120(HDB:SEND) or FB122 (HDB: FETCH) with job type: Write/Fetch?

Yes, if you mean an active PLC that is to get data from a passive partner.

No, if you mean a passive plc. Then only the Send-A / Receive-A is required.



4) Is there any way to communicate with WinCC (working as OPC Server) using job type: Send/Receive? If yes, then how to configure WinCC to act as an initiator of the action (WinCC reads from PLC).
Cannot remember and don't have WinCC at hand.

5) Is it possible for gathering all the data to be used in a job type: Write/Fetch in a specified DB to reduce the load on the communication? For example: instead of reading I20.0, F45.0, I23.0, I transfer their values to some DB and use these DB tags on WinCC.

Yes, that is wise.

And now the most important!!
6) All the questions lead to the main problem I've been having lately. The communication with all the S7, S5 PLCs, WinCC and some other visualization system (which I don't have access to) seems to be configured fine - data exchange between PLCs works good, data exchange on the line S7 - WinCC works good, but there are some problems with communication S5 - WinCC.
Some tag values read S5 on WinCC simply don't appear or appear only sometimes. For example: I have several Hot Metal Detector sensors and when they detect said hot metal, they give logical '1'. The values are correct on the S5, but when being transfered to WinCC, not only do they not work correctly, but also they come intermittently.

Check that the Send-A and Recv-A function called with the VKE=TRUE as mentioned above.

If you need more 'bandwidth', call those blocks several times from OB1, well spread inbetween the process programs.


Knowing all that, do you guys have any idea about where to even start looking for a solution? Is there a chance to solve this problem on the 'programming and configuration' level or does it look like more of a hardware problem?

You can connect online to the CP1413 by using COM 1413 / COM143 or I think also COM 535 and the AS511 cable (not all converters can, dependant of power supply on pin nr ...oh, forgotten). You can study the different jobs, and look out for status info. Note that this does a heavy load increase on the CP-card.

Good Luck
Kalle

Dear KalleOlsen,

Thank you very much for your input. I will definitely make use of it, but if you don't mind, I would like to ask some more

KalleOlsen said:

'Active' means that the WinCC initializes the connection.
In the S5 you must run 3 FB's even if it is passive:
- FB "Synchron" to initiate the CP-card, called from OB20/21/22.

- FB "Send-A" and FB "Receive-A" from OB1.
Alternatively
- FB "Send" with Auftragsnr 0 (==send all)
and FB "Receive" with Auftragsnr 0 (==receive all).

Note that these FB-calls MUST be proceeded by VKE = TRUE.
O M 199.0
ON M 199.0
SPA FB120
..

Click to expand...

Yeah, I do have all three FB's. VKE = TRUE means that the call has to be unconditional? Sorry, I'm not proficient in German

But I still am not sure if the 'reading part' of my post is correct. I will try to be more clear. For example, communication between PLC1 and PLC2 is done via FB120 (SEND) and FB121 (RECEIVE). These blocks are present on both PLCs and the data to be transfered is kept in prepared Data Blocks, for example DB30 for Send and DB31 for Receive.

But I am not sure whether there should be a similar pattern to WRITE/FETCH communication with WinCC or not. What I mean is that I have prepared data that is supposed to be trasnfered to WinCC, but it isn't used in any communication-supporting blocks (send, receive, fetch - neither of these). So does that mean it is just how it's supposed to work? Because it does work in this manner. It's just that the fact that SOMETIMES and only with SOME signals I have problems with communication on PLC-WinCC line, made me dig deeper and try to understand if the settings and configuration I've been using up till now is good.

KalleOlsen said:

Yes, if you mean an active PLC that is to get data from a passive partner.

No, if you mean a passive plc. Then only the Send-A / Receive-A is required.

Click to expand...

Well, my PLCs are passive for both actions. So if WinCC writes and reads to/from passive PLC, Fetch and Send blocks aren't needed at all, correct?

KalleOlsen said:

Check that the Send-A and Recv-A function called with the VKE=TRUE as mentioned above.

If you need more 'bandwidth', call those blocks several times from OB1, well spread inbetween the process programs.

Click to expand...

I would be grateful if you explained what VKE=TRUE means, because as I said before, I assume it is some abbreviation in German which I'm not familliar with

As for the 'bandwidth', I checked the program I have and the communication HDBs SEND-ALL and RECEIVE-ALL nested in some other FBs and PBs, which are then called in OB1. And this happens at the end of OB1, after most of actions have been already processed. So, not only is it not possible to call JUST SEND-ALL and RECEIVE-ALL, but also calling these blocks before the data to be sent is prepared doesn't sound too good.

But tell me, what if I called SEND-ALL right after another SEND-ALL. Is there any chance it helps?

KalleOlsen said:

You can connect online to the CP1413 by using COM 1413 / COM143 or I think also COM 535 and the AS511 cable (not all converters can, dependant of power supply on pin nr ...oh, forgotten). You can study the different jobs, and look out for status info. Note that this does a heavy load increase on the CP-card.

Click to expand...

I will surely check all the configuration setting when I go back to the site. If I remember correctly I have CP1413 software in the Step5 environment we have used.

And two more questions.
1) I am not sure if you are familliar with this, but still. If I condensed and gathered all the data in one DB AND tried to read it in WinCC as 'Raw Data Type', would this lessen the load on the communication?
2) Are you maybe familliar with whether reading directly from hardware inputs/outputs (I, Q) or flags (F) may strain communication more than reading from Data Blocks?

Sincerely yours,
Nattana

VKE means "Verknüpfungsergebnis", should be RLO "result of logic operation" in english.

A fetch request can read a block with one single area (DB, PEW, PAE) and a maximum size of 255 bytes.
WinCC says to the S5: "hey, give me 100 bytes from DB100, from start address 50" and the S5 sends this data back.

WinCC has a packing mechanism also for S5 communication. If you have two tags DB100.DW0 and DB100.DW10, then WinCC should read 12 bytes, because it's more efficient/faster. If you have many tags from different datablocks, then it needs many request what makes the communication rather slow.

With S7 communication for packing in WinCC it's relevant that you use the same update cycle for the tags when they are used in a graphics object. I guess for S5 this is the same.

Yeah, I do have all three FB's. VKE = TRUE means that the call has to be unconditional? Sorry, I'm not proficient in German

As ThomasV2 stated, it is called RLO in English coding.
What I ment is that you must be sure that the logic result is '1' when calling the FB120/121.

I will try to be more clear. For example, communication between PLC1 and PLC2 is done via FB120 (SEND) and FB121 (RECEIVE). These blocks are present on both PLCs and the data to be transfered is kept in prepared Data Blocks, for example DB30 for Send and DB31 for Receive.

To initiate a Send/Fetch, you need to refer to a job number (A-NR German Auftragsnr) that is defined with COM1413.
When you go online with COM1413, be sure to load the settings from the CP to the PC. Search for the job number definitions, and you'll probably understand more of the secret magic.


But I am not sure whether there should be a similar pattern to WRITE/FETCH communication with WinCC or not. What I mean is that I have prepared data that is supposed to be trasnfered to WinCC, but it isn't used in any communication-supporting blocks (send, receive, fetch - neither of these). So does that mean it is just how it's supposed to work?

No, the PLC is still passive. The WinCC sends a datagram with an RK512 -like header. This header includes (as ThomasV2 says) the data type (I/Q/DB) the start address and the length. This is received, interpreted and responded with the FB121/120 (Recv-A/Send-A).


Because it does work in this manner. It's just that the fact that SOMETIMES and only with SOME signals I have problems with communication on PLC-WinCC line, made me dig deeper and try to understand if the settings and configuration I've been using up till now is good.

This could happen if the RLO is not minded before call of FB120 / 121. ...as I have pointed several times.

Well, my PLCs are passive for both actions. So if WinCC writes and reads to/from passive PLC, Fetch and Send blocks aren't needed at all, correct?

Correct.

I would be grateful if you explained what VKE=TRUE means, because as I said before, I assume it is some abbreviation in German which I'm not familliar with

VKE = RLO
Set to true f.x. like this

O M 199.0
ON M 199.0
JU FB120
:
And the same before jumping to FB121.

As for the 'bandwidth', I checked the program I have and the communication HDBs SEND-ALL and RECEIVE-ALL nested in some other FBs and PBs, which are then called in OB1. And this happens at the end of OB1, after most of actions have been already processed. So, not only is it not possible to call JUST SEND-ALL and RECEIVE-ALL, but also calling these blocks before the data to be sent is prepared doesn't sound too good.

I disagree. Try it.


But tell me, what if I called SEND-ALL right after another SEND-ALL. Is there any chance it helps?

It might do, but I have allways distributed the calls evenly.

And two more questions.
1) I am not sure if you are familliar with this, but still. If I condensed and gathered all the data in one DB AND tried to read it in WinCC as 'Raw Data Type', would this lessen the load on the communication?

Yes, it is still wise. Look at ThomasV2's post.


2) Are you maybe familliar with whether reading directly from hardware inputs/outputs (I, Q) or flags (F) may strain communication more than reading from Data Blocks?

Yes, yes, yes.


Kalle

Dear Thomas_v2 and KalleOlsen,

Thomas_v2 said:

A fetch request can read a block with one single area (DB, PEW, PAE) and a maximum size of 255 bytes.
WinCC says to the S5: "hey, give me 100 bytes from DB100, from start address 50" and the S5 sends this data back.

WinCC has a packing mechanism also for S5 communication. If you have two tags DB100.DW0 and DB100.DW10, then WinCC should read 12 bytes, because it's more efficient/faster. If you have many tags from different datablocks, then it needs many request what makes the communication rather slow.

With S7 communication for packing in WinCC it's relevant that you use the same update cycle for the tags when they are used in a graphics object. I guess for S5 this is the same.

Click to expand...

Thank you very much for your input! The information you posted clarified some of my questions about how precisely the Fetch/Write job type works.

And just so I am sure I understood what you wrote. If for example I have tags that in WinCC that try to read from: DB30.D0.0, DB30.D0.4, I30.0, I30.3, I31.1.

Will WinCC read the whole byte D0 in DB30 or just the single bits? Same for hardware inputs. Do you maybe have any documentation on this packing mechanism in WinCC? I would like to know more

KalleOlsen said:

As ThomasV2 stated, it is called RLO in English coding.
What I ment is that you must be sure that the logic result is '1' when calling the FB120/121.

Click to expand...

Yeah, thank you I use unconditional calls so I guess everything is ok here

KalleOlsen said:

To initiate a Send/Fetch, you need to refer to a job number (A-NR German Auftragsnr) that is defined with COM1413.
When you go online with COM1413, be sure to load the settings from the CP to the PC. Search for the job number definitions, and you'll probably understand more of the secret magic.

Click to expand...

Yeah I know that. ANR 0 is for Send-All I believe, and for typical Send operations it is 1 and up, correct? I also know that there are some special ANR numbers around 250~ area. I will definitely search for more information about ANR, looks like the CP1430 manuals didn't have enough information

KalleOlsen said:

No, the PLC is still passive. The WinCC sends a datagram with an RK512 -like header. This header includes (as ThomasV2 says) the data type (I/Q/DB) the start address and the length. This is received, interpreted and responded with the FB121/120 (Recv-A/Send-A).

Click to expand...

I see. So if I try to read from different DBs, hardware inputs I or flags at the same time, it means that mentioned header has to be sent several times with different headers to enable reading from all those data areas? If it works like this, packing everything up to a single data block may reduce the load on the communication way more than I initially thought

KalleOlsen said:

This could happen if the RLO is not minded before call of FB120 / 121. ...as I have pointed several times.

Click to expand...

What about FB126/FB127 (SEND-ALL/RECEIVE-ALL)?

Because now that I looked in the program I have, FB120/FB121 (SEND/RECEIVE) are called with JU (Unconditional Call), but FB126/FB127 are called with JC (Conditional Call - if RLO is "1")...

I will definitely have to check this.

KalleOlsen said:

I disagree. Try it.

Click to expand...

Okay, I definitely will once I get back to the site.


Again, thank you so much for help. My experience with S5 is close to being non-existent , so I hope my questions do not irritate you too much (even if they are trivial to you).

Sincerely yours,
Nattana

What about FB126/FB127 (SEND-ALL/RECEIVE-ALL)?

Because now that I looked in the program I have, FB120/FB121 (SEND/RECEIVE) are called with JU (Unconditional Call), but FB126/FB127 are called with JC (Conditional Call - if RLO is "1")...

I will definitely have to check this.

FB126 acts like FB120 with A-NR = 0,0
FB127 acts like FB121 with A-NR = 0,0

Both should allways be called with RLO = 1.


I forgot to mention that these FBs can be parametrized indirectly via some DB interface. Then they can appear with some default, zero settings that are substituted with values from a DB. One have to investigate the FB calls to find out.


Regards
Kalle

KalleOlsen said:

What about FB126/FB127 (SEND-ALL/RECEIVE-ALL)?

Because now that I looked in the program I have, FB120/FB121 (SEND/RECEIVE) are called with JU (Unconditional Call), but FB126/FB127 are called with JC (Conditional Call - if RLO is "1")...

I will definitely have to check this.

FB126 acts like FB120 with A-NR = 0,0
FB127 acts like FB121 with A-NR = 0,0

Both should allways be called with RLO = 1.


I forgot to mention that these FBs can be parametrized indirectly via some DB interface. Then they can appear with some default, zero settings that are substituted with values from a DB. One have to investigate the FB calls to find out.

Regards
Kalle

Click to expand...

Hi Kalle,

Sorry to be replying to your post this late. Was busy during the weekend.

Now that I checked FB126 and FB 127, I can confirm they are called with Conditional Calls, but... the condition for them to trigger is 'A F 0.1', where F0.1 is a flag that is ALWAYS TRUE... Honestly, I don't think there is a difference between JU and JC with condition that is always '1'

And about the DB interface - yes, I noticed that. It was confusing at first, I won't deny

Okay, thank you once again for your replies and for your help. I hope I will not have to revive this thread and bombard it with further questions in the future

Sincerely yours,
Nattana