FC5, FC6, AG_SEND and AG_RECV

leem2209

Lifetime Supporting Member
Join Date
May 2015
Location
Wirral, UK
Posts
210
I'm trying to understand how the various PLC's in our machine are communicating and I've gotten so far but come with a bit of a dead end...

Basic info on the machine....
There's 10 PLC's in total, 9 for various sections and one "Central PLC" all connected via Profibus. The CentPLC is then connected to the factory DCS system.

PLC1 <-> |----------|
PLC2 <-> | Cent PLC | <-> Factory DCS
PLC3 <-> |----------|

So, I know which Data blocks transfers information to the Central PLC (CentPLC) and back again, one example is as follows:

PLC1 DB119.DBX260.0 - AG_SEND ----> AG_RECV - CentPLC DB791.DBX260.0
PLC1 DB19.DBX0.0 - AG_RECV <---- AG_SEND - CentPLC DB701.DBX20.0

Looking up info on AG_SEND and AG_RECV I can see that you set the component address and the starting DB address and length of data to send/receive, which all makes sense.

So each individual PLC has an FC5 (AG_SEND) and FC6 (AG_RECV) and I'm imagining that FC5 and FC6 in the CentPLC has numerous AG_SEND and AG_RECV for each PLC it will communicate to. Unfortunately I cant see the programming of FC5 and FC6 as they are protected.

My Questions:

Is there any way I can view the program in these functions?

If I am right about multiple AG_RECV in CentPLC, how does each AG_RECV know which AG_SEND to communicate with?

Can anyone show me an example of what the programming would look like in FC5/FC6?

I hope this makes sense!

Cheers...
 
You dont have to know the inside of those blocks. What is important are the destination and source dbs which you have already mentioned, and the connection IDs. The IDs are defined in NetPro.
 
Thanks Jesper...

But out of curiosity, how does the CentPLC know which addresses to to associate with which PLC?

Also, I've rarely looked at netpro, I had a little nosey and didn't know where to find the connection ID, the example I saw somewhere wasn't the same as what I was looking at.
 
Last edited:
NetPro

Hi,

NetPro manages this. When you make a S7 connection in NetPro you have to download the configuration to both CPU's. NetPro will show this by marking these CPU's orange in NetPro.

Read this document:
https://cache.industry.siemens.com/dl/files/518/17628518/att_69375/v1/s7_connection_en.pdf

Kind Regards,
G



Thanks Jesper...

But out of curiosity, how does the CentPLC know which addresses to to associate with which PLC?

Also, I've rarely looked at netpro, I had a little nosey and didn't know where to find the connection ID, the example I saw somewhere wasn't the same as what I was looking at.
 
Another question I have thought of during my sleep...
If I didn't know which PLC DB related to CentPLC DB, how could I find that out if I cant access FC5/6 to see the addressing?
 
You dont need to look inside the AG_SEND/AG_RECV blocks.
Look at the calls of these blocks.
For AG_SEND, the "SEND" pin has an ANY pointer that points to the source DB.
For AG_RECV, the "RECV" pin has an ANY pointer that points to the destination DB.
 
Jesper, forgive me if I'm missing something, but aren't the AG_send and AG_recv in FC5/6? So as I can't access FC5/6, I can't see what the source and destination pointers are...
 
FC5/6 are just send/receive blocks. There's nothing on the inside that's going to make any sense to you. Heck, unless your STL is superb, it's not going to make a lot of any sense.

Usage of FC5/FC6:
Each is part of a unique pair.
What makes them unique?
The parameters supplied.
ID: Connection ID which is generated in NetPro.
LADDR: Which CP it needs to use as the ID is NOT unique. For each CP it is unique, but if you have several CP's, you can have the same ID several times. The combination of ID + LADDR is unique.

Those 2 parameters are how you find out between which PLC's the FC5/FC6 is used.
If you have several PLC's communicating with the same centralized PLC, then the latter will either contain at least one set of FC5/FC6 per connection, or the parameters will all be supplied indirectly, thus changing when needed.

How do you find out what data is being sent where?
The hard way.
Open Project containing the centralized PLC > Open NetPro via Options->Configure Network > Click on the CPU of the centralized PLC.
Not the icon of the PLC, but the lil block right next to it saying 'CPU'.
In the lower part of the screen, you should now get a list of all configured connections to/from that PLC.
Local ID: The ID used in FC5/6. NOTE: it is displayed in HEX in this list, while it is used as decimal in the editor.
Partner ID: If the connection partner is a Siemens PLC AND it's in the same project, it will display the ID used in the partner PLC. If not, then this space is blank.
If you double click on either of these, you should get the properties window. This window shows what is used in FC5/FC6 for ID/LADDR in the Block Parameters-section.
Partner: The connection partner.
If the connection partner is present in the project, you will see the configured name for that PLC/Device.
If the connection partner is NOT present in the project, the name is configured in the Properties window > Local Endpoint > Name.

Now you have a list of connections and their parameters.
Now you use the cross reference to find all uses of FC5/FC6.
You will have to check each of them, one by one, to see what data it sends to which connection.

Example 1:
Code:
      CALL  "AG_SEND"
       ACT   :=M82.0                    
       ID    :=2                        
       LADDR :=W#16#FFD                 
       SEND  :=P#DB82.DBX300.0 BYTE 100 
       LEN   :=100                      
       DONE  :=M82.1                    
       ERROR :=M82.2
       STATUS:=DB82.DBW2
Pretty straightforward.
It sends 100 bytes of data, starting at DB82.DBX300.0 to the PLC that is configured on connection ID 2 on CP configured as W#16#FFD.

And in the attached screenshot (connection_2), we can see the configured connection with local ID 2 (as is seen used in the AG_SEND usage above), the partner PLC, its ID (15), its IP-address, etc

In the partner PLC we find:
Code:
      CALL  "AG_RECV"
       ID    :=15                       
       LADDR :=W#16#1FE1                
       RECV  :=P#DB80.DBX300.0 BYTE 100 
       NDR   :=M84.3                    
       ERROR :=M84.4                    
       STATUS:="CommsDB".recvStat       
       LEN   :=MW86
Connection ID is 15, so we know it's coming from the centralized PLC, we can see this in the screenshot supplied.
We can also see it receives 100 bytes of data, which it puts in DB80, starting at DB300.0

For each and every connection you see in that screenshot, there is a FC5 (AG_SEND) and FC6 (AG_RECV) in the PLC software of the respective PLC's.
In the centralized plc, you should have several FC5/6 calls.

Example 2:
Code:
      CALL  "AG_SEND"
       ACT   :="LN02_PRI01".SEND.Bits.ACT
       ID    :=51
       LADDR :=W#16#FFD
       SEND  :=#SendPntr
       LEN   :="LN02_PRI01".SEND.LEN
       DONE  :="LN02_PRI01".SEND.Bits.DONE
       ERROR :="LN02_PRI01".SEND.Bits.ERR
       STATUS:="LN02_PRI01".SEND.STAT
Data is sent to ID 51 on CP W#16#FFD.
What data this is? Well you'll have to check the software to see how the ANY-pointer is being generated.
As you can see in screenshot (connection_51), there are quite a few parameters not present that were present in the first example.
This is because the connection partner is not present in the project. The connection is to a printer.


Now that you have the list and data it sends/receives from the Centralized PLC, you need to check the other PLC's that are configured partners.
Each of them should have a FC5/6 call which will supply the information on which data is sent/received.


Hope this helps.

PS: If you want to know where the W#16#FFD comes froms:
HardwareConfig > Double click on CP > Addresses > Inputs
The configured number is the Decimal representation, while NetPro uses the Hex value
FFD = 4093
1FE1 = 8161

Connection_2.jpg Connection_51.jpg
 
You have to look in the blocks that calls FC5 and FC6.
AG_SEND and AG_RECV are the symbolic names of the blocks FC5 and FC6 from the SIMATIC NET CP library.

One thing that may confuse is if the original programmer has changed the symbolic names or the block numbers. It is normal to not change them, but not impossible.
 
Jeebs... alot of advice there, thank you very very much!

I followed what you said and found where FC5 and FC6 is called for in each PLC.

Hoping it would show me the DB address and the length of data, but no, just to make things already more confusing! Here is one of them:


Code:
Network 3: Receive - FB
Comment:

   CALL       "_FC_AG_RECV"
     ID       :=#ID
     LADDR    :=#LADDR
     RECV     :=#anyZeiger_receive 
     NDR      :=#NDR
     ERROR    :=#ERROR_REC
     STATUS   :=#Status
     LEN      :=#LEN

So, now not only would I have to search through each PLC to find the calls for FC5 and FC6, check Netpro for all the connection paths as stated, I also need to work out where each ANY is generated!

Although I have a (crude) list of what DB goes where, I couldn't work out how I would find that information if it wasn't for this list.

Now I have a much better understanding, and should I find myself on a machine without documentation, I now know how to find it out, even if it is a lot of work!

Thank you to Jeebs, JesperMP and Combo for all your advice!

:geek:

I love this forum
 
The variable #anyZeiger_receive is declared in the calling FB. You can see that by the leading "#". It means it is defined by the declaration part of the FB (you see that at the top of the editor window).
If anyZeiger_receive is a a STAT or TEMP Just search for "anyZeiger_receive" within the FB.
If anyZeiger_receive happens to be an IN variable, it means it is passed to the FB from the block that calls this FB (this the most likely scenario, otherwise the ANY pointer would just have been stated directly as in Jebs 1st example)
 
Last edited:
As Jesper said, check to see how the #anyZeiger_receive is declared.
If it's an IN/IN_OUT parameter, you need to look how this FB is being called.
If it's a STAT/TEMP, highlight #anyZeiger_receive > CTRL+F to search the FB.
You should be looking for 'LAR1 P##anyZeiger_receive'
Then a few statements like:
Code:
      L     W#16#1002                   // Siemens ID, Type BYTE
      T     W [AR1,P#0.0]
      L     100                         // Length
      T     W [AR1,P#2.0]
      L     171                         // DB number
      T     W [AR1,P#4.0]
      L     P#DBX 22.0                  // Area identifier
      T     D [AR1,P#6.0]
The above code generates an any-pointer P#DB171.DBX22.0 BYTE 100
The 'L P#DBX 22.0' can also be written as:
Code:
      L L#22
      SLD 3
If #anyZeiger_receive is NOT declared as a TEMP variable, you can always use a VAT to see the values of the any-pointer.
NOTE: you can't view it as an any-pointer in a VAT, but you can view it as 3 words and a double word, allowing you to easily decode the value.
 
If I hover over #anyZeiger_send, a comment box comes up showing it is a TEMP parameter.

Highlighted and searched and as Jeebs stated, the code is this:

Code:
LAR       P#anyZeiger_send
L         W#16#1002
T         LW [AR1, P#0.0]

L         #LEN
T         LW [AR1, P#2.01]

L         #DW_SEND_START
SLD       3
OD        DW#16#840000000
T         LD [AR1, P#6.0]

L         "Scmiermerkerwort_MW252"
T         LD [AR1, P#4.0]

Then I trace back #DW_SEND_START to a block which does Old/New comparison and calls another FC.... and #LEN is the same...

I could be here forever tracing back!

It all makes much more sense know though and my curiosity has died down.

Thanks again guys! (y)
 

Similar Topics

using comm module fc4a-hpc1 (rs232) on idec and connectd to g306 and i have no comm. I believe the settings might be off. Any ideas? Where to get...
Replies
1
Views
1,572
Can anybody see what's wrong with the following screen dump? I need to display an integer in a text field (a 20 character String). Originally I...
Replies
30
Views
10,432
Hello... Friends I have IDEC microsmart FC6A - c24r2 PLC... I need to format the old program in that... it was password protected. How do I...
Replies
0
Views
689
Theres probably a simple solution to this but cant seem to figure it out. I am making an addition to an existing piece of S7 software for a...
Replies
3
Views
2,685
So I had an odd request from a customer for the above. I have written the logic and tested it all in one PLC with only using 7 outputs and 7...
Replies
15
Views
427
Back
Top Bottom