Recent Control & Safety Systems Discussions
Similar Posts
How to access Hart signals using OPC?
exact installation location of Profibus gateway in order to transmit Hart signals to AMS
Acknowledge Alarms by a digital input signal
DCC Interlock state
My Interlock Not Working
Share

HART digital signals for control or interlocks?

Assuming the update rate is sufficient:

Is it supported to use HART digital signals for control?

Is it supported to use HART digital signals for interlocking?

Brian Hrankowsky

19 Replies

  • Mike Link
    It is supported for both applications. Watch out though, on redundant controllers if they switchover you lose hart for about 8 seconds (while the new controller (re)initialized the Hart modems).

    Recommended? it would really depend on the application. For control I don't have too many issues, on switchover or loss of signal you would shed to Manual (you probably want a module alarm to detect this). For interlocks I would want to know a lot more about the application and have some good failure handling logic (is it better to trip due to bad signal or stay running? should there be a delay on that? etc.)
  • John Rezabek

    When you say "assuming the update rate is sufficient" you may also want to ponder, "is the update rate always the same"? So if a technician calls up a tag on AMS and the system labors to populate all the parameters, does the variable you're aiming to use continue to update at the same frequency? What if someone connects a handheld configurator / calibrator? Will your control loop or interlock tolerate a change in latency?
    Wired HART is also a relatively small amplitude signal, so the demands on your "physical layer" to be properly shielded / grounded will be greater than the purely 4-20 mA applications.

    If you didn't see it in the related posts Jonas Berge has written a comprehensive guide for using HART on LinkedIn . . .

  • Andre Dicaire

    In reply to Mike Link:

    In terms of applications, the factory does not "support" applications. that is, the application is something that you have to support. The factory supports the product functionality. Generally, the factory recommends against using HART variables for control. It is up to you to determine if the HART Variables are suitable for use in the application.

    Is in most programming, it is the error handling, or abnormal conditions that are the more difficult challenges. If the use of HART variables bring benefit and do not introduce unacceptable risk, you are free to implement them in your strategy. Only you can determine what those risks are and how to mitigate them.

    Andre Dicaire

  • Brian Hrankowsky

    In reply to John Rezabek:

    The link doesn't seem to want to render well on my work provided laptop (pictures won't show up). Is there any way to estimate the update rate impact from a call up in AMS?
  • Andre Dicaire

    In reply to Brian Hrankowsky:

    I don't think so. The AMS DM is typically manually initiated, though the Quick Check snap on could run automated queries. Connection to the same device will impact based on what data is being called, and various devices have different features with more data exchange. The DeltaV HART value polling is interspersed with the other HART calls. I've never tried to gauge the impact of active AMS DM screens on the HART channel poll for variables. I just expect that there will be an influence, like John R. mentions above.

    There is also an overall bandwidth limit on HART communication in the HART AI and AO cards as these share a common HART modem between the channels. On CHARM IO, each CHARM has a dedicated HART modem, but HART commands initiate in the CHARM Card, and to avoid disrupting the primary IO polling, the HART throughput is limited overall. The more HART enabled CHARMS, the longer updates take, but still much faster than the HART AI and AO cards.

    If you are concerned on a given device, you should set up a test to see what effects you see. But be aware that you need to have multiple channels actively communicating HART data to reflect a real world scenario. Having one channel on a Card or CIOC with HART would give you best performance, not necessarily real world. If ten second updates work for your application, you should be good. If you are thinking 2 or 3 seconds consistently, that might not be attainable.

    Andre Dicaire

  • Brian Hrankowsky

    In reply to Andre Dicaire:

    Hi Andre,

    I am specifically looking at CHARMS and HART. There are a couple points you made that have me a bit confused:
    1) since each CHARM has its own modem, why would more HART enabled CHARMS on a CIOC decrease HART update rates?
    2) the listed specifications for HART Data Update Rates for CHARMS is 500 ms. But you're indicating 2-3 seconds is optimistic. Why the difference?

    Thanks in advance,
    Brian
  • Andre Dicaire

    In reply to Brian Hrankowsky:

    my understanding is the CIOC manages the HART call to each CHARM and pulls the data up to pass to the controller. Priority is given to the primary signal for control and HART Data is retrieved with remaining bandwidth. so having 96 HART channels can take a bit longer than one HART channel.

    As for the 500ms update, that simply is not possible. The HART call for variables is initiated by the CIOC, goes out to the CHARM, then to the transmitter and the response itself takes about 580ms alone over the wire. I've observed updates at 1.5 to 2 seconds.

    A triloop device that uses Burst mode will see HART values about every 600ms. it can depend on what the Burst call setting is.

    Andre Dicaire

  • Brian Hrankowsky

    In reply to Andre Dicaire:

    Hi Andre,

    I put a call in to the GSC at the same time as starting this thread. They confirmed much of what you all have said and indicated there is a Incident Report about the CHARMs HART update rate documentation. the website is still incorrect (they'll fix it soon I am sure).

    One item they were different on:
    Product Engineering stated that the update rate with CHARMs is not dependent on the number of CHARMS IO cards on a CIOC. Maybe some more digging is worth it here?

    Thank you very much for answering so many of our user questions!
  • js

    In reply to Brian Hrankowsky:

    Appreciate the conversation, the questions that Brian raised were in my mind also as i was exploring the option of using the HART_PV digital HART data from a Vega radar device. I too went with the 500ms updates that were mentioned on the website and thought that would be good for level control module with execution of 2sec. The intent was to avoid having to re-calibrate the mA loop which we have found to have drifted sometimes resulting in deviation between local and deltav reading.
    Seems like pulling HART digital would only provide an update rate of approx 1.5-2 sec ? right ? that may still work but seems like even that is not consistent and can vary for actions like AMS connecting to device ?
    Also do we have Burst mode capabilities for HART CHARMs?
    Any other suggestions to be able to use HART digital and avoid the re-calibration of loops ?

    Thanks
    jas
  • John Rezabek

    In reply to js:

    From what I've read in Jonas Berge's guide "burst mode" only applies to WirelessHART? 

    "The triggered burst mode and event notification (sometimes referred to as report by exception) functions are intended for WirelessHART not for 4-20 mA/HART"

    "Do not use burst communication for devices connected to a control system or multiplexer because the burst communication will cause diagnostics and auxiliary variable monitoring etc. to slow down. Burst communication may also cause many communication error alarms in the IDM software."

    I've heard of configuring some function blocks to compare the HART PV to the mA loop, maybe generating a maintenance alert . . .

    Radiometric applications are typically averaging over a few seconds anyhow - maybe you are fine with 5-10 second updates. I remember a paper presentation by Terry Blevins where he explored the tolerance of loops for variable latency - mostly with respect to wireless. But when your technician is pulling a signature from the transmitter it might have some affect.

    I would tend to favor the analog loop since it updates multiple times a second. Not sure about CHARMs but I think the M-series AI cards are somewhere around 20x a second.

    Cheers,

    John

  • Andre Dicaire

    In reply to John Rezabek:

    Concerning Burst Mode, DeltaV does not support it, and ignores all Burst mode transmissions. Although the DeltaV channel might tolerate the presence of Burst mode traffic, this traffic will interfere with normal polling done by DeltaV. DeltaV has to wait for a burst message to complete before it can send its HART command. The Transmitter has to listen for additional commands before sending a new burst. So Burst mode should not prevent communication to DeltaV, but it would negatively impact the polling. So with DeltaV Burst mode is to be disabled on transmitters.

    Burst mode has been around long before WirelessHART and has been used with wired transmitters by Triloop devices that strip out the Hart variables and reproduce them on dedicated 4-20 signals that are then wired to the control system. In Burst mode, the transmitter is told what data structure to send and it sends it continuously. Typically, the 4 variables and their status. On the 1200 baud HART communication it takes over 500 ms to send that data. Since the device doesn't wait to be asked for data, it sends this continuously, with a brief pause between so it can listen for any additional HART commands. When left alone you get data updates around every 600 ms or maybe 800 ms. It simply cannot be faster than the baud rate allows.

    As for the HART update rate on CHARMs not being dependent on the number of HART enabled CHARMS, I don't know. What I do know is we observed about a 1.5 second update frequency on a transmitter on our test system which has 6 HART devices. At site, the same transmitter showed about 2.5 seconds but with many more HART devices connected. We never received an explanation for why one was different than the other and left it as somehow related to the different number of devices. Our CIOC is at 100 ms update rate. I don't recall if the Site unit was at the default 250 ms. Maybe it's based on that setting. Maybe you can ask the GSC in relation to your CTS call what is the expected update rate of HART data and what configuration affects this rate.

    Andre Dicaire

  • Andre Dicaire

    In reply to js:

    jas, maybe a solution is to use the 4-20 mA signal for control, but correct it based on the HART variable. That way you get the response to change from the 4-20 mA value and the accuracy from the HART variable. calculate a bias value based on the HART value and apply this to the 4-20mA signal. If you lose HART communication, the bias holds and the loop continues to function on the 4-20 mA signal. This will take all jitter due to HART update rates out of the equation but give you the most accurate control signal.

    Andre Dicaire

  • js

    In reply to Andre Dicaire:

    Appreciate it Andre, thats may be good approach !
    Being in regulated environement mostly limits some of the 'playing' that can be done.
    I really would like to know what the performance parameters are for a CIOC with multiple HART CHARM I/O architecture. Hoping someone has that good piece of info. Seems like i may have to open up a case with GSC to understand this better.
  • Andre Dicaire

    In reply to js:

    Having predictable behavior is often more important. If there are configuration choices that affect HART update rates, those would be good to know. Asking the GSC would be the right place to start.

    Andre Dicaire

  • Jonas Berge

    In reply to Andre Dicaire:

    And it is also a matter of the field device, not just the control system. Some HART instruments may respond faster or slower than others.

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.