Is there a way to add a functionblock's IO_REF parameter to a faceplate? On the AI detail page, I would like to show where the AI is wired up, including card and channel.
No, the IO_REF parameter on standard DeltaV I/O function blocks are not a controller runtime parameter so you can't reference this as you would like.
1. The input parameter use a external parameter to the Output Parameter
1. The output parameter use a external parameter to the Input Parameter
In reply to Lucho:
Lucho,
It is almost always better to read parameters (i.e., module B reads from module A). Other than sequences, supervisory logic etc. you should never write from structured text code in one module to anything in another module; and in the cases where you don't have any other option, use extreme care and document the module(s) being written to with what is written, from where, for what purpose and under what circumstances. I have seen poor practices in this respect cause no end of difficulty.
Best regards,
Neil Brown.
There are several reasons for using a write instead of a read.
- For continuous transfer of data, using a read ensures that the destination module controls where the data comes from, eliminating the possibility of multiple sources writing to the value. Neil's response speaks to this and the potential confusion in trouble shooting where an unexpected write occurs overriding the expected code.
- when the modules are located in different controllers, a read sets up unsolicited communiations that transfer data efficiently and the destination module is aware of a loss in communication through the status of the parameter. If your configuration reads the data, it will work effectively whether the modules are located in the same controller or in different controllers.
When using a write command the destination parameter is unaware if the writes stop. it is the responsibility of the writing module to verify the write is successful and to report that consequence effectively. Writes have that AWST (asynchornous Write Status) they should check to see that the write was successful. Writes can fail if the destination is a block parameter with mode or Engineering unit ranges and the value is not accepted (i.e. writing to a PID/SP while in CAS mode or with value that is out of range).
Sequences usually write to modes and Setpoints to automate the execution of commands, and these actions should always perform error checking to identify when the sequence fails to execute. Writes should never be continuous as a matter of best practice.
When modules are located in the same controller, writes and reads are basically direct memory references and if we are talking parameter to parameter, then mode and EU Scale ranges don't really matter. The CST and AWST status will always be good, because there is no external communication. But using Reads ensures a consistent approach, even if modules are in different controllers. And only one source can affect the reading destination.
Andre Dicaire
Hi, ADicaire, may be there is an error in the phrase above, may be is as follows:
There are several reasons for using a read instead of a write.
In reply to Matt Stoner:
Thank you Matt. It seems this post has been hi-jacked by a read/write discussion, but I've seen your name buried enough in various module properties in DeltaV systems, that I am confident yours can be the last word.
In reply to frankkant:
Your welcome, I believe a number of releases ago (I have been through all of them - yes since v2 so it is a little fuzzy), this parameter may have been in a runtime parameter. I have numerous customer request for this to be displayed on the detail but in the latest versions of DeltaV it isn't available.
You can refer to KBA article NA-0400-0041 for good info on read/write in deltav.
I only partially agree that read is always better than write to echange data between modules.
Having a module with several input parameters as external references has a problem in terms of project execution. That module will not be finished until all those modules it will read from are there. Basically everything is not finished until late stage in project execution. This makes hard to estabilish "finished" work packs.
The point is that after class based development was introduced, using external references to bind modules maybe is not the best option. Hierarchical design using Equipment modules with private/shared module block references, makes posible to use wired binding and code binding. Code binding can be done from SFCs within EM or CALC/ACT blocks using the the module block reference blocks instead of the real module bound to those module block references. In this way the writing is, more or less, an internal parameter writing within the EM.
"Assign module and all contained non-SIS modules" and "Download module and all contained non-SIS moduels" options are good to have everything syncronized. It's also possible to define execution order of function blocks/module bloks into EM so you can define the order for data exchange between modules.