Emerson Exchange 365

Hi!

When I'm trying to add an external reference parameter into the program script in a calc functional block, I can see a few parameter's fields available, among them there is a field called ".REF" (not ".$REF", but ".REF").

According to the logic implemented in the system, the use of this field is the same (or pretty much the same) as the field ".CV". My question is what is the real use of this field (I mean ".REF")? Does anybody know if there is a

description of this parameter's field in DeltaV help?

external reference
twentysevendk twentysevendk
17 Jan 2015 12:58 PM
3 Replies

Rachelle McWright Rachelle McWright
21 Jan 2015 3:03 PM
Matt Stoner , Tinh Phan , Niklas Flykt , Youssef.El-Bahtimy Any insights on this post?
Best Regards,

Rachelle McWright | Community Manager, Emerson Exchange 365

Share. Learn. Network.

Youssef.El-Bahtimy Youssef.El-Bahtimy
21 Jan 2015 3:46 PM
I looked in to this a little bit the other day, and here's my assessment.

Using Watchit to try and read Parameter.REF does not return anything (v 11.3.1) except when referring to a unit alias (which just returns the configured value).

I'd theorize that .REF may be a hook into the default field of an external reference source (the one that is returned when no field is specified, which is different for different types of parameters).

Certainly, $REF returns the path of the reference, but I've never seen .REF in control logic other than for alias referencing. What version of DeltaV is being used here?

1
Matt Stoner Matt Stoner
21 Jan 2015 3:51 PM
First, ".REF" looks to just use the same as ".CV" but I can't confirm that this is always the case in my quick testing.

Second, External Reference parameters can't be changed by logic running in the controller by writting to ".$REF" as it is only set by the download of the configuration.

If you do want to change a reference (".$REF") while the logic is running in the controller, you need to have the parameter type be a dynamic reference parameter.

Note: When changing the dynamic reference parameter with ".$REF", you should confirm that the ".CST" = 0 after changing before the changed reference value is used with any logic. Otherwise you will get a Failure if the value isn't resolved correctly.

1
Recent Control & Safety Systems Discussions
Faceplate Problem.
3 Replies
Foreground Animation
4 Replies
DeltaV 13.3.1 Upgrade and Fieldbus DD file
1 Reply
Read values from a Named Set
6 Replies
OPC UA in ver 14.3. I would like to replace my PI to PI with OPC UA interface. DeltaV Advanced Continuous Historian to site OSI PI server.
2 Replies
<
>
>
Similar Posts
Updating External Reference Path via String in Calc Block

External reference

Detecting #IGNORE on an External Reference

External Reference to DST reference or use DI block?

Exporting the list of External References to Spreadsheet

The Dynamic Reference gives us the .$REF field, where we can programmatically set a Path to a parameter. Once the path has been bound, we now have access to all the fields of that parameter, by referencing the Dynamic parameter.

Note when you set the path, you do not set a field. You set the ModuleName/Block/Parameter with no specific field. The Dynamic Parameter, like any other parameter has a .CST field, called connection status. If the path provided is valid, the CST will resolve to 0, confirming the path is bound successfully. So after you've set the $ref path, you should check the .CST prior to using the dynamic reference parameter. Or at least, you need to assume it may take an extra execution of your module before CST goes to 0.

Once bound, the dynamic reference parameter assumes the fields of the destination parameter. Not all parameters have a .CV field: MODE, Scaling are a couple I can think of.

DeltaV provides the External Reference and Internal Reference parameters which hare the .REF path set during configuration and cannot be changed programmatically.

When you set the $ref path, you should do so by exception. That is, do not write to the parameter continuously. Check that it is empty, and if so, define it. Then check that the CST goes to 0 before you use the value and status that you read.

The purpose of the Dynamic reference is to allow a control module to dynamically change external data links based on operating states rather than writing conditional expressions such as If Then statements to read and pass data into the logic. you can write one expression that uses the Dynamic Reference parameter name, but change the path to make the function flexible.

Some rules I use:
1- Don't use Dynamic references to read or write to IO. This is not supported. It may work in some releases, but ultimately, it is not intended for IO references. IO references should land in a module and the value referenced from the module via.
2- avoid cascading dynamic references. Since Dynamic references are set at run time, the database is unable to verify invalid references or circular references. It will get very hard to troubleshoot and the Status and Connection Status may no longer help as one does not know where the status is being set. Don't do it.
3. Always check the CST has resolved to 0 before relying on the dynamic reference. Else, the value may not be usable and your logic could execute an unexpected response.
4. "With great power comes great responsibility" - Spiderman's Uncle. Don't over use this tool. Again, simplicity and ease of troubleshooting and understanding will trump cleverness. Sometimes it is better to show several External references and select from them in your expressions rather than to define a Dynamic reference that you set. Remember it takes time to resolve the path, and you cannot verify the status of other values when they are not bound. Make sure you are using this for the right reason, and not just because you've figured out a new hammer... and everything looks like a nail.

Andre Dicaire

In reply to Andre Dicaire:

Andre Dicaire ,

An integrator used dynamic references to fields on data sets from a VIM with an Ethernet/IP driver. Is that supported? or is that considered unsupported like dynamic references to DSTs?

Thanks in advance,
Brian

In reply to Brian Hrankowsky:

What you describe is a Dynamic reference to a DST. The DST is the Serial Dataset of the Serial Card emulated by the VIM, or a Signal if you are using the DeviceNet emulation. That would fall in the not supported category. What that means is, although it is working in your current version of DeltaV, you may be forced to change your configuration if at some point the controller prevents the Dynamic Reference from accessing the Dataset Registers directly. If you called the Support center with an issue that your Dynamic Reference to a Database register was no longer working, you likely would be informed how that is not supported.

As we all know, DeltaV licensing is based on IO usage. IO is counted in the Database, based on explicit references from IO blocks or External references when using Bus or Serial data. If you use Dynamic references, the database does not know what that reference will be.

With real IO, the IO blocks provide scaling and alarming functions as well as status propagation. Trying to bypass system licensing would create some complicated configurations, and a host of unexpected behaviors on downloads... It is just not a good idea.

With v12 license changes, there is no more duplicate licensing created due to user configuration. This impacted Serial Datasets the most as one data set contained values that were best processed in separate modules. This led to the wide use of Landing or Marshalling modules. One module = 1 DST for each dataset. In v12, it is now 1 DST per Dataset period. You can have 100 modules read 100 registers, and it will still be 1 DST for the DataSet.

So I think it's up to you if you want to change this configuration or wait until you are forced to, and you might never be force to.,

Andre Dicaire

In reply to Andre Dicaire:

Thanks Andre. I doubt the LBP was trying to bypass licensing. The dynamic reference approach really simplified the configuration and shrunk the overhead of the application quite a bit. We'll work on a path forward.

I would like to ask that is there any experience of significant delay in binding dynamic references between modules in different controllers over modules in same controllers?

In reply to Aishwarya udas:

yes there is a difference but not significant. local references bind more quickly as references are to local memory and data structures.

A remote binding on the first parameter of the module requires the controller to locate the remote module. This is done via a message to directory services for the controller hosting the referenced module.

With the location known, the Proxy Client Server are created and the parameter data begins communicating.

If the module is already serving data to this controller this first step has already been done, possibly with an external reference, and the Proxy client server already exist. then the new parameter is added to this proxy pair.

If the parameter is already being served, then the binding will be the same as a local parameter.

Note that once a dynamic reference is made for a parameter, that value continues to communicate even if the reference is changed and the parameter is not being read. It is ready for the next time the reference is made.

when the Dynamic reference $REF is set, the CST will go to pending, and then to 0 when complete. use a 100 ms module and test this with a local parameter and a remote one. start a timer when you set both references and note the time for the CST of each to go to 0 or Good.

note the first time should take a bit longer than the second time.

Also the module execution rates determine the update rate of the parameter.

Andre Dicaire

In reply to Andre Dicaire:

Thanks lot Andre for making concept clear.

Why we need to download set up data if dynamic references are not resolved quickly in crossconroller communication?