Hi Nick, thank you for your input. I wanted to try and improve upon the design and I knew it meant turning it all into UDTs. I also realized that I was combining 2 separate but related system components into 1 tag, those being the IO Device and the IO Channel. My tag structured represented the IO-Map and then used to identify the device by linking descriptions to each IO channel. I decided to split these 2 up into separate UDTs and link them together with the associated IO address like a relational database, the IO address being a key between the io device and io channel.
Input Module UDT
Digital Input Channel UDT - Definition
I created a 16 digital input module UDT to see what that would look like. It required creating another UDT, a digital_io_channel udt, and adding 16 instances to the input module UDT. The digital IO udt consists of 4 tags (only 2 are needed, I later added 2 more) and no parameters. The 2 needed tags are “IO_Address”(string) and “Value” (boolean). I define or partially define the values for these tags with parameters from the Input module UDT.
The 16-channel-input-module-UDT definition consist of 2 parameters, plc_name and io_base_address (and added later ‘wire_number’ and ‘drawing_number’), and 16 instances of the ‘digital_io_channel’ udt. The io channel udt definition is finalized at this level by sequentially adding a number to the end of the base io address to correspond to with each channel.
I created a new UDT definition for each module type, the new project I was working on had 3 generations of allen bradley PLCs. 1 PLC had over 150 IO modules and used 24 different modules types, and so I created 24 module UDT definitions and named them after the module’s model number.
Input Module UDT Definition
I can now create a new instance of any module by giving it a name and defining a few parameters.
Input Module UDT - Instance Example
##IO_Device UDT
I created a io_device udt as a generalized example of any io device to start building from. The idea from there is to create more specific udt types such as IO_Device/Level_Transmitter or /3-Way_Switch. The io_device UDT definition consist of tags that I would use to logically locate when searched for. It’s ‘Description’, ‘Device_Type’, the ‘Area_Name’, and ‘Equipment_Name’. This is an attempt to create a nicely organized view of the system but it immediately starts to grow in complexity. Organizing the system neatly is only partial achieved. The outliers, devices which have associations that span multiple areas and equipments demand more layers of complexity. Do I allow for more than 1 equipment and area association or do I create sub-areas or groups of equipment zones? Buttons and switches have these issues. 1 switch can control many machines but that is not the norm. A switch is often located in a different area than the equipment it is controlling. Do I now create another tag to associate a panel_id? Hydraulic systems also require consideration as they can span multiple areas and equipment.
In the IO_Device definition pictured, I create some tags that I will be removing as they are tags derived from the associated IO module and io_channel UDTs. I think I should keep that data separate and keep only the associative IO_Address tag as the shared key between them.
IO_Device UDT Definition
I used the plc tag name for the name of the io_device instance. The PLC tag naming convention used here is fairly typical, hard to understand for someone new to the system, but consistent and thankfully complimented with tag descriptions. The tag names were descriptive in same ways I wanted to organize them, meaning they usually contained the needed information and I could use the patterns to apply associations.
I created the 1200 or so io_device UDT instances from this 1 plc and placed them all in 1 folder. I envision something more organized within the tag browser, but at this stage it is not needed for the task of creating a screen to search for these io_devices. The search criteria will be more dynamic than a folder file structure, which is what is used for the IO_Map search tool.
Usage
In Vision I created a template for use in a template repeater to display these data points in logical groupings and added all relevant information so to be useful to anyone troubleshooting the system. The screens are intended to be quickly scanned through to find relevant information and collected if needed for short term monitoring by clicking on an instance turning it to a popup window
IO Map Search
The ‘Get Values’ button runs a script that browses the io device folder and pulls data needed for the selected module. The script runs fast enough, but I imagine there is a better way to do this and creating the io_device search tool caused me to rethink it all.
IO Device Search
At first I thought that in addition to the IO_Address tag, the IO_Device udt needed to have the IO_Address_Source_Path, the path to the associated io_channel udt instance, so that information could be more quickly derived for my search tool. I don’t want to run a script that performs the long operation of linking the io_channel’s path each time I do a search. From the perspective of the io_device, all the io_channel’s associated data is to be pulled, but whats the best way to go about that? I have a habit of using hidden tables on my screens that help me debug. In this case, I am generating a dataset to be used for a template repeater that is derived from a larger dataset on a pre-populated hidden table. The template repeaters displays the selected slices of information. I saw major performance improvements from having a hidden table referenced and realized that it could easily be populated by a dataset tag instead of by the script when the window opens. Each PLC could have its own dataset tag containing all the io_device info with its associated io_channel info and as long as its kept up to date, can be used for the purpose of this search engine.
