Hello Siemens Community,

We’re currently facing an issue while trying to establish inter-PLC communication between two S7-400 Automation Stations (AS) located in different areas, but under the same PCS 7 multi-project.

✅ System Setup:

• PCS 7 Version: [PCS 7 V9.0 SP3]
• AS Type: S7-400 (one per area/project)
• Configuration: Multi-project (each AS in a separate project, integrated into one multiproject)
• Objective: Exchange data specifically to command pumps of area 2 using the scada of area 1 (e.g., boolean/real tags) between AS1 and AS2

🧪 What We’ve Tried So Far:

1. CFC-to-CFC Signal Linking:

• Linked outputs/inputs across CFC charts between both AS stations.
• Performed automatic NetPro download.
• Moved CFC blocks of both AS into OB33 (cyclic task).
• Downloaded both AS successfully.
• ✅ Result: No data exchange observed. Signals not updating between AS.

2. Standard GET/PUT Blocks:

• Implemented GET/PUT blocks on both AS (with matching partner DBs).
• Configured correctly in NetPro (partner info, routing).
• No known issues with subnet or firewall (same network).
• ✅ Result: Still no signal communication.

3. One-Sided GET Setup:

• Tried using only a GET block on the active AS side.
• Passive AS only contains the necessary target DB.
• Configured with correct partner ID, DB, and IP address.
• ✅ Result: No signal received. Communication not established.

⚠️ Additional Context:

We’ve used the same GET/PUT blocks before in a different setup within the same multiproject, to communicate between an S7-400 and an S7-1500 (TIA Portal) — and it worked flawlessly. This shows our base configuration and approach for GET/PUT is functional under the current network and PCS 7 version.

📌 Questions / Assistance Needed:

1. Are there any additional NetPro, routing, or SDB steps specific to S7-400-to-S7-400 communication in a multiproject setup?
2. Should one AS always be set to GET only and the other fully passive (DB only)? Any known limitations on simultaneous PUT/GET from both?
3. Do we need to manually export/import SDBs or routing tables for the partner AS into each project?
4. Any project structuring rules or recommendations for handling multi-area communication within PCS 7?

🧾 Notes:

• AS stations are on the same Ethernet network.
• All blocks are placed in OB33 for cyclic behavior.
• No CP cards used — CPU communication only.
• Communication worked previously between S7-400 (PCS 7) and S7-1500 (TIA).

Any suggestions or guidance would be highly appreciated!

Best regards,
Jec

#1 should work without needing to do get/put.

Check:

1. The netpro connections were created manually by you or by CFC when you made the first cross controller interconnection?
2. You downloaded both controllers netpro?
3. Controllers must be in the same subnet, I'm not sure how this wouldn't be possible, but just checking.
4. What does the netpro connection say when you monitor it online?
5. Do you have any alarms coming from the @IK blocks?

RVS.wick

#1 should work without needing to do get/put.

Check:

1. The netpro connections were created manually by you or by CFC when you made the first cross controller interconnection?
2. You downloaded both controllers netpro?
3. Controllers must be in the same subnet, I'm not sure how this wouldn't be possible, but just checking.
4. What does the netpro connection say when you monitor it online?
5. Do you have any alarms coming from the @IK blocks?

 Hi, RVS.wick

 At first try, the netpro is auto created and then we try to download it. But shows no solution, the problem still occurs.  

After it didn't work, we deleted it then we create new netpro then we started using get/put.

We doesn't any receive alarm or errors . 

I don't know why it wouldn't work.  @IK alarms only are created after you compile/download AS & OS when using CFC native AS<>AS connections (after compiling charts and correctly executing all downloads including netpro).
Are you sure you downloaded both AS's worth of NetPro?  When you monitor the online state of netpro, what does it show?  “connection being set up”?

Since you haven't seen any connection even with Get/Put, I think its something I already listed above such as mismatch subnet or AS can't even see each other somehow, or procedural with your steps.

RVS.wick

I don't know why it wouldn't work.  @IK alarms only are created after you compile/download AS & OS when using CFC native AS<>AS connections (after compiling charts and correctly executing all downloads including netpro).
Are you sure you downloaded both AS's worth of NetPro?  When you monitor the online state of netpro, what does it show?  “connection being set up”?

Since you haven't seen any connection even with Get/Put, I think its something I already listed above such as mismatch subnet or AS can't even see each other somehow, or procedural with your steps.

 Thank you for your answer RVS.wick, the status on NetPro is "connection being set up"

Assuming you see "connection being set up' on both AS (not just one), then most likely the Netpro has been downloaded correctly.

But it means there is still an issue in one of the following places, my best guess is #1:

1. Physical network (connection path does not exist between the controllers due to connections/firewall/gateway etc.)

2. Program not configured - in your case get/put not configured correctly (unless you switched back to CFC method) with the ID's and data sizes, etc.

3. Somehow incorrect configuration of networks & incompatible/wrong IPs, but seems unlikely if you were able to make CFC based interconnections before, it never would have let you succeed in the past.  Assuming all OS communication also working, but you should still also check your named connection names are all configured correctly too.

RVS.wick

Assuming you see "connection being set up' on both AS (not just one), then most likely the Netpro has been downloaded correctly.

But it means there is still an issue in one of the following places, my best guess is #1:

1. Physical network (connection path does not exist between the controllers due to connections/firewall/gateway etc.)

2. Program not configured - in your case get/put not configured correctly (unless you switched back to CFC method) with the ID's and data sizes, etc.

3. Somehow incorrect configuration of networks & incompatible/wrong IPs, but seems unlikely if you were able to make CFC based interconnections before, it never would have let you succeed in the past.  Assuming all OS communication also working, but you should still also check your named connection names are all configured correctly too.

 Hi RVS.wick

I haven't mentioned earlier that the CPU B uses named connection while the CPU A uses Industrial Ethernet because for some reason during early stages of creating the project, the CPU A cannot establish a communication thru Named Connection so we decided to use IE which works well. 

My Question is, is there other way for this two PLC to communicate with each other? 

Having issue on one controller not being able to use named connections to me means there is something in your network settings.  Maybe you need a gateway address but didn't configure it, or something else.  Or maybe you are doing your NetPro downloads wrongly.  I'm not sure, there are so many possibilities.

Regarding alternate ways to communicate, of course there are many, however all of them are going to require either same networking to be resolved or using extra hardware (like PB coupling via CP, or PN/PN coupling, etc.).

Looking at your original use case, do you need to send commands from one AS to another or simply you want to issue commands from different HMI area and you are using the AS<>AS to do this?  You know in this case you could just build connection for those OS to both AS, but anyhow eventually you will have a use case for AS<>AS and you'll need to solve your problem.  

SOLVED!! Thanks for the help, everyone! We managed to solve the problem. It turned out the PLC was connected to the terminal bus instead of the plant bus like the others. Once we connected it to the correct plant bus, everything started working.