...I am sorry to ask you again what do you mean i/o configuration mismatch for which CPU.
Do you mean newly replaced CPU?
...Now I am in confused...
Sorry, I meant for the faulty CPU.
In line with Aabeck's explanation...
The SLC controller that is in fault was in operation in a chassis with other 1746 I/O modules. These modules were added to the RSLogix 500 program's I/O Configuration by selecting the correct modules and adding them to their equivalent slot numbers. Once they have been correctly added to reflect the physical I/O configuration of the chassis, the program is verified and Downloaded to the controller.
When the controller is placed in Run Mode, the processor checks the I/O Mapping. This must match exactly with the physical chassis configuration. If the program's I/O Mapping is in any way physically missing or misaligned, an I/O Mismatch error xx52h occurs.
The point I was making was that if you test the processor in an empty chassis, where none of the original I/O modules are present, it would fault on I/O Mismatch. This could then mislead you into thinking this is your original fault.
There is an option to set the I/O Slot Enable bit off (0) for each of the used slot numbers. This is done under the I/O tab in the processor Status file. This would force the processor to ignore the disabled slots when checking the I/O Mapping.
While that is a useful feature, it's not much use to you here as you would need to Download the slot disable changes to the controller. You cannot Download to a faulted controller. You would have to reset the fault before doing so, but this would mean first clearing the very fault you want to identify.
But while I'm spitting all that information out, I've had another thought...
I cannot remember, but I'm pretty sure that if you power up an already faulted SLC processor, in a foreign chassis, it will still retain its last fault even if there is now a newer fault condition. I think this is the case because the CPU is not running when it is faulted. So it cannot perform an I/O Mapping check and throw a newer xx52h error?
So perhaps an I/O Mismatch would not be an issue after all?
Sorry for my meandering and the added confusion.
My brain sometimes runs away with itself, but judging by the postcards, it always seems to have had a good time.
Regards,
Confucius
