Hello everyone,

I’m curious about integrating an S7-1500 PLC with an IPC running a C++ program. I want to understand how to establish communication between the PLC and the IPC using PROFINET.

Could anyone provide guidance on the best practices for setting up PROFINET communication in this scenario? Specifically, I’m looking to:

1. Configure the IPC as a PROFINET IO Device.
2. Set up the PLC as the IO Controller.
3. Exchange data (such as measurement values) in real-time.
4. I’m also curious about the efficiency of PROFINET communication. Are there potentially better alternatives, such as using OPC UA, or other communication methods, that might be more suitable?

Additionally, if anyone has any tutorials or resources that could help with this setup, I would greatly appreciate it.

Thank you!

We have literally hundreds of S7-1200/'1500 PLCs communicating with Visual Basic and VC# (using Visual Studio).

We chose direct connection between the PLC and PC (no routing) which allows for UDP communications.

Since UDP is blind, it is very light-weight on the network, fast, and efficient.

However, you lose the acknowledgements and determinism of TCP (and by extension, ProfiNET).

I suggest using the Snap7 library integrated into your C++ program.

Or, purchase the s7-1500 that allows you to externally execute certain code blocks (FBs) on the PC and use that approach for extreme integration and for very demanding application integration.

There is a wide range of approaches.

Most people will be very happy with Snap7 despite its limitations (DBs must be non-Optimized DBs, for example).

Please advise your path forward and a bit more about the project specs/requirements that led to having a PC running a C++ program in parallel with PLC logic and being forced to have them talk back and forth.

Vladyslav_

Hello everyone,

I’m curious about integrating an S7-1500 PLC with an IPC running a C++ program. I want to understand how to establish communication between the PLC and the IPC using PROFINET.

Could anyone provide guidance on the best practices for setting up PROFINET communication in this scenario? Specifically, I’m looking to:

1. Configure the IPC as a PROFINET IO Device.
2. Set up the PLC as the IO Controller.
3. Exchange data (such as measurement values) in real-time.
4. I’m also curious about the efficiency of PROFINET communication. Are there potentially better alternatives, such as using OPC UA, or other communication methods, that might be more suitable?

Additionally, if anyone has any tutorials or resources that could help with this setup, I would greatly appreciate it.

Thank you!

 

The S7-1500 PLC is responsible for deterministic machine control tasks such as conveyor and cutting machine control, sequencing, interlocks, and HMI interaction.

The PC running a C++ application is used for machine vision tasks. The application processes data from a line-scan camera, stitches acquired lines into a 2D representation, and performs precise image-based measurements (around 0.1 mm accuracy) on boards several meters long after they have been cut.

After the dimensional measurements and analysis are completed, the C++ application performs correction calculations, and the results are sent back to the PLC so that the cutting machine parameters can be adjusted if the measured dimensions are outside the specified tolerances.

Because of this separation of responsibilities, communication between the PLC and PC is limited to high-level data exchange, such as:

• Measurement results (length, width, OK/NOK)
• Calculated correction values for the cutting machine
• Simple trigger and handshake signals

In this situation, I think Snap7 is sufficiently powerful to transfer contents of an entire DB in each direction within the required times.

Look at the Snap7 library.  Here's just one /r topic about it:

https://www.reddit.com/r/PLC/comments/1fm5xh2/experiences_with_snap7/

If you need .NET, they mention "Sharp7" (C# vs C++).

That said, they mention using open source / free OPU UA communications in symbolically addressed (S7-1200/1500) PLCs.

FYI, the VB/C# applications I mentioned all use non-optimized DBs and have to disable security and fully enable put/get for things to work.  These have their own isolated networks, so the security concerns are merely between a non-connected network adapter and all the controls hardware, with a 2nd network adapter connected to a company (firewalled/segmented) network.

No PLC - PLC comms are available with this approach, but that's appropriate for our always isolated systems.

For a production line, OPC UA may be a better approach as you can use security, force secure connections, and still get good performance and reliability.

And, you (most likely) do not really want to establish a true "ProfiNET" connection - (because) that typically will require joining the Profibus/Profinet alliance to get access to necessary details only available inside that paywall.

Vladyslav_

The S7-1500 PLC is responsible for deterministic machine control tasks such as conveyor and cutting machine control, sequencing, interlocks, and HMI interaction.

The PC running a C++ application is used for machine vision tasks. The application processes data from a line-scan camera, stitches acquired lines into a 2D representation, and performs precise image-based measurements (around 0.1 mm accuracy) on boards several meters long after they have been cut.

After the dimensional measurements and analysis are completed, the C++ application performs correction calculations, and the results are sent back to the PLC so that the cutting machine parameters can be adjusted if the measured dimensions are outside the specified tolerances.

Because of this separation of responsibilities, communication between the PLC and PC is limited to high-level data exchange, such as:

• Measurement results (length, width, OK/NOK)
• Calculated correction values for the cutting machine
• Simple trigger and handshake signals

 

 

Thank you for the detailed explanation and the helpful insights regarding network setup and data exchange. Your points about isolated networks and the considerations for secure and reliable communication are very useful.

Thank you again,

0_Einstein