ProductCode for ctrlX Drive changes with firmware update - alternatives for detecting ctrlX Drives via EtherCAT

Hello,

in our SDK based ctrlX App, we whitelist the following XML node properties in our automated commissioning process, to detect the connected ctrlX Drives via EtherCAT Master App:

product code, path in XML: Config → Slave → Info → ProductCode

revision number, path in XML: Config → Slave → Info → RevisionNo

Since we check for these criteria to determine a certain ctrlX Drive model is connected via EtherCAT as a slave, we recognized that the product code changes with every firmware update of the drives. Therefore, this check is not suitable to support the loose link between ctrlX Core OS version and drive firmware version. Are there other criteria to identify a specific ctrlX Drive configuration (model family like XCS, safety type like STO/SMO, ...)?

Thanks for your help in advance.

After a direct call some resume:

"productCode" is directly related to the device type. There is a internal list available which number corelates to which device. We check if and where this can be published.
"productCode" only changes if there is a major incompatible change in the device description e.g. in the cyclic data.
"productCode" is not hard coupled to the runtime version of the drives, but as a new drive runtime version releases at the same time then a device description, it seems to be linked. But not each runtime version gets a new number.
The has been a major change for devices using AXS6.12 handed out from ctrlX IO Engineering 4.6.1, so "productCode" changed.
"revisionNumber" can change if there is a minor but compatible change. This happens most likely if a device is quite new.