It's also going to be important to know the set up of the racks of I/O in great detail with Remote I/O, some types of I/O require special attention to enable them to cause a rack fault in the processor, and how nad where the physical I/O will end up in the data tables.
This requires documentation outside of RSLogix5, which is often not kept current with what's in the machine. If you have good known documentiontation, ship this part:
You need a good physically record the rack layout, types of I/O, slot addressing modes (1/2, single or 2-slot).
I believe with RSLogix5, you can read the dipswitches in software for some parts of this, and other parts may require, powering down and looking at the cards. with a notepad, if they are in question.
From there, I recommend directly reading any slot/fault status in the Status file directly, which should work even if the PLC is faulted and halted.
For real I/O, I recommend mapping then to internal addresses with simple rungs for digitals with XIC, OTE (or XIO OTE if it makes sense to invert them). And with MOVs or COPs for analogs or other groups that occupy real I/O data table spaces.
Then you are free to layout the screen tags without having to worry about the physical I/O, make changes easily in simple ladder code, and make the core logic running off these mapped bits more portable.
Plus, certain processor and HMI/SCADA combinations disallow directly addressing I and O files.
