• Not Answered

Analog Input - HART_FIELD_VAL "Device Units Invalid" Error

On analog inputs (CHARMS), I am trying to use the HART_FIELD_VAL as the DST parameter.  I am getting Bad PV errors and in diagnostics the Status on the Channel says "Device Units Invalid".

I have HART enabled on the CHARM and have autosensed for HART device.  All of that looks good.

How do I reconcile the units mismatch and eliminate this error?

Greg Bayne

• 15 Nov 2023 1:13 PM
• Cancel

10 Replies

• Matt Forbis

  

  • 15 Nov 2023 1:54 PM

  When using HART_FIELD_VAL, it uses HART to reconcile the XD units and scales after downloading the module. If you have a disagreement between units (for example, deg F and °F are not the same unit), and the device cannot reconcile the difference, it will give this error. If you have a Trex or AMS, you could look at the device to see what the units in the device are and configure the XD_SCALE to be the exact same.
  
  If I recall correctly, there are two special units 'no units' and ' ' (That's a single space) that can be configured and they will always read the units from the device into DeltaV and should eliminate this error as well.

  • Cancel
• Greg Bayne

  

  • 15 Nov 2023 2:49 PM

  In reply to Matt Forbis:

  Thanks for that. I believe I have used that method in the distant past. Should the L_TYPE be set to Direct?

  • Cancel
• Matt Forbis

  

  • 15 Nov 2023 3:27 PM

  In reply to Greg Bayne:

  If using HART_FIELD_VAL and your Instrument is configured to the same range and units as what the control module desires, then yes, the L_TYPE is direct. If you were wanting to rescale or present in a different unit (for example, inH20 for a tank level but want to show in %), then you can still use indirect and the function block will scale linearly.

  • Cancel
• Tinh Phan

  

  • 15 Nov 2023 3:44 PM

  In reply to Matt Forbis:

  Just to add on to what Matt have mentioned. You will need to do two module download. When you download it the second time, it will read the device scale and unit and display it and want a confirmation.

  • Cancel
• Greg Bayne

  

  • 16 Nov 2023 7:54 PM

  The help and suggestions worked great. Thanks for the support!

  • Cancel
• MPHymel

  

  • 19 Oct 2024 4:25 PM

  In reply to Greg Bayne:

  Along these same lines, I am using FIELD_VAL_PCT and Indirect and get the same problem. Shouldn't the XD_SCALE units not matter in this case? Tried setting XD_SCALE to " " and still get that problem.

  • Cancel
• Andre Dicaire

  

  • 21 Oct 2024 5:47 PM

  In reply to MPHymel:

  When you say the "same problem", do you mean you are seeing "Device Units Invalid", but are using Field_Val_Pct?
  
  The L_TYPE Indirect forces the AI block to calculate the PV value using the FIELDA_VAL and the OUT_SCALE. FIELD_VAL is a % value of the incoming IO reference. When you use FIELD_VAL_PCT, the value goes directly into FIELD_VAL, and gets scaled by OUT_SCALE. With HART_FIELD_VAL, the IO channel provides the scaled value based on XD_SCALE, which scales the 4-20 mA signal to EU Value at the channel. The AI block receives this value and converts it to % in FIELD_VAL. The PV value, is then set based on L_TYPE of indirect or Direct. As Matt said, if DIRECT, then the hart value from the channel is pushed to the PV. The OUT_SCALE becomes informational and can represent the operating range that is narrower than the full range of the transmitter. If INDIRECT is used, the FIELD_VAL is scaled so you can view the signal in different units, like PSI to KPA or Fahrenheit to Celsius.
  
  I also recall an issue that some transmitters did not support certain variations of Inches of H2O that were temperature based. If you were setting XD_SCALE to something the transmitter could not use, you would get an error. I would suggest setting XD_SCALE to 0-100 %, if your input channel is 4-20 mA using Field_Val_Percent. and Indirect on L_Type. But I'm not sure why the AI cares about XD_SCALE if using FIELD_VAL_PCT.

  Andre Dicaire

  • Cancel
• MPHymel

  

  • 22 Oct 2024 4:21 PM

  In reply to Andre Dicaire:

  Andre, thanks for the reply. Yes, I am having the same problem, but following your post, I realized that while we are using FIELD_VAL_PCT for the primary indication (steam pressure), we have an ancillary module using the HART SV for capsule temperature. I only discovered this in researching data to reply to your post more thoroughly, which led me to discover this.
  
  Strangely, I suspected the "°F" vs "degF" issue the instant I realized this point existed, but was surprised to find that the units in the module and in AMS match, so now I am doubly confused.
  
  There were several DSTs that were showing this error in Diagnose, and I want to look at each to see, if in all cases we have secondary modules looking at HART variables, and if so do any of those have unit mismatches. It may be a few days before I can look deeper.

  • Cancel
• Andre Dicaire

  

  • 22 Oct 2024 4:52 PM

  In reply to MPHymel:

  Are you using an AI block to read the SV values? I would read these with an external reference. You can wire this to an ALM block to give you IN_SCALE to provide context. No need for the extra features of the AI block. Although I understand the desire to just use an AI block so all the display references and faceplates and such are the same.
  
  As you look into this, can you remove one of these SV references to confirm it is actually causing the issue? That way you know exactly what the source is and that makes it way easier to solve. The issue with mismatched ranges has been between DeltaV and the Device, not AMS. If DeltaV XD scale has Units not supported by the device, it can't accept DeltaV's requested scaling. Secondary variable is a HART value only and is not scaled. You would use L_Type DIRECT in an AI, or just read the value with external reference. But I'm speculating.

  Andre Dicaire

  • Cancel
• MPHymel

  

  • 22 Oct 2024 7:29 PM

  In reply to Andre Dicaire:

  Correct the ref to AMS was me checking to see what units were in use for that parameter in the transmitter via AMS, and they were degF instead of C.
  Yes AI block is being used, actually using a PCSD AI class for both.
  Confirmed that primary module is Field_Val_PCT, indirect, XD_SCALE 0-100%
  Modified the secondary point to look at Field_Val_PCT, indirect, XD_SCALE 0-100% and still have the error
  
  Tried setting both XD_SCALE units, one as " " and the other as "no units", downloaded, still have the error
  Tried downloading changed setup data to the controller, and the CIOC and still have the error
  Tried downloading the charm, still have the error.
  Returned both XD_SCALE units to %, downloaded and still have, still have the error. Even tried rescanning the CIOC in diagnose.
  I set the capsule temperature module back to HART_SV, indirect and still the error exists.
  
  I went into AMS and set the temperature units in the transmitter to "degC" ( there is no "°C" option), and in the XD_SCALE set the same range limits, but chose "°C", (as there is no "degC" option in module configuration). I wonder if this is the root of the problem.
  
  Now I did get a reading for the capsule in spite of the error in Diagnose. Just the CHARM is reporting BAD and that is what prompted me to look into it.
  
  Cool thing is now the Field_Val status in the module is GoodNonCascade, whereas before it was bad. The CHARM status is still bad with the same ol' "Device Units Invalid". XD_SCALE probably wants to be "°C", wonder if the problem is the transmitter has it as "degC"

  • Cancel