EE - Forum Styles

Dynamically Referencing IO / PK Controller Pros & Cons

Dynamically references to IO is not possible with 'vanilla' deltaV.  I suspect that this is because dynamic references to IO breaks the current licensing model, among other reasons.  Nonetheless, this is a recurring customer request.

Using a PK controller, there is a way to provide for Dynamic IO.  I am interested in learning what the community thinks of this idea, and any Pro's or Cons to using this method.


1.) Map IO into DeltaV any way you like to a landing module.  This can be bussed, traditional, remote IO.

2.) Create a dynamic reference parameter for each IO you wish to dynamically assign.

3.) Publish the dynamic reference to the MODBUS port of the PK Controller using MAP REGISTERS.  Set the IP address of the Modbus port to something like

4.) Configure the Ethernet IO port to IP address something like

5.) Create a LDT under the Ethernet IO port of the PK controller. Use the PK's own IP address of  So now, the PK controller is reading MODBUS from itself, via TCP/IP.

6.) Assign registers to new DST's.

7.) Verify that the MODBUS port and the ETHERNET IO PORT can communicate. in PK controller settings.

8.) Download!


Change the dynamic reference to point at the OUT parameter of the AI/AO/DI/DO block in the landing module.  This is published onto MODBUS, and looped back into the same interface, which creates a DST which can be assigned to IO in the field.

This separates the IO from a Hardware and software perspective.  Now, We have IO for physical objects, and IO for logical objects.  We can map the physical objects onto logical ones by changing one dynamic reference per IO point.


-It seems that this can be done at a reasonable cost, with the licensing of the ethernet port by LDT and up to 100 parameters per LDT counting as one DST.  It does have a cost, though.

-No equipment outside a PK controller seems to be required.

-"SOFT" CMs won't be needed if we can publish parameters back onto MODBUS and read it back into DeltaV via a loopback as a DST.

-It will be necessary to create a new alarm parameter which forwards hardware alarms up to the referencing module.

-Can be set up fully redundantly.

-Can be configured via bulk edit.

-Requires no external network hardware.

-Very fast interface.

-I do get a warning that an LDT and the PK share an IP address, but download still works fine.

-Provides a new way to simulate values onto a deltav system.  

-Modbus interface seems like a good way to do competitive integrations.

Questions for the community:

Where would you put the dynamic reference parameter?  Does it make sense in the landing module?  Or should it be in the AI/AO/DI/DO module which the IO is mapping?  It can be anywhere, but what makes the most sense?

Is this robust enough?  Has anyone tried doing this yet in a production environment?

8 Replies

  • Very creative. looks like a solution in search of an application.

    Once you land your IO in the landing module, it is explicitly referenced and licensed in the configuration and you can now dynamically reference this value from any module in the DeltaV system.

    I guess I'm missing the problem you are solving. But in addition to the original DST's counted in the Landing Modules, you've added the licensing for the Ethernet MODBUS TCP IO license and additional DST licensing of the Logical Device tags, as well as convoluting the data flow. Not to mention the loss of HART data and signal integrity to the consuming control module.

    Nope, I would be firmly on the don't do this side of the fence.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Bruce, I guess I'm still trying to understand the use case.  Is the goal to reduce DSTs and therefore system cost?  Or to use 3rd party I/O?  Or a combination?

    I've used landing modules with serial I/O (old Mynah PLC IO Interface), Sthal I/O over Profibus, and a few other scenarios.    I always used external references vs. dynamic references.  If I'm not mistaken, the external reference works much better when searching for what references (especially writes) to a parameter (in this case an I/O point).  

    Landing Modules:

    • Landing modules are not difficult to support and with proper naming conventions can point to the physical location of the I/O address.
    • Landing modules consume additional CPU resources.
    • Landing modules become the limiting factor in module execution rate for the control modules referencing them.  If you try to scan too much at high frequencies (200msec), then get ready to purchase more controllers.
    • Landing modules required us to create custom AI, AO and DI blocks as we couldn't reference the landing module parameters with the I/O address parameters. 
      • These custom modules required even more CPU time as it is difficult to recreate all the functionality in a prebuilt FB with custom code without using more resources.  (~1000 vs. 400 usec exectime for an AI)
      • We were able to use the F_IN_Dx & F_OUT_Dx parameters with the DC blocks.
    • Landing modules will allow you to break the rules on writing to an I/O address in a different controller since you are actually writing to a parameter via the external controller.  This is helpful at times, but dangerous if not done with proper error / communication checking.

    Dynamic References

    • I love the ability to use dynamic references when really needed.
    • I avoid the use of dynamic references unless absolutely needed.  
    • I personally wouldn't consider using dynamic references for I/O (especially outputs).
  • In reply to Michael Moody:

    We have a customer who has purchased some RSTi I/O- which is now an Emerson product of course! These RSTi couplers use Profinet, so they have already given up integration of the HART. VIMs pivot this profinet data to serial data where it is consumed by DeltaV. In the system that they are trying to construct, they'd like to be able to re-arrange everything. In this way, they can make different products, by re-arranging unit operations. An agile manufacturing environment. They have a non-pcsd library already in use, with an established track record.

    It is the customer's preference to be able to switch inputs and outputs without re-downloading CM's which reference IO, or by passing in parameters to indicate which physical IO is linked to which logical CMs. This is in some ways accomplished presently via dynamic reference composites, which MAP parameters from a composite onto standard I/O function blocks. However, this can miss the mark because it does not pull in standard module parameters, like IOBAD for example, so additional modifications the library would be required for this functionality. Additionally, these would use new custom blocks. Each of these dynamic reference composites contains MANY dynamic references (almost one per parameter in an AI block!), which makes understanding the flow of data challenging. Ever consider charging for dynamic references?

    This concept of 'looping back' the data through an interface simplifies the structure of these custom AI / DI / AO blocks. Reducing DSTs is not a large priority here, building a flexible environment is the driver. I'm trying to leverage built-in features of the hardware to simplify the total configuration, even if it costs a little more.

    At its core- an IO address is a more granular piece of information than the associated data in DeltaV.

    In managing a library, there is a lot to be said for keeping the number of custom pieces as small as possible, particularly when there is regulatory oversight possible.

    Thank you for mentioning the F_IN_x and F_OUT_x on the DC block, very helpful.
  • In reply to BruceSchaller:

    I don't dispute that dynamic referencing could be of great use to create flexible IO addressing schemes. You are describing a specific requirement that seems to be best served by enabling dynamic referencing of physical IO. In this case, Ethernet based IO over a VIM that lands the data in a either a Serial card dataset or possibly a Profibus card signals. These types of IO values are recommended to be used with External Reference rather than IO blocks, and so things lie HART data and individual signal health diagnostics are not directly at play. Signal health will have to be passed with a separate "status" word as the status of each signal is based on the communication health of the link.

    A dynamic reference, once bound behaves just like an External reference, with the same CV, ST, CST and AWST fields. So yes, being able to reference these signals or registers through a Dynamic reference would allow a CM to be redirected to a different set of IO signals at run time without downloading the module.

    The reality is that you will not get Dynamic Referencing changed for your customer, and even if this comes to pass, it is highly unlikely that it would not require some level of reconfiguration of the existing library to make it work. Is it possible there is another way to provide desired flexibility without the use of Dynamic reference parameters for IO?

    In the ISA88 model, a control module would represent a basic control function, like a control loop or motor or valve, each with specific IO, and each CM is uniquely named. With the Batch environment, we can use aliasing to allow any collection of control modules to be used by the single Operation/phase logic. Dynamic referencing was added to the product to enable this level of flexibility outside the Unit Aliasing structure. But still it is intended for Module/parameter referencing.

    For a VIM dataset (which is what you indicated the Profinet device is mapped to), you can land the entire data set with External references in a landing module. This was common practice up until v12 due to how DST licensing was counted. A single module referencing the dataset 100 times was still one DST, but referencing the same 100 registers once in 100 separate moduels was 100 DSTs. In V12 the license count was based on the IO being referenced once. All additional references are gratuitous.

    With external references, you can directly reference the input and output registers from the CM's. But you cannot use dynamic references. But if you simply revert to a landing module, the CM's can use dynamic references to these External references. The landing module can be used to reference any IO. You could structure them to mirror the physical IO device, adding appropriate diagnostic information. Or you could structure them based on IO signal relationships, such as IO for a Unit, combining Serial data, native DeltaV IO signals etc.

    Your original construct involved a landing module, a modbus master to slave exchange, which would return Logical Device registers, and it seems you would also need to add the VIM communication to the Profinet. I'm not seeing the need for all this extra data manipulation. Simply land the RSi I/O data into one or more Landing Module and Dynamic references are available to your configuration.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Andre - a bit off topic but I am curious about your statement recommending external references in lieu of I/O blocks for serial / Profibus I/O. I like using the built-in scaling and engineering units etc. Why is external reference recommended?
  • In reply to John Rezabek:

    Start by looking in Books Online under Configuration -> I/O Configuration -> Using Profibus DP, DeviceNet, AS-Interface and EIOC with DeltaV function blocks.

    Andre will soon give an excellent novel on the topic (Sorry Andre I had to take a shot at humor :D) but my cliff notes on this subject is the control system will probably try to do something with outputs during a time when communication to device(s) is interrupted. I/O using Function Blocks attempts these I/O driving only on the change of the value. The wired External Reference is attempted every scan so when the device becomes good/communicating again the value would be written unlike what occurs when using a Traditional I/O block.
  • In reply to Matt Stoner:

    Matt - thanks - perhaps that explains why serial IO so utilized sometimes spawn annoying "I/O input Failure" or "Inputs Transfer Error" that show up in the event journal and then clear a few scans later . . .

  • In reply to John Rezabek:

    Good question John. Books on line details the use of External references for Bus cards, including Profibus, DeviceNet, Asibus and Serial Cards. For FF, we references the FF blocks.

    This recommendation is primarily for outputs. As for Inputs, you can certainly use the input IO blocks to process them with scaling and apply alarms and such.

    The reason is that on a loss of communications, AO, DO, DC, EDC blocks that are bound directly to Bus card signals will stop writing to them while they are in Bad Status state. The IO blocks are designed this way so that if an output channel goes BAD status, the block waits to see what the state of the output will be when status is restored to good. Then the IO block initializes to the current state of the channel, which may be different, and mostly likely is in a passive state.

    The Bus cards are different in that they hold data that will be written when communications is restored. In the case of a motor that was running when the comms loss occured, it may have a time out on loss of comms and may have shutdown. If the Profibus signal was active, it is possible that the card will resend that active run command before the Module can determine what the current output value should be and the motor restart.

    By using an External reference, the DeltaV module can determine that the motor has timed out and set its output in the bus card to 0 to align with the expected off state of the motor.

    The key for this is that the DeltaV module time out should be a bit shorter than the motor time out to eliminate a window where the motor may time out but the signal is still on. If the DeltaV module sets the run to stop, and communications is restored in the window before the motor times out, the motor is stopped by the DeltaV timeout, and no restart happens.

    This is really only an issue if we are using a single bit run/stop command rather than separate start (momentary) and stop (Latching) commands, such that the normal state of these commands leaves the motor as is. Or in the case of some devices a command word is used that has a RUN/STOP bit but also a RESET bit. On a loss of comms, the motor ignores the RUN/STOP bit until a Reset command is seen. This allows the DeltaV Module to align the Run/STOP bit with the state of the motor before a reset is issued to restore remote command of the motor.

    Some devices have neither of these options available and have a simple interface with a run/stop bit. In that case, the double time out on comms allows a motor that trips on loss of comms to remain off until appropriately commanded to start again after issue is resolved, and that requires use of External reference. (for the outputs)

    Andre Dicaire