Help Needed with Pre-Testing Two-Port PROFINET Device Configuration

[yasiralismb1]

Hi everyone,

I am currently pre-testing a two-port PROFINET device before applying for the actual certification in the lab. I am using an ETS board for testing and following the steps outlined in the product documentation.

Here is what I have done so far:

Set the IP for the NIC connected to the ETS as 192.168.5.2, and communication with the ETS board is working.
Set the IP of the PROFINET device to 192.168.0.50 as per the documentation.
However, the BF LED on the PROFINET card keeps blinking, indicating that there is likely a configuration issue.

Could someone guide me on the correct way to configure the IPs or point out any steps I might be missing? Any advice on correctly setting up each part of the system would be greatly appreciated

[benja_m]

Hi everyone,

I am currently pre-testing a two-port PROFINET device before applying for the actual certification in the lab. I am using an ETS board for testing and following the steps outlined in the product documentation.

Here is what I have done so far:

Set the IP for the NIC connected to the ETS as 192.168.5.2, and communication with the ETS board is working.
Set the IP of the PROFINET device to 192.168.0.50 as per the documentation.
However, the BF LED on the PROFINET card keeps blinking, indicating that there is likely a configuration issue.

Could someone guide me on the correct way to configure the IPs or point out any steps I might be missing? Any advice on correctly setting up each part of the system would be greatly appreciated

Assuming the blinking LED "simply" indicates that no cyclic communication is in place, this seems plausible.
ETS only established a connection when a test is performed. And not all tests require a connection, esp. most of the DCP testcases for example do not establish a connection.

Does the LED behavior change when you execute different testcases?

[yasiralismb1]

Hi everyone,

I am currently pre-testing a two-port PROFINET device before applying for the actual certification in the lab. I am using an ETS board for testing and following the steps outlined in the product documentation.

Here is what I have done so far:

Set the IP for the NIC connected to the ETS as 192.168.5.2, and communication with the ETS board is working.
Set the IP of the PROFINET device to 192.168.0.50 as per the documentation.
However, the BF LED on the PROFINET card keeps blinking, indicating that there is likely a configuration issue.

Could someone guide me on the correct way to configure the IPs or point out any steps I might be missing? Any advice on correctly setting up each part of the system would be greatly appreciated

Assuming the blinking LED "simply" indicates that no cyclic communication is in place, this seems plausible.
ETS only established a connection when a test is performed. And not all tests require a connection, esp. most of the DCP testcases for example do not establish a connection.

Does the LED behavior change when you execute different testcases?

Yes you are right when ETS board communicate with it BF led stop blinking. I configured my device according to ProductDocumentation.pdf guidlines, I can access ETS board in ART-Tester but I have some DCP test failed. DCP_1 logs is following.

18:57:28 - Starting Testcase: DCP - DCP 1
18:57:28 - Initializing Power Outlet
18:57:30 - DCP_1: Start of test DCP - DCP 1 without VLAN-Tag
18:57:30 - DCP_1: Test step 1: Requesting ResetToFactory (reset communication parameters) of the dut
18:57:30 - DCP_1: Test step 2: Waiting for the DUT to apply the reset to factory request. [ms]: 60000
18:58:30 - DCP_1: Test step 3: Check the IdentifyAll response behavior.
18:58:30 - DCP_1: Test step 4: Powering off - on the dut
18:58:36 - DCP_1: Test step 5: Waiting for the DUT to power up again.
19:00:08 - DCP_1: Test step 6: Set the name of station to 'dut' permanently.
19:00:13 - DCP_1: Test step 7: Send an Identify.Req with the name of the DUT as filter.
19:00:13 - DCP_1: Test step 8: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:00:18 - DCP_1: Test step 9: Send a DcpGet.Req with the following parameter: NameOfStation, DeviceId, MacAddress and IpParamter.
19:00:18 - DCP_1: Test step 10: Set the name of station to 'dut' permanently.
19:00:23 - DCP_1: Test step 11: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:00:28 - DCP_1: Test step 12: Requesting ARP for IP - Address: 192.168.0.50
19:00:28 - DCP_1: Test step 13: Check the IdentifyAll response behavior.
19:00:28 - DCP_1: Test step 14: Temporarily set the ip address of the DUT to 192.168.0.51
19:00:33 - DCP_1: Test step 15: Requesting ARP for IP - Address: 192.168.0.51
19:00:33 - DCP_1: Test step 16: Check the IdentifyAll response behavior.
19:00:33 - DCP_1: Test step 17: Powering off - on the dut
19:00:39 - DCP_1: Test step 18: Waiting for the DUT to power up again.
19:02:11 - DCP_1: Test step 19: Requesting ARP for IP - Address: 192.168.0.50
19:02:11 - ERROR: Dcp: No response received.
19:02:11 - ERROR: DCP_1: Test step 20: There was an ARP received. This was not expected.
19:02:11 - DCP_1: Test step 20: DCP - DCP 1: Aborted due to errors.
19:02:11 - DCP_1: Start of test DCP - DCP 1 with VLAN-Tag
19:02:11 - DCP_1: Test step 1: Requesting ResetToFactory (reset communication parameters) of the dut
19:02:11 - DCP_1: Test step 2: Waiting for the DUT to apply the reset to factory request. [ms]: 60000
19:03:11 - DCP_1: Test step 3: Check the IdentifyAll response behavior.
19:03:11 - DCP_1: Test step 4: Powering off - on the dut
19:03:17 - DCP_1: Test step 5: Waiting for the DUT to power up again.
19:04:49 - DCP_1: Test step 6: Set the name of station to 'dut' permanently.
19:04:54 - DCP_1: Test step 7: Send an Identify.Req with the name of the DUT as filter.
19:04:54 - DCP_1: Test step 8: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:04:59 - DCP_1: Test step 9: Send a DcpGet.Req with the following parameter: NameOfStation, DeviceId, MacAddress and IpParamter.
19:04:59 - DCP_1: Test step 10: Set the name of station to 'dut' permanently.
19:05:04 - DCP_1: Test step 11: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:05:09 - DCP_1: Test step 12: Requesting ARP for IP - Address: 192.168.0.50
19:05:09 - DCP_1: Test step 13: Check the IdentifyAll response behavior.
19:05:09 - DCP_1: Test step 14: Temporarily set the ip address of the DUT to 192.168.0.51
19:05:14 - DCP_1: Test step 15: Requesting ARP for IP - Address: 192.168.0.51
19:05:14 - DCP_1: Test step 16: Check the IdentifyAll response behavior.
19:05:14 - DCP_1: Test step 17: Powering off - on the dut
19:05:20 - DCP_1: Test step 18: Waiting for the DUT to power up again.
19:06:52 - DCP_1: Test step 19: Requesting ARP for IP - Address: 192.168.0.50
19:06:52 - ERROR: Dcp: No response received.
19:06:52 - ERROR: DCP_1: Test step 20: There was an ARP received. This was not expected.
19:06:52 - DCP_1: Test step 20: DCP - DCP 1: Aborted due to errors.
19:06:58 - Finished test case DCP - DCP 1.
19:07:02 - Starting Testcase: DCP - DCP_2
19:07:02 - Initializing Power Outlet
19:07:04 - DCP_2: Start of test DCP - DCP_2 without VLAN-Tag
19:07:04 - DCP_2: Test step 1: Requesting ResetToFactory (reset communication parameters) of the dut
19:07:04 - DCP_2: Test step 2: Waiting for the DUT to apply the reset to factory request. [ms]: 60000
19:08:04 - DCP_2: Test step 3: Check the IdentifyAll response behavior.
19:08:04 - DCP_2: Test step 4: Powering off - on the dut
19:08:10 - DCP_2: Test step 5: Waiting for the DUT to power up again.



I do not know why its not getting response of ARP command. normally when i create project in ART-Tester it can automatically get Mac address of DUT.

[j.rost]

Hi everyone,

I am currently pre-testing a two-port PROFINET device before applying for the actual certification in the lab. I am using an ETS board for testing and following the steps outlined in the product documentation.

Here is what I have done so far:

Set the IP for the NIC connected to the ETS as 192.168.5.2, and communication with the ETS board is working.
Set the IP of the PROFINET device to 192.168.0.50 as per the documentation.
However, the BF LED on the PROFINET card keeps blinking, indicating that there is likely a configuration issue.

Could someone guide me on the correct way to configure the IPs or point out any steps I might be missing? Any advice on correctly setting up each part of the system would be greatly appreciated

Assuming the blinking LED "simply" indicates that no cyclic communication is in place, this seems plausible.
ETS only established a connection when a test is performed. And not all tests require a connection, esp. most of the DCP testcases for example do not establish a connection.

Does the LED behavior change when you execute different testcases?

Yes you are right when ETS board communicate with it BF led stop blinking. I configured my device according to ProductDocumentation.pdf guidlines, I can access ETS board in ART-Tester but I have some DCP test failed. DCP_1 logs is following.

18:57:28 - Starting Testcase: DCP - DCP 1
18:57:28 - Initializing Power Outlet
18:57:30 - DCP_1: Start of test DCP - DCP 1 without VLAN-Tag
18:57:30 - DCP_1: Test step 1: Requesting ResetToFactory (reset communication parameters) of the dut
18:57:30 - DCP_1: Test step 2: Waiting for the DUT to apply the reset to factory request. [ms]: 60000
18:58:30 - DCP_1: Test step 3: Check the IdentifyAll response behavior.
18:58:30 - DCP_1: Test step 4: Powering off - on the dut
18:58:36 - DCP_1: Test step 5: Waiting for the DUT to power up again.
19:00:08 - DCP_1: Test step 6: Set the name of station to 'dut' permanently.
19:00:13 - DCP_1: Test step 7: Send an Identify.Req with the name of the DUT as filter.
19:00:13 - DCP_1: Test step 8: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:00:18 - DCP_1: Test step 9: Send a DcpGet.Req with the following parameter: NameOfStation, DeviceId, MacAddress and IpParamter.
19:00:18 - DCP_1: Test step 10: Set the name of station to 'dut' permanently.
19:00:23 - DCP_1: Test step 11: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:00:28 - DCP_1: Test step 12: Requesting ARP for IP - Address: 192.168.0.50
19:00:28 - DCP_1: Test step 13: Check the IdentifyAll response behavior.
19:00:28 - DCP_1: Test step 14: Temporarily set the ip address of the DUT to 192.168.0.51
19:00:33 - DCP_1: Test step 15: Requesting ARP for IP - Address: 192.168.0.51
19:00:33 - DCP_1: Test step 16: Check the IdentifyAll response behavior.
19:00:33 - DCP_1: Test step 17: Powering off - on the dut
19:00:39 - DCP_1: Test step 18: Waiting for the DUT to power up again.
19:02:11 - DCP_1: Test step 19: Requesting ARP for IP - Address: 192.168.0.50
19:02:11 - ERROR: Dcp: No response received.
19:02:11 - ERROR: DCP_1: Test step 20: There was an ARP received. This was not expected.
19:02:11 - DCP_1: Test step 20: DCP - DCP 1: Aborted due to errors.
19:02:11 - DCP_1: Start of test DCP - DCP 1 with VLAN-Tag
19:02:11 - DCP_1: Test step 1: Requesting ResetToFactory (reset communication parameters) of the dut
19:02:11 - DCP_1: Test step 2: Waiting for the DUT to apply the reset to factory request. [ms]: 60000
19:03:11 - DCP_1: Test step 3: Check the IdentifyAll response behavior.
19:03:11 - DCP_1: Test step 4: Powering off - on the dut
19:03:17 - DCP_1: Test step 5: Waiting for the DUT to power up again.
19:04:49 - DCP_1: Test step 6: Set the name of station to 'dut' permanently.
19:04:54 - DCP_1: Test step 7: Send an Identify.Req with the name of the DUT as filter.
19:04:54 - DCP_1: Test step 8: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:04:59 - DCP_1: Test step 9: Send a DcpGet.Req with the following parameter: NameOfStation, DeviceId, MacAddress and IpParamter.
19:04:59 - DCP_1: Test step 10: Set the name of station to 'dut' permanently.
19:05:04 - DCP_1: Test step 11: Setting the IP-Parametes (IP, Subnetmask, Gateway) of the dut permanently.
19:05:09 - DCP_1: Test step 12: Requesting ARP for IP - Address: 192.168.0.50
19:05:09 - DCP_1: Test step 13: Check the IdentifyAll response behavior.
19:05:09 - DCP_1: Test step 14: Temporarily set the ip address of the DUT to 192.168.0.51
19:05:14 - DCP_1: Test step 15: Requesting ARP for IP - Address: 192.168.0.51
19:05:14 - DCP_1: Test step 16: Check the IdentifyAll response behavior.
19:05:14 - DCP_1: Test step 17: Powering off - on the dut
19:05:20 - DCP_1: Test step 18: Waiting for the DUT to power up again.
19:06:52 - DCP_1: Test step 19: Requesting ARP for IP - Address: 192.168.0.50
19:06:52 - ERROR: Dcp: No response received.
19:06:52 - ERROR: DCP_1: Test step 20: There was an ARP received. This was not expected.
19:06:52 - DCP_1: Test step 20: DCP - DCP 1: Aborted due to errors.
19:06:58 - Finished test case DCP - DCP 1.
19:07:02 - Starting Testcase: DCP - DCP_2
19:07:02 - Initializing Power Outlet
19:07:04 - DCP_2: Start of test DCP - DCP_2 without VLAN-Tag
19:07:04 - DCP_2: Test step 1: Requesting ResetToFactory (reset communication parameters) of the dut
19:07:04 - DCP_2: Test step 2: Waiting for the DUT to apply the reset to factory request. [ms]: 60000
19:08:04 - DCP_2: Test step 3: Check the IdentifyAll response behavior.
19:08:04 - DCP_2: Test step 4: Powering off - on the dut
19:08:10 - DCP_2: Test step 5: Waiting for the DUT to power up again.



I do not know why its not getting response of ARP command. normally when i create project in ART-Tester it can automatically get Mac address of DUT.

It seems that your device is not dealing well with restoring remanence data after a PowerOn. The expectation is, that from the temporary set IP address no ARP.Req is answered after a Power On.

[yasiralismb1]

Hi Profinet Experts,
I am currently testing a PROFINET device using the Embedded Test System (ETS) and Automated Real-Time Tester (ART), and I ran into an issue that I am hoping to get some insights on.

The device setup includes standard PROFINET configurations, and I am specifically running the IP_UDP_RPC_I&M_EPM - SCENARIO 1 (CLRPC) test case. During the test I encountered the following error while establishing an IOC-AR (Input-Output Connection - Application Relationship) connection with little-endian encoding:

15:03:20 - Starting Testcase: IP_UDP_RPC_I&M_EPM - SCENARIO 1 (CLRPC)
15:03:20 - Initializing Power Outlet
15:03:21 - First Scenario Part 1: First Scenario: Checking of RPC, IP and UDP Part 1
15:03:22 - First Scenario Part 1: Test step 1: Prepare the DUT for the test run.
15:03:32 - First Scenario Part 1: Test step 2: Sending and validating ICMP ping.
15:03:35 - First Scenario Part 1: Test step 3: Read and validate the I&M0FilterData from the dut.
15:03:35 - First Scenario Part 1: Test step 4: Establish an IOC-AR with 'little endianess'.
15:03:35 - ERROR: DCE/RPC Layer: Fragment number does not match Serial. Requirement: 0x00000000. Data: 0x00000001
15:03:35 - ERROR: First Scenario Part 1: Test step 5: Failed to establish an IOC-AR with little endianess.
15:03:47 - First Scenario Part 2: First Scenario: Checking of RPC, IP and UDP Part 2
15:03:48 - First Scenario Part 2: Test step 1: Prepare the DUT for the test run.
15:03:48 - First Scenario Part 2: Test step 2: Read and validate the I&M0FilterData from the dut.
15:03:48 - First Scenario Part 2: Test step 3: Establish an IOC-AR with 'little endianess'.
15:03:49 - First Scenario Part 2: Test step 4: Validate the ModuleDiffBlock and IOPS.
15:03:49 - First Scenario Part 2: Test step 5: Start sending of manipulated packages.
15:03:49 - First Scenario Part 2: Test step 6: Sending a read request with a wrong IP checksum
15:03:50 - First Scenario Part 2: Test step 7: Sending a read request with a wrong UDP checksum
15:03:52 - First Scenario Part 2: Test step 8: Sending a read request with a wrong IP and UDP checksum
15:03:54 - First Scenario Part 2: Test step 9: Sending a read request with a too big IP length value.
15:03:55 - First Scenario Part 2: Test step 10: Sending a manipulated read request. (IP Length is as big as UDP Length).
15:03:57 - First Scenario Part 2: Test step 11: Sending a manipulated read request. (IP Length too small).
15:03:58 - First Scenario Part 2: Test step 12: Sending a manipulated read request. (UDP Length too small).
15:04:00 - First Scenario Part 2: Test step 13: Release IOC-AR established with a fragmented connect request.
15:04:19 - Finished test case IP_UDP_RPC_I&M_EPM - SCENARIO 1 (CLRPC).
15:04:21 - Test execution finished.

After this error, the test continues with manipulated packet tests, but I am concerned this fragment mismatch might impact the entire test outcome.

Device Details:
Device Type: PROFINET I/O device (PCI card)
Testing Environment: ETS with ART for real-time testing

Questions:

• Has anyone else encountered similar fragment mismatch errors in ETS/ART tests? If so, any advice on specific configuration settings to check or debugging steps to try?

• Could this issue be related to the DUT’s handling of little-endian formatting or RPC sequences, and are there particular configurations I should try adjusting?

Any suggestions or experiences would be greatly appreciated. Thanks in advance for the assistance