This can be a real struggle for companies at times, and I've never understood why. Well, in my former company it's because people just didn't seem to 'get it' when I constantly complained that our prints and program never matched up well, it was like talking to a wall. Primary issue was that nobody besides me understood system integration, and we were scaling up into a system integration type of company.
Anyhoo, there are two issues I always see. First is the program reference. We would always follow the P&ID diagram.
M-101
M-102
FV-201
FV-202
TT-301
TT-302
That worked for the "most" part. Of course, what to do about the Hyphen? In the PLC program, we had to eliminate it. FV-201 became FV201. In the Prints it would remain hyphenated, then what if there was a prox associated with a valve? FV-202-ZSC, again that doesn't work well in the PLC program.
Why not? Also, I think standard P&ID convention would label it ZSC-202 for valve closed switch and ZSO-202 for valve open.
So I constantly fought that. Then what about the wire labeling?
I've seen the wires that control a device be labeled with the device's loop number. So if you had a modulating valve called FV201, the conductors in the shielded cable that modulate it would be called FV201+ and FV201-.
FV201 works great as a AOI name for the device control. But what about the actual IO label? Can't use FV201 again, so do you call it inputFV201? outputFV201?
If you're using an AOI, couldn't you just make one of the parameters the physical I/O address assignment without having to alias it?
Didn't make much sense to use those so we defaulted back using a Chassis Rack Slot identifier on the actual IO and wire label. This way if you looked at a wire label on a field device you would know where it was physically wired too. Labeling the field device wire as FV201 at the field device doesn't make much sense when you already know it's FV201, I think most people troubleshooting would prefer something that told them where the wire went.
On the flip side, if you're looking at the panel, labeling the wire I:1/1 according to the I/O address doesn't make sense when you already know it's I:1/1. If it were labeled FV201, you'd know "this is the wire that turns on FV201."
Took me a year to get that concept across. Prior to that it was 'name it whatever-the-hell-the-electrical-designer-wanted' never mind the fact that their attempt at aligning with the PLC IO address was wrong because they insisted on designating AI, DI, DO, AO in the address when that isn't how a Logix PLC works.
Do you mean they would start over as soon as the IO type changed? So like if there were two DI and two DO cards, they'd label them as DI0, DI1, DO0, DO1? If so, that's terrible, I agree.
So you'd look at the address they put on the prints, and it was simply wrong because the syntax was wrong and therefore the reference didn't exist in the PLC!!! Oh, and then the software guys would name the items in the hardwrae tree whatever-the-hell-they-wanted so nothing aligned. Not to mention that the wire labels could be 20+ characters long, the electrical designers didn't seem to understand that an electrician in the field might not have a labeler that could handle that. I've seen labels 2+ inches long, at a field device it gets buried int the conduit, what good is that?
That's pretty insane. Loop numbers can get pretty long. I generally prefer to number everything according to schematic line number, even the I/O. That way, you always know exactly where to find the wire you're looking at.
Then what if the IO isn't directly wired to an output? It's on a network like Ethernet or ASI?
In the end I proposed the Chassis-Rack-Slot, or Chassis-Class-Instance convention that I feel works really well and addresses both wired and networked devices. Plus it kept character length to a reasonable 12 characters for a wire label, granted you had to understand how to decode but it works well. The IO mapping logic clearly connects the dots of the two, and in the end the prints had FV-201 on them, and the wire label indicating something like C04R01S08/9.
I would say this could add confusion because Chassis-Rack-Slot doesn't really mean anything with Ethernet I/O, but it is at least a convention of some kind that can be applied consistently.
Don't even get me started on matching descriptions.....I always felt bad for the end user getting our prints. The systems we did were so large and the process engineers never provided good descriptions for the initial electrical design so again it was 'make-it-up' to get the prints done while the software guys where writing the functional design spec and creating the descriptions there. Electrical guys *****ed about having to re-work it after. I'm sorry but that's how it goes!!
It amazes me how often prints get neglected, despite how important they are. They are your first and most important line of defense in troubleshooting a machine.
