Peripherals without explicit platform support entry are treated as not supported

[MarvinW]

I am a little confused right now and would like to know if the following behavior is intentional. I am using CPS 5.9.2 and have not tested this with other versions.

Peripherals must explicitly state that they support ("yes") or maybe ("NotTested") support a peripheral. If they don't support ("No") or don't state a platform type at all then they will not be compatible with the PLC platform.

What I mean that a peripheral with this .ood will not be compatible in ctrlX:

<SupportedPlcTypes>
    <PlcType name="BTC" supported="Yes" />
    <PlcType name="RIL" supported="NotTested" />
</SupportedPlcTypes>

On the other hand, it seems that objects (units, handlers, add-ons, bases ...) do not have this requirement. If a platform is not found in the ood it is allowed to be used in CPS anyway. Is inconsistency an oversight or intentional?

Strictly speaking, if it's not state then a platform should probably be treated as incompatible for both objects and peripherals. However, it is probably a lot more convenient to treat them as "NotTested" for both types. Maybe a warning when reloading STD or adding such an object/peripheral would be nice for a certain grace period whenever a new platform is added. In my books, CXA still counts as a new platform 🤣

[nexidator]

This behavior is intentional. The thought was that units are usually hardware independent and more likely to work on any PLC type. That's why they default to NotTested. Peripheral objects often need explicit IO linking information for each supported PLC type, that's why they default to No.

By the way: If the whole SupportedPlcTypes element is missing, BTC support is assumed as "Yes" for compatibility reasons.