I'm curious if the general consensus would be that it's better to have the actual mapped memory bits named indicating the hardware I/O address (Input_0_1 for I:0/1 or something along those lines) or named for the device (FCV_Limit_Sw_Closed for example).
If you create an alias called FCV_Limit_Sw_Closed for, say, Local:3.I
ata.1 and that point dies and you want to now wire it Local:4.I.Data.13, your alias (which cannot be altered online) will still point to the old card, which defeats the purpose of creating the alias.
OTOH, having an alias Input_03_01 (please zero pad things, or _10 will be between _1 and _2, which is annoying) as an alias to Local:3.I.Data.1 doesn't add any value. The alias tag and the real-world tag are redundant.
So don't bother with aliases in your mapping. DO add descriptions (tag names and descriptive name) to the I/O addresses, so you can tell what's on that card when looking at it in the data table.
In an asynchronous scan, if I have a sensor with an integer value, and I use a COP instead of a CPS, then it's possible that during the input bits being read, the value could change and result in some bogus value, correct?
Theoretically, yes. That's why CPS was invented. Especially annoying when there is a small change in the bit pattern: 1000000 going to 0111111 or vice versa. The value only changed by 1. But if the I/O update hit at the exact microsecond that it was reading bit 6, the resulting value could be 0000000 or 11111111, essentially halving or doubling the real value, instead of showing it as virtually unchanged.
This is capable of triggering all sorts of alarms and thus shutdowns when there was never a real issue.
Of course, this only applies to analog I/O, where the bits are interpreted as a unit. If you were merely copying all the .Data bits in a discrete card to some buffering DInt, whether one bit was or was not set on the same scan as another hardly matters.
If it really does, then get an SOE module which will REALLY tell you which input was on first.