Unassigned I/O References

I assigned a device tag to an I/O reference in an AI function block. The device tag had not been allocated to any I/O channel. When I go to the I/O (conventional or CHARMS) and browse for a device tag the device tag does not appear in the Unassigned I/O References. Shouldn't it be there? If I select All instead of Unassigned I/O References I can see the DST listed amongst the rest but with no Channel assigned as expected. If I click Find  from Unassigned I/O References and select Object Type 'I/O Reference', the device tag is listed.

Am I misunderstanding something? This is DeltaV version 12.3

  • You are not misunderstanding things. The unassigned I/O reference list is a list of Tags entered into control modules that are not assigned to an IO channel. This allows you to bind an IO channel to a tag name while defining the control module, but you have not configured the IO where this signal will actually exist. The only way to add a tag to the Unassigned IO Reference list is to configure that tag name into a control module IO reference. The tag will disappear from the list if you assign it or go back in the control module and remove it.

    Some times, it takes a few minutes for a tag to appear in the list. Not sure how long you waited, but it should make it to the list. If you have not cleaned the database for a while, (regular maintenance stuff), it might help to do so.

    For those not familiar with the Unassigned IO references, it is good to understand the perspective of this list.
    - Device Tags are "Assigned" to IO channels. A Device Tag can be created in a control module by typing in the tag, or via bulk Import. If the Device Tag is not yet defined at the IO channel level, it is added to the Unassigned IO list. The Device Tag is referenced by the Module, but is Unassigned.

    - An IO channel is "Referenced" by a Module using its Device Tag. It can get confusing because we are asked to "assign" a CHARM IO channel to a controller, but this has nothing to do with which modules reference the IO Signal. The IO Configuration tool lists all IO channels by hardware location and indicates the Device Tag of the channel, and what module(s) it is "Referenced By". If the Referenced By field is blank, no module currently references this channel, by its Device Tag.

    So Device Tags are Assigned to IO channels, IO channels are referenced by Control modules. You can create Device Tags during Control Module creation, in which case they are referenced, but not yet assigned. Or you can create the Device Tag when defining the IO Channel, at which point they are Assigned, but not yet Referenced. Late binding happens when both the tag is assigned, and is referenced. This allows the IO to be configured, installed and even commissioned, waiting to be referenced. When the referencing module is imported/added to the database the IO channel is bound by tag to that module reference. The control module configuration Engineer does not need to know where the IO channel is physically located. The tag binding will connect the two.

    Note that a control module can reference an IO channel assigned to a different controller. Since the IO channel is not local to the module's controller, the input value is passed by it's host controller to the Module's host controller. In this way, a single IO channel can be referenced from different modules in different controllers. Prior to v12.3, multiple modules referencing a single IO channel would result in multiple DST licenses. In v12 and later, each IO referenced by one or more modules is counted as a single DST license.

    Andre Dicaire

  • In reply to Andre Dicaire:

    I've just come back to the configuration and, as you predicted, there is now a list of unassigned I/O.

    In the past I have usually assigned tags to the I/O first and then referenced them when configuring the I/O reference. I had read about the alternative way which seemed to be useful, particularly when the client is dilatory in providing an I/O list. However I hadn't really understood it. Thanks for your comprehensive explanation which makes the concept very clear.

    It also clarifies a couple of things that I have noticed over the years. Firstly if you change the tag on an I/O channel you don't have to change anything in the modules that reference. This I now realise is because the reference is via the I/O location not via its tag. Secondly when looking at modules online, the online value of I/O parameters is blank and not the tag as you might think.
  • In reply to Cedric Dawnhawk:

    Although Control studio is configured by Device Tag, and shows this tag if it is unassigned, for some reason, it changes to show the hardware path once assigned. It is useful to know the IO block is bound to a physical channel. But showing the device tag along with the hardware path would be a more complete and useful approach. You might want to visit the UDEP site and submit this as an enhancement.( www.userideas-emerson.com/ )

    The workaround is to add a text field in your module under the function block and type in the Device Tag there. This will show the tag name wherever you open the module offline or online in Control Studio. But it is a manual task that needs to be verified during commissioning. As it is, if the Device Tag is unassigned, it shows up by name in the control studio view. Once assigned, you get the hardware address.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Andre
    Please what happens if a channel fails e.g. in DeltaV 9.3. Usually if I have another spare channel somewhere in another I/o card. Can I reassign the Device Tag of the failed channel to the spare channel and not make any changes to the modules that reference the bad channel?
  • In reply to chigarthur:

    Yes. But technically you will have to download the module. When you reassign the Device Tag, the database updates the module to point to the new Physical IO location. This will flag the module as changed, and you must download the module (Partial Download) along with the changes to the IO, and of course, move the wires. You do not have to edit the module in control studio as the reference is to the Device Tag, which you are not changing.

    By reassigning the Device Tag to a new IO channel, you do affect anything that uses that channel. So if it is a HART device, you will need to reconfigure the device definition, simply by auto sensing the device, and then also rescan the hierarchy in AMS Device Manager to update the location of the device. I expect you would need to download any "changed Setup Data", since this should affect the DST setup data. And therefore download Changed Setup data to the Pro Plus, letting Auto Update service take care of updating all the consoles. Note that the affected setup data on a Device Tag reassignment is not likely to affect anything at the console level in Operate, especially if the channel is not HART. But you should download the changed setup data to cover any IO references in applications like DeltaV Insight etc and to make sure PlantWeb alerts on that HART device are properly aligned.

    In v9 CHARMS do not exist, but Remote IO does. It is all the same behavior, whether it is a local IO channel or remote IO.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks for this lecture!!