The integrated PHYs of netX90, like all Ethernet PHYs, have a specific delay required to handle data on their receiption- and receive-path. This delay is fix within certain boundaries.

The maximum value for the receive path is 252ns (GSDML parameter “MaxPortRxDelay“). The real receive delay of netX90 depends on several external aspects and is in the range [220ns; 252ns].

The maximum value for the send path is 116ns (GSDML parameter “MaxPortTxDelay“).

Profinet devices based on netX90 should use these values in their GSDML file.

Issue in older Hilscher reference GSDML files

Together with the Profinet device firmware, Hilscher provides GSDML files. These files serve as a template for device manufacturers and such technical parameters are typically used 1:1 by the device manufacturer.

Unfortunately, up to Hilscher firmware version V5.5, the GSDML files provided stated a wrong value for “MaxPortRxDelay. The value 220ns was used, which is 32ns smaller than the maximum possible value of the implementation. See

The value “MaxPortTxDelay” was always stated correctly in Hilscher GSDML files.

Consequences of wrong value in GSDML file

Asuming the GSDML file of a netX90 based device uses the wrong values as stated above, the real receive delay may be up to 32ns larger than stated in GSDML file. Depending on the usage of the device, different consequences can occur and need to be considered.

RT-only Profinet Devices

For devices which are purely used in RT environment, thus IRT is never used, there can not be any issue as there is no planning done for timing of cyclic frames. The wrong parameter has no impact.

IRT Profinet Devices

For devices which are used in IRT environment, the timing of cyclic frames is scheduled in engineering system. The GSDML parameters “MaxPortRxDelay” and “MaxPortTxDelay” are part of the calculation. As such, the calculation is based on wrong values.

However, due to two other aspects, this wrong calculation will most likely never be an issue. These two issues are

1. 100ns SafetyMargin added to delay calculation for relative forwarder

2. configured cable delay used for calculation is larger than real cable

SafetyMargin

The IRT Engineering Guideline states, that for devices implementing IRT with technique “relative forwarder”, a SafetyMargin of 100ns shall be used for calculation. netX90 based devices implement “relative forwarder” and thus the calculation will be “corrected”. However, in worst case, the required SafetyMargin is not 100ns but only 68ns.

Cable Delay

The cable delay is part of the IRT planning, too. The cable delay used for calculation is configured into every Profinet device as part of it’s IRT configuration as well. In case the real cable is larger than the one used in IRT planning, the Profinet device will raise an error. As consequence, IRT planning will always use a cable delay larger than the real cable used in the actual installation.

The 32ns error introduced by wrong GSDML parameters roughly equals runtime in 5m cable. Thus, the potential difference of cable length between value used in IRT planning and real cable is reduced by 5m.

Conclusion

Device manufacturers creating a new netX90 based device shall use the correct values mentioned above.

Device manufacturers already having GSDML file and field devices delivered to the field should consider correcting the value in their next major device rework. There is no actual need to correct the values, as stated above. However, using incorrect values should be an active decision in that case and a strategy how to fix the wrong value in the future should be created.