I/O Module-Defined tags always follow the pattern...
Location : Slot : Type
Location : the name of the "parent" of the module, always "Local" if in the same chassis as the controller (you can't change it, it's fixed). If it is remote I/O, instead of "Local" it will be the name given, in the project's I/O configuration, to the comms adapter in the remote chassis.
Slot : obvious really, the slot number of the I/O module as assigned in the I/O configuration, not where the module actually is ! If those two things don't agree, it just doesn't communicate.
Type : can be I (Input), O (Output), or C (Configuration)
So for an Input module in slot 6 of the same chassis as the controller, the module-defined tag where the input data is will be
Local:6:I
There will also be a tag called Local:6:C which is the Configuration tag - it tells the module how to behave.
For digital modules, there is a member of the tag called .Data, which itself has BOOL elements numbered .0 to .31 (even if it's only a 16-bit module, there is space for 32 bits).
Input bit 11 on that module is then addressed as Local:6:I.Data.11
However, if you try to Search through the logic to find where that input is used, you might not find it.
That is because an Alias tag may be used in the program. Search is not letting you down, its just that the physical input doesn't exist in the logic at all.
The absolute best tool is the cross-reference, because that jumps the gap and will show you where the physical input is alias-referenced in the logic.