industrialNETworX

Hello,

I have several questions concerning the PROFINET stack.

I have ported C-toolkit on Linux and written almost all handling functions documented for PROFINET IO device firmware (version 2.1.2.0, API documentation revision 13). Currently I am running software PROFINET IO Tester (Version 1.5, revision 4282, testcase version 2.2.2.14.15-PUB ) to check, whether the device is susceptible for acceptance as complete IO device. I use GSDML GSDML-V2.0-HILSCHER-COMX RE PNS-20080702.xml (the newest I found on your web pages).
Quite large part of testcases pass, but there are some, that fail and I don't know whether it can be solved by means of program in host processor.

Here are listed testcases, that fail. Not all are listed since several fail because of dependency on the ones listed here.
- PDEV1: Official description is following
# Tests whether the GSD-File contains SystemDefinedSubSlots and
# read PDInterfaceDataReal and PDPortDataReal for each Interface
# and Port and displays for manual checking.
In GSDML there is no SystemDefinedSubmoduleList, which is marked as required in GSDML specification. My question is, is this functionality implemented? How should I set parameters od SystemDefinedSubmoduleList in GSDML file for it to work?

- RPC_EPM_TEST: Official description is following
# Test of End Point Mapper Instance for Remote Procedure Call Protocol
# EPM records are looked up and is searched for a record with Profinet device
# object description (PN record).
# The test of the EndPointMapper is part of the RPC testing. Within the standard
# RPC calls the EndPointMapper shall give an overview about the tested device.
# The data within the EndPointMapper shall be consistent and shall also be consistent
# with the data read back with I&M functions. The PNIO-UUID shall be present within
# the EndPointMapper (EPM) response, the RPC-EPM-UUID may be present.
The testcase returns "FAIL: Wrong number of floors in PN object record (0x0000) : must be 5 -> ERROR". I don't have a clue what to do with this.

- RM2, RM4, RM63: In these I think I know the reason why they fail. It concerns the packet 'reset to factory settings'. This packet is indicated to host, but no description is given in API documentation. My question is following, how should I set the netX to factory reset according to PROFINET?

- ALARMNUM_CHECK:
# Test of Alarm-State machine APMS (AcyclicProtocolMachineSender)
# Number of alarm retries have to be checked.
the fail message is following: "Device repeated Hi: 0 and Low: 65, RESULT ERROR: Wrong number of alarm retries"

- CONNECT_FULL: Official description is following
# Testing of RPC.
# The startup of the device is done with different adjustments within the RPC.
# Once a correct connect is sent with data representation of RPC with byte order "little endian".
# After the con-nection is established fully, the data exchange shall work in a proper way. Also
# a READ.req for I&M0 data of the PROFINET interface is sent with RPC byte order "little endian".
# The answer of the device shall contain the correct I&M0 data. Then the connection is aborted.
# Without switching off the device a second startup is done, but this time a correct connect is
# sent with data representation of RPC with byte order "big endian". After the connection is estab-
# lished fully, the data exchange shall work in a proper way. Also a READ.req for I&M0 data of the
# PROFINET interface is sent with RPC byte order "big endian". The answer of the device shall contain
# the correct I&M0 data. The device shall react in the same way without considering the byte order
# sent by the test system. The AR is shut down again by a RELEASE.req of the test system.
The fail message is following:
"5. State: Cmd: RPC_Read: Data: Valid I&M0 Exp.Resp: +
RESULT ERROR: Read I&M0 (little endian): Error -> not OK"

- CONNECT_FRAG: Official description is following
# Testing of RPC.
# A correct segmented CONNECT.req shall be processed correctly. The device and the controller shall
# be able to establish an AR. DataExchange is working properly. After releasing this AR, a second
# time a segmented CONNECT.req is sent to the device by the test system. But this time the first
# segment is sent with data representation "little endian" and the second seg-ment is sent with data
# representation "big endian". In that case the device may reject the segmented connect, answer
# with an error and may not establish an AR to the test system. The exact reaction of the device shall
# be noted in the test records.
The fail message is following:
"5. State: Cmd: RPC_Read: Data: Valid I&M0 Exp.Resp: +
RESULT ERROR: Read I&M0: Error -> not OK"
This result is exactly the same as CONNECT_FULL testcase.

- VLAN:
# Check of VLAN.
# This test case checks the correct behavior of the IP stack regarding VLAN TAG.
# The test system shall connect to the device and do data exchange one time using the described
# VLAN TAG and after that it shall do this a second time without using VLAN TAGs. In both tests
# the device shall do correct data exchange and work properly.
The fail message is following:
"RESULT ERROR: Read I&M0 without VLAN block : Error -> not OK"

- REPEAT_FRAMES:
# This test case uses the repeat of RPC_Read and RPC_Write to simulate a problem on the receiver
# or line. First normal startup is done, so that there is a running system in data exchange. Then
# a RPC_Read is repeated once. The device sends back the same data in the second READ.res as in
# the first READ.res. Afterwards a RPC_Write is repeated in the same way. The device shall accept
# that and run without problems.
The fail message is following:
"RESULT ERROR: Read I&M0 : Error -> not OK"
For four last mentioned the problem is in block I&M.

Will You please send some information, how to solve the testcases mentioned above?
I am not sure, whether the description is be good enough, please feel free to ask for more detail.

best regards
Karel Boček