Hi,
I am trying to read in a parameter the Eng. Unit of an analogue input using a CALC function block and referencing to MODULE/AI1/OUT_SCALE.UNITS. I would expect that the return will be the engineering unit (e.g. kg) of the AI function block, instead is an integer. Does anyone know how can I do this?
Thanks!
I am curious what are you try to get accomplished within your CALC logic?
I don't believe that you will be able to reference the text "kg" within the calc block logic but if you open the file DVData\download\EUDT.scr with Notepad, you can find the associated integer number with the EU that you want and then write your logic using these numbers.
Example:
(MODULE/AI1/OUT_SCALE.UNITS = 1088) would be your check for kg
Word of Caution: All the values will be the same except Custom Engineering Units which could be different numbers depending on how they were added or imported into the DeltaV system. If you only have one system then you should be fine but if you have a development/simulation system as well, these numbers might be different on each system depending on how the custom EUs were added.
Regards,
Matt
In reply to Matt Stoner:
Matt's question is of utmost importance. The right solution requires an explanation of the needed functionality.
I'd like to caution using the *.SCR files. These are internal files of the DeltaV system and are not documented. I've used them myself, but I don't expect them to remain unchanged or even persist from revision to revision.
EU information is intended for Operators and are primarily used by Operator stations. In DeltaV Operate, reading the EU units will result in the text value being returned.
If you are looking to see if a Units parameter is correctly set, you could configure a Scaling Parameter and set it to the KG units. Then you could compare the AI scaling to this reference parameter. The reference parameter name could be assigned restricted security access so it does not get changed. This way you set the reference using engineering tools without having to look up integers in a system file.
Note that you cannot programmatically access these .SCR files from controller code.
Andre Dicaire
In reply to Andre Dicaire:
BOL states: Engineering Units: This is a string in the workstation and a 16-bit unsigned integer in the controller.
I could see needing to reference the units in an operator message, batch prompt etc, that would need to be concatenated in the controller with other string message information before it is picked up by the graphics.
Another potential use would be to facilitate automatic scaling from one unit to another (without using a scaler block).
If you use an OPC client, you can probably bounce the string from the OPCserver back into another control module.
In reply to Youssef.El-Bahtimy:
Scratch that, the OPC server does not render it to string like it does with Named Sets.
Hi guys,
I once had Exactly the same problem as Anca when I tried to decode the EU of an analogue value for generic operator messaging purposes.
I used what you might consider a sledge hammer approach to break the nut! But never the less supported by Emerson!
My solution was to create a simple function in a composite embedded in the Phase/EM/CM. I read the .UNITS value (X) as an integer and passed that to an input parameter of the composite, 1 scan later the function returned the string value from a simple lookup calc block into the composites string output parameter.
I didn't decode the thousands of possible EU values available, just those that my configuration used. If a value of X was entered that wasn't in my lookup calc I simply returned the string value "EU value X not know" this then allowed the lookup table to be expanded. The reality is a single project only uses a small number of the available EU.
I didn't try to utilise any Emerson unsupported methods, always best steering away from those as there is potential that DeltaV implementation changes and those methods suddenly stop working after an upgrade.
Good luck,
Neil.
The request is to include the Engineering Unit in the alarm message e.g. 'High High Alarm Value 99 m3 Limit 95 m3'. Therefore I am using the CALC Block to Read the AI1/OUT_SCLAE.UNITS and use it to create my %P1 and %P2 parameters for the Alarm Message. What I did not know was whether or not the integer number returned can be used to associate it always with the same EU and what the risk of doing this is.
Anca
In reply to Anca Vacar:
So the real issue is that the Alarm Message is generic in the Alarm Type, yet a high alarm is common to all manner of process variables, so you can't explicitly place EU units in the Alarm Message of the High High alarm. You could make a HighHigh m3 alarm, but you'd need a Low, Low Low, High as well, and then again for KG/Hr, L/M, etc.
This sounds like an enhancement opportunity for DeltaV. Where the EU Units is automatically provided as a variable for the alarm message, allowing for a defintion like:
"High High Alarm Value %p1 %Units Limit %P2 %Units"
Where the %Units is automatically extracted from the scaling parameter at download to be used at runtime to record the alarm message. Or the user simply defines the EU Units for the alarm as part of the specific module alarm , and not the generic alarm definition.
One solution you could try is to create a message parameter for your alarm as a string. Point the %P2 variable for your alarm to this parameter. At run time, read the Limit value of the alarm and concatenate that with the EU Units of the alarm to form a string like " m3 Limit XXXX m3", where XXXX is the limit value. You'd need to define a parameter for each alarm so you can capture the correct limit value in the string.
You'd also need to create a new alarm type for use with this formatted parameter. as you modify the module to create the new parameter, you can change the alarm type from High High Alarm to say Hi Hi Alarm EU. Otherwise you'd have to edit every module at once.
A compromise is to set %P2 to show the limit and the EU units. You would not have to change the Alarm Type, and as you added the new parameter, you'd change the alarm to point to it and progressively change the message to read 'High High Alarm Value 99 Limit 95 m3' where %P2 is "XXXX m3" rather than just the limit value.
Do you really need to show th units twice in the message?
I don't completely agree, Andre. The issue is either the units field is not resolved as a string in the controller, or that registration to the alarm subsystem doesn't include units (even as an integer) that could be resolved at the workstation during presentation.(i think you suggest this as an enhancement). Adding another string to every module just to hold the units is no small task for a running plant, and like a modules name, seems like it should be an easily referenceable value. Units matter to process engineers , operations, and scientists working with valuable product and dangerous chemicals even though to programmers and control engineers it may seem like just a label. Andre Dicaire <bounce-ADicaire@community.emerson.com> wrote:
DeltaV v12 has a new advanced alarm property, an alarm description. If text is provided, it replaces the module description when the alarm is presented in an alarm list or in alarm help. It is intended for use when individual alarms within a module have some unique information to convey to the operator. So EU could be part of the alarm description. I can see however that having a computed %Units string available for use in alarm messages would be a better solution and will definitely consider it in future product releases.
Yousef,
I think we are in agreement. My suggestion of adding a parameter in the modules was a workaround with today's system, not a suggestion for the enhancement's implemenation.
I think the Module Alarm itself should hold the information users need, and in the case of Units of the alarm parameter, DeltaV should automatically derive that from the host block's scaling parameter. As an enhancement, it should not require users to modify their existing module configurations. In my mind the enhancement would allow a user to simply add Units to their Alarm Messages as desired.
By the way, I am not recommending that Anca create all this overhead. She needs to decide if it is worth the effort. But to get the Units into the Alarm Message, it has to be placed in a %P variable that is passed to the workstations when the alarm is generated. Even if you dynamically derived the UNITS from the integer value with a look up function, it must get it into a %P parameter for display in the alarm message.
While we are at it, are there any other Alarm features you would like to see in DeltaV? How would they rank in importance to adding Units to the alarm data?
Thanks Andre. I think a more important feature regarding alarming is to allow for specification of significant digits and evaluation of alarms against the appropriately rounded value instead of the raw floating point value. The DECPT field in scaling params could be used implicitly for this purpose. Andre Dicaire <bounce-ADicaire@community.emerson.com> wrote:
Hi!
I am working together with Anca on this. The workaround we chose is to have a string parameter in each module which we configure to hold the engineering units.
One advantage is that the client does not want to see the current value in the alarm message, only the limit value. So I can make my HI and LO alarms in the form of: High Alarm Limit %P1 %P2, where %P1 is the value and %P2 is the unit.
In the case of HIHI and LOLO alarms the alarm message gets more complex, so we had to use a string parameter anyway in which we concatenate information. In that case, it is easy to add the EU as just another thing we concatenate into the string.
It would definitely be a nice new feature to have the EU easily referenced, so we do not have to create a new string parameter in each module.
Thank you for all the answers and ideas!
Istvan
Hello!
In response to your questions...
I already wrote in my last entry how we will solve this. And I have mentioned that in the case of the HIHI and LOLO alarms we need other additional information in the alarm message. Since this is the case, the only difficulty of adding the units to the alarm message was to translate them into strings (which we will do by simply configuring the units into a string parameter).
So, in our case, for a pharma client, we do not need the actual value of the measurement, it is enough to show only the limit value and then we know that it is above that limit... However, as the alarm deactivates we would like to get the alarm duration, maximum deviation from the limit value, and maximum (or in the case of LOLO, minimum) values of the measurement.
So, this is what we get in the Event Journal as alarm message when the alarm deactivates: "High High Alarm Max. value 99 l Max. deviation 4 l Duration 00:22:48h".
These are currently more important than getting the EU into the message. Maybe the alarm duration could be solved at historian level, but if you need the maximum deviation, you need to run a logic while the alarm is active, to check whether the current value is greater than the maximum until now.
I suppose this is not needed by a lot of clients, so I would not include this in DeltaV, but getting the EU easier is definitely something which would be great.