Contact and Coil | Nearly In Control

Mapping Your Outputs

This is part of an RSLogix 5000 Tutorial.

The process I suggested for mapping your inputs was rather long and drawn out because we needed to deal with the problem of asynchronous I/O. The problem arises because inputs are under the control of physical processes (electricity) and communication processes (the backplane communication) that we don’t have control over.

Outputs, on the other hand, are completely under our control. That’s why I recommend a simpler approach for setting up your outputs. Where we created a distinct tag called LI01 to hold the internal state of our inputs, I suggest creating an alias tag, LO02 that aliases the existing tag Local:2:O.Data that was created when you added the output card. Just remember to add descriptions to each bit (LO02.0, LO02.1, etc.). Here’s how I’ve configured the LO02 tag in the Controller Tags:

RSLogix 5000 Tutorial - Mapping Outputs

That’s it! This method has two advantages: it’s fast, and it allows you to right click on any output in your program and force it directly without having to do a cross reference. The asynchronous nature of the outputs won’t bite you as long as you only ever drive each output from a single coil (which is a good idea anyway, for readability).


4 comments

  • Clement · September 10, 2010 at 2:15 pm

    Why did you have to map your outputs in the first place?
    Since it’s an alias, and you are not mapping bit by bit.
    What’s the purpose apart from less typing?

  • Author comment by Scott Whitlock · September 11, 2010 at 5:19 pm

    @Clement: As you’ve hinted at, the reason for mapping the outputs is purely syntactic sugar, but for two reasons. First, since there are good reasons for mapping the inputs, mapping the outputs like this provides consistency between the naming schemes of inputs and outputs. Secondly, many electrical specifications say that the wires connected to your I/O must be labelled with the internal I/O address in the PLC. This made sense back in the days of a SLC 500 where the output was O:4/0, but most wire labellers won’t handle Local:2:O.Data.15. LO02.15 is a bit easier to handle.

    Of course, I never said you *have* to do it this way. :)

  • ivirban · February 11, 2011 at 2:50 pm

    Nice…
    What is L from LI,LO stands for? Local?
    As a trainer, I’ve seen some maintenance keyboard users novices who confuses I with 1 and especially O with 0 when typing or reading.
    Does some global naming standards exists? Or each company has(n’t) his own naming standard?

  • Author comment by Scott Whitlock · February 11, 2011 at 5:45 pm

    @ivirbin – yes L is for “Local”. When you get fieldbus’ involved I typically see “D” for “DeviceNET”, and so on. I still use I/O for input and output even though they can be confused with 1 and 0. The fact is, if you’re consistent with your naming convention, then the second letter after the L is always a letter, so in practice it’s not a big deal.

Leave a Reply

Theme Design by devolux.nh2.me