Has anyone found a way to display I/O information (like controller-card-channel) on a graphic or detail display, similar to what you see in Control Studio Online? If you have, do you have to do anything different to display this for different I/O types (conventional I/O vs. CHARMS I/O vs. Foundation Fieldbus vs. DeltaV with Provox I/O vs. Devicenet, etc.)? It seems like, since it is available in Control Studio Online, that it ought to be available within DeltaV Operate but I have not found a parameter that allows me to do that.
I look forward to any responses.
Gareld Butler
I would open diagnostics and browse to the I/O information you are interested in. From there, right click and select Properties. The dialog shows Parameter Path. If you copy and paste this into a datalink (of course change the field to add the A_, F_ , qualifiers), you should be able to read the value in graphics. This should work regardless of I/O type.
Gareld,
Guessing that you want to provide hardware information relating to a control loop, such as where the transmitter and valve are connected? DeltaV does this with Control Studio, which is accessed in context through the module faceplate or any alarms. you might also want to know where a physical device is located. Maybe a Loop Sheet tied to the Control module and called in context on the Operator station would be a more complete solution. But adding this information to your control displays, via control modules will require significant configuration and data entry. It would help if you clarified exactly what you are trying to accomplish, who needs the data and why. That sort of thing.
You should understand that Control Studio does make a connection to the Database to get theinformation that it shows, and some of this data persists in the Online view. If you look at the IO parameter off line, it will be populated with the DST name and parmaeter. e.g. AI1/IO_IN = TI-4001/FIELD_VAL_PCT. In the FB diagram, this will be translated to the hardware path where this DST is assigned. This could be a CHARM or conventional IO, or blank if the DST is unassigned.
At run time, the IO_IN parameter is blank and does not return a value. If it did, it would be the DST name and not the physical path. The AI block still shows the Physical Path in Control Studio diagram under the block, but this is from the configuration database, not runtime information. The signal channel information is actually downloaded to the module but is not exposed in a referencable way at run time.
You could add text parameters to your modules and populate this with the IO hardware paths, and then modify your Facplates and Detail faceplates accordingly to display this infomration. Or you call up Control Studio and get the right path every time, with no user data errors. But there is no runtime parameter in the blocks to get the paths.
For your PROFIBUS or DEVICE net IO references, BOL recomends these be done with External Reference parameters. For these references, you can read the $REF field of the parameter and this will return the hardware path. For instance, I configured PARAM1 to DST path "PDT001/FIELD_VAL_D". At run time, I can read PARAM1.$REF and I get CTRL-1/IO1/C02/P01/DEV001/SIG001/FIELD_VAL_D.
PDT001 is a unique DST name defined under my device called "PDT1" on SIGNAL 001. Notice the path says DEV001 and SIG001. The device address is "1" and this is the first Signal configured on the device. This path uses indexes. For Devices, you'd want the Device Name which is not provided in this path.
Sorry i can't offer you an alternate method to resolve this information, other than using Control Studio in context to the module, or adding a documentation link to call up a Loop sheet or other document.
Andre Dicaire
In reply to Andre Dicaire:
Thanks, Andre.
What we were looking for is a way for the operator to do some initial troubleshooting of an I/O problem without having to call up (or understand everything that is going on in) Control Studio Online. I had considered placing text parameters on the detail display (I/O tab) to guide them but was worried that someone might move a device to a different I/O channel and forget to change the text parameter. I was not willing to take that risk.
Is there a way we could use external reference parameters for references other than PROFIBUS or DeviceNet I/O that would also provide the same capability of reading and displaying the $REF field?
Thanks.
In reply to Gareld Butler:
I would take another approach. Building something into thre control modules and into the faceplates will be prone to error and require a lot of work.
If you maintain loop and wiring sheets for your control strategies, you could place these in a shared directory and have a faceplate call up the pertinent loop sheet to show where equipment is connected, and even located in the field.
You could create a comprehensive list of all signal tags, there physical location, and there module references. From this, you could parse the file with a vba function based on the Module name and show the operator the physical IO locations .
Unfortunately, this list does not exist.
The IO configuration utility provides a list of IO assignments for all LocalBus IO Cards, but does not include CHARMS. You can print this to file and it inlcudes the referencing module/blocks for each signal tag.
CTRL-1
IO1
C01 AI Card 8 CH 4-20mA HART
CH01 HART Analog Input Channel TT-789 TI-789/AI1/IO_IN Temperature of tank
CH01 HART Analog Input Channel LT-101 LIC-101/AI1/IO_IN Tank Level controller
etc.
For CHARMS you can export each CIOC to XML
CIOC-1 CHM1-01 PT-2503 AI 4-20 mA HART CHARM AI4-20 mA CTRL-4 PC-2503/AI1/IO_IN
CIOC-1 CHM1-02 LT-2502 AI 4-20 mA HART CHARM AI4-20 mA CTRL-4 LC-2502/AI1/IO_IN
etc
(there are more fields (columns) than I've shown, and data is actually in XML. This is what it might look like in EXCEL, showing some of the data in the export.)
You would need a utility to parse these files and generate a common format data file of all IO refrences and then use this file to provide module specific IO references in context to the operator.
Controller IO Type IO_Card Channel DST ModuleReference Path
CTRL-1 IO1 C01 CH01 TT-789 TI-789 AI1/IO_IN
CTRL-4 CIOC CIOC-1 CHM1-01 PT1000 PC-2503 AI1/IO_IN
Etc.
Maintaining this would mean updating the data files with a new export from time to time, and runing the utility to parse and create the common data file. The output files need to be generated manually.
Alternatively, you could parse the FHX file of the database, which would be more challenging to create. If you did that, you could schedule daily exports and trigger a new parse of the FHX automatically.
Or you could add text fields to modules and manually manage this information.
I'd vote for integrating loop/wiring data sheets in PDF for the Operator to reference with a single click, if they exist. OTherwise, I don't know what to tell you.
Would it be useful to have an As Built IO reference list that showed where and how all the IO was being used in the system (Module/path references)?