In my application, we use X20 and X90 configurations mixed but fixed on certain CPU module (X90CP174 48 00 and X20CP0483). To make the program flexible and unified, I’m thinking about using the PLC module ID to recognize the PLC type.
In essence, in both X20 and X90 configuration view, the same tag for recognizing the PLC type is mapped in the PLC’s IO mapping to the channel called ModuleID. Then in my program, I’ll check the tag value then I know the PLC type.
In my test the module ID seems to be unique between my PLC module variants and consistent for the same module. My questions are:
Is there going to be different module IDs for the same PLC hardware but different firmware? For example, are X90CP174 48 00 PLCs using B4.92 firmware going to have a different module number from the ones using F4.92 firmware?
Is it possible to get different module ID between old and new PLC hardware with the same type? For example, are the same X90CP174 48 00 PLCs purchased now and two years ago going to have the same module ID?
Is the information about the correlation between the module ID number and the PLC type available? The Automation Help’s section covering the module ID and the PLC’s manual covering the module ID references each other and doesn’t provide detailed information…
Ignore, the following, this has been proven incorrect, see posts below
Ignore
In addition, but this seems to be an edge case, we have given new module IDs to the same modules when we ran out of serial numbers using the same module ID - so using them is no 100% guarantee.
I have been misinformed and clarified this with colleagues meanwhile. The “Alte Matnr” was untouched, we rather chose to use letters in the first place of the actual serial number.
→ ModuleID has not changed, so please ignore the first part of my reply above.
I stand by the part of not hardcoding the IDs, though
It’s hardcoding as in “comparing the ModuleID with a known value and acting accordingly”, which, imo, has the disadvantage that you can’t have another config using the same PLC doing yet another thing differently - which, as far as I’m concernced, is usually a “won’t happen ever” being replaced with “I should have thought of that, someone decided it will happen while I was still integrating solution 1”. Same goes with another config that should do the same but uses e.g. a newer PLC because it’s the generation of 2 years later. One doesn’t want to change the code to add the comparison for the moduleID.
TL;DR: I still recommend not relying on the ModuleID since you can not distinguish configs and / or will have the case where the same code path should be used for different plcs etc…
I decided to use the module ID because I can’t find a way to detect which configuration is active.
My application is simple, a RS-232 interface needs to read some data from a device. With X20 and X90 PLC, the RS-232 device address is different. Instead of having two POUs in the logical view and use them respectively in the X20 and X90 configurations, one POU that automatically detects which PLC it is running in can reduce the program maintenance in the long term.
If there is a way to detect the configuration instead of the PLC module, it is obviously better. Can you provide more information about it, please?
Potentially yes. For some reason I overlooked the Configuration ID.
We are using configuration version to track our software versions so we don’t include source code in the PLCs delivered to sites. But we can have different configuration IDs to identify the different PLC modules or same module but different physical configurations.
changing the ModuleID is basically a “no go”