Testing Profinet I/O devices without a dedicated PLC

Using CODESYS Control Win as a practical Profinet test environment.

If you work with Profinet devices, there are plenty of occasions when you want to test something quickly but don’t necessarily have a PLC sitting on the bench.

Perhaps you’re developing a device and want to check the GSDML. Perhaps you’re an integrator who has just received a new piece of equipment and wants to make sure the Profinet interface behaves as expected before taking it to site. Or perhaps you’re troubleshooting a device and don’t want to tie up a PLC from another project just to find out whether the problem is actually in the device.

This is where I find a software-based Profinet I/O controller particularly useful.

For example, a Windows PC running CODESYS Control Win can be used as a SoftPLC and, with the appropriate Profinet functionality, provide a practical test environment for a Profinet I/O device.

It isn’t a replacement for a PLC in a production application, and it certainly isn’t a replacement for formal Profinet conformance testing. But for the right job, it is a remarkably useful tool to have on the engineering bench.

What are we actually trying to test?

It’s worth starting with the basics. When I receive a Profinet device for testing, I don’t necessarily want to build an entire automation project around it. Initially, I want to answer some fairly straightforward questions such as:

• Can I import the GSDML?
• Does the device configure correctly?
• Can I establish the Profinet connection?
• Do the expected modules and submodules appear?
• Can I exchange cyclic I/O data?
• Do the diagnostics behave as expected?
• What happens when I restart the device?
   

These are simple questions, but answering them early can save a surprising amount of time later.

A basic Profinet test therefore needs a genuine I/O controller. The controller needs to understand the device description, establish the connection and exchange the configured process data, so normally, we’d reach for a PLC. But we don’t always need to.

Turning a PC into the test controller

This is where CODESYS becomes interesting. CODESYS is an IEC 61131-3 development environment, and CODESYS Control Win provides a SoftPLC runtime for Windows. The runtime supports Profinet controller functionality, allowing a Windows PC to be used as the control platform for a suitable Profinet test.

For me, the attraction isn’t that this somehow replaces a PLC, because it doesn’t. The attraction is that I can get a useful test environment running on equipment I already have on the engineering desk.

Because the application is developed using IEC 61131-3 languages, the test program can be as simple as it needs to be. There is no reason to write a complicated control application just to toggle a few outputs and monitor some inputs.

Getting started

The actual setup is reasonably straightforward.

1. Create the CODESYS project

Create a new project and select CODESYS Control Win as the target. At this point, we’re essentially creating a small SoftPLC application on the PC.

The beauty of CODESYS is that the test application doesn’t need to be elaborate. A few lines of Structured Text can be enough to exercise the device.

2. Import the GSDML

Next, import the GSDML file for the device being tested. This is one of the first useful checks. If the GSDML doesn’t import correctly, or the modules and submodules don’t appear as expected, you’ve already found something worth investigating before you get any further.

The GSDML is effectively the device’s description to the engineering system. If the configuration doesn’t make sense at this point, there is little value in moving on to more complicated testing.

3. Configure the device

Add the device to the Profinet configuration and select the required modules and submodules.

The device name and network configuration then need to be assigned appropriately. This is also a good point to check the physical network.

A surprising number of ‘Profinet problems’ turn out to be something much simpler — the wrong network adapter, a firewall, a VPN connection or the PC using an interface that wasn’t intended for the test.

When I’m testing on a laptop, I like to keep the test network as simple as possible.

4. Write a small test program

You don’t need a machine application: you just need enough code to exercise the device.

For example, a simple Structured Text program can toggle an output at a known interval while monitoring the input data coming back from the device. You can then expand the test as required.

If the device has several I/O modules, test them individually. If it provides diagnostic information, deliberately create an appropriate condition and see what the controller reports. The important thing is to make the test repeatable.

5. Run the test

Once the application is downloaded and the CODESYS runtime is running, the PC can act as the Profinet I/O controller.

At this point you’re looking for the basics:

• Does the device establish communication?
• Does cyclic data exchange start?
• Are the configured inputs and outputs behaving correctly?
• Are diagnostics reported?
• Does the device recover correctly after a restart?
• Does changing the configuration produce the expected result?
   

For a straightforward device, this gives you a useful amount of information without first building a complete PLC test system.

Where this approach is particularly useful

I see three obvious applications for this scenario.

Device development

If you’re developing a Profinet device, you can use the setup during development to check basic communication and configuration before moving to more formal testing.

It can be particularly useful for finding problems in the GSDML or in the way the device handles its modules and cyclic data.

Integration work

For an integrator, the ability to test a device before it reaches site has obvious advantages.

If a device doesn’t behave as expected on the bench, it’s much easier to investigate it there than when you’re standing in front of a machine waiting for production to start.

Troubleshooting

It can also be useful when troubleshooting.

If a device isn’t communicating with a user’s PLC, putting it onto a separate test setup can help answer an important question:

Is the problem with the device, or is it somewhere in the user’s control system or configuration? It doesn’t necessarily give you the answer immediately, but it gives you another controlled environment in which to investigate.

What this test does not prove

This is the important bit: a PC running CODESYS is a useful test tool, but it is not a magic Profinet validation system.

It is not a deterministic real-time test platform

CODESYS Control Win runs under Windows and is described by CODESYS as having soft real-time properties.

That distinction matters, because Windows is doing Windows things in the background, and other applications, drivers and network activity can affect timing.

So if you’re trying to prove tight cycle-time performance, jitter or deterministic behaviour, this is not the platform I’d use as the final reference. Use appropriate real-time hardware for that job.

It is not an IRT test

Profinet RT and Profinet IRT are not the same thing. A Windows-based Control Win test should not be used to validate IRT performance or applications where the deterministic characteristics of IRT are fundamental to the application.

Again, use the appropriate hardware and test environment for the requirement you’re trying to prove.

It is not formal Profinet conformance testing

This distinction is important: if a device communicates successfully with CODESYS, that tells you something useful about its functional behaviour with that controller. It does not mean the device has passed Profinet conformance testing.

Formal conformance testing has its own requirements and should be carried out through the appropriate testing and certification process. Think of this approach as engineering validation, not certification.

One controller is not every controller

This is another reason I wouldn’t stop testing here.

Profinet is standardised, but controllers and engineering environments can still differ in how particular situations are handled. Startup behaviour, diagnostics, configuration and some edge cases can expose differences. So if a device is intended to work with a particular PLC platform, I’d still test it with that platform.

The CODESYS test gives you another piece of evidence. It doesn’t give you universal interoperability.

Don’t forget the test environment

One of the more interesting things about using a PC for Profinet testing is that the PC itself becomes part of the problem:

• Multiple network adapters can cause confusion.
• VPN software can interfere with the network path.
• Firewalls can prevent the communication you are expecting.
• Device discovery can become frustrating when the wrong Ethernet interface is being used.
   

So if something isn’t working, don’t immediately blame the device, but start with the basics:

• Which network adapter is CODESYS using?
• What IP configuration does the PC have?
• Is another adapter active?
• Is a firewall blocking the required traffic?
• Is the physical connection correct?
   

I’ve spent enough time troubleshooting industrial networks to know that the simplest explanation is often worth checking first.

How far should you take it?

How far you take it depends entirely on what you’re trying to prove.

For a basic functional check, a PC-based SoftPLC can be extremely useful, but for more demanding testing, you need to move up the scale. That might mean testing with the actual PLC platform used by the user, testing network redundancy, checking specific Profinet features, performing long-duration testing, or moving to a real-time platform where timing behaviour matters. And for a product that needs formal certification, there is no shortcut around the appropriate conformance process.

The mistake is not using a PC-based test: the mistake is assuming that one test proves everything.

A useful tool for the engineering toolbox

I like CODESYS for this sort of work because it removes a lot of unnecessary barriers between the question and the test.

I don’t have to turn a simple device check into a PLC project — I can create a small IEC 61131-3 application, configure the Profinet network, connect the device and start looking at what is actually happening.

That’s useful engineering; it means I can find problems earlier, test devices away from the production environment and get a better understanding of how a device behaves before it becomes part of a larger system. And that’s really where I see the value of this approach.

It’s not about replacing the PLC. It’s about having another tool available when the PLC isn’t what you need. For early-stage Profinet device testing, troubleshooting and bench validation, a software-based I/O Controller can be a very practical addition to the engineer’s toolbox.

Image credit: iStock.com/Quique Olivar Gomez