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.
Setup:
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 192.168.1.77
4.) Configure the Ethernet IO port to IP address something like 192.168.1.88.
5.) Create a LDT under the Ethernet IO port of the PK controller. Use the PK's own IP address of 192.168.1.77. 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!
Usage:
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.
Notes:
-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?
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:
Dynamic References
In reply to Michael Moody:
In reply to BruceSchaller:
In reply to John Rezabek:
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 . . .