HART CHARMS problem causing MODBAD on AI and AO blocks

I am writing to find out if other people have experienced this issue. We currently have a DeltaV 12.3 installation and are running AMS Device Manager 12.5 trying to use HART CHARMs to manage HART devices. We have experienced several incidents where we had a module go to MODBAD because of a bad input or output on a HART CHARM (after it has been working for months or years) with no diagnosable cause (checking the HART device with AMS Manager works and the HART device will not show errors, connecting with a HART field communicator to the device will also not yield any alarms or reasons for the issue, changing the CHARM will not change the outcome, download of the CHARM or the dependent module will not change the MODBAD situation). When changing the HART input or output to a normal 4-20 mA input or output, everything will function like it should.

Does anybody have any insight as to what the cause for such a failure would be.

These issues have caused process shutdowns or downtimes in our plant and I would really like to continue to use the AMS Device Manager over CHARMs for commissioning and troubleshooting if possible, rather than changing all HART CHARMs to simple 4-20mA inputs or outputs.

Regards

Frank

5 Replies

  • For the MODBAD, can you please confirm if you are seeing this on analog signal (DST/FIELD_VAL_PCT) or diginal signal (for example, DST/HART_FIELD_VAL)?
  • First, I would recommend that you don't use HART variables for your control instead use the Field_Val_PCT for your control. If the HART signal(s) goes bad, it would not trip your plant. This uses the 4-20 mA signal and also go to DeltaV Explorer at the channel level, you can ignore some bad status that might be causing your block to go bad but allow you still use AMS.
    One thing I would check first to see if the Device is having communication issues in DeltaV Diagnotics and look at the device under the channel for "HART statics" there should be no comm errors. If there is, clear it and see if it increment overtime. If it still increment, use these troubleshoot suggested items below.

    There are these actions you need to think about when troubleshooting that Jonas Berge has put together that will help:
    The issues that develop over time preventing HART from working properly include:

    Cable shield grounded at device by somebody not knowing it shall not be connected at the device
    Inadvertent contact between shield and grounded metal objects due to moisture or dirt, or at device replacement
    Excessive loop resistance due to corroded terminals or added series device like an adapter
    Device replaced with a device which is not HART-enabled
    New source of noise
    Moisture in device compartment or field junction box
    Loose connections due to vibration
    HART signal attenuation due to increased capacitance in aging cable or stray capacitance
    Device replaced with a device which is not the correct HART protocol version
    Device replaced with a device which has not been configured correctly
    Additional master connected causing master conflict
    Shield damaged
    Shield continuity compromised
    Housing ground disconnected at device replacement or due to corrosion
    Field junction box ground poor connection due to corrosion
    When HART communication alarms start appearing, don’t just disable HART communication. Instead troubleshoot the communication to fix the problem. If HART communication is disabled, the benefits of HART are lost and only analog 4-20 mA remains.

    Hope this helps.
    Tinh
  • In reply to Tinh Phan:

    Agree with Tinh 4-20 mA preferred for control and alarms and such. Using HART for continuous upgrade requires "digital grade" installation such as correct cable shield connection, isolation, and grounding. The installation can degrade over time if care is not taken when replacing devices, due to water ingress, or other changes. There could be intermittent comms issues. You can check comms health from DeltaV diagnostics.

    Or

    If you spot comms errors, you may want to check if installation has been damaged over the years

    These stats may have been running since the system was commissioned so you may wish to reset these statistics, and then check back a few days later. 

    Stay safe,

    Jonas

  • In reply to Jonas Berge:

    Before we make blanket changes to the system on what parameter to use, the root cause of the issue should be better understood. Starting with Jonas information, verify the channels in question. If pulling and reinserting the CHARM or replacing the CHARM does not resolve the issue that does seem to indicate a field side problem. But if AMS DM communicates with the device over HART, using the same HART modem of the CHARM, that is curious.

    As Jonas indicates, these counters and their current value could be driven by events long past. You should reset these to get a better sense of the current state. Or you can observe the rate of change.

    Modifying the IO blocks to use the Field_Value_Percent will disassociate the IO block from the HART device XD_SCALE. This feature allows you to reset the device Scaling directly from DeltaV. If you do not really use this feature, then changing the channel parameter to the simple analog would be a good option.

    the other thing to consider is whether you have the latest version of Firmware on the CHARMS. Being that you are at v12, that may not be the case. you can verify the CHARM firmware version and compare that to the latest. Logging a call with the GSC, they can help you determine the difference in versions of CHARMS and if there is a known issue that might explain this behavior.

    Do any of these devices have Burst mode enabled? Burst mode is not supported with DeltaV. On earlier Firmware, it could cause the CHARM to stop receiving HART data. This was addressed in a later firmware so that if Enabled, the DeltaV CHARM continues to function, ignoring the burst messaging.

    So I guess, check if Burst mode is enabled and disable it if it is.

    Andre Dicaire

  • In reply to Andre Dicaire:

    We routinely have a problem like this with Fisher DLC instruments.