Versions Compared

Old Version 8

changes.mady.by.user Former user

Saved on

compared with

New Version 9

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Include Page
Master Channel
Master Channel

 

In the HART FieldUnit's Poll Table, every command must be included that is intended to be supported by the RediGate. But as with all other FieldUnit types, it is not required to scan all of those polls in real-time. For instance, a typical Poll Table is shown below that includes seven polls defined in the HART Command objects.

But Although the Poll Table might contain many Command Index entries, the Master Channel might be configured to poll only poll for the 3rd Poll Record (CMD 03 - Read PVs as floating point), as shown below. This allows the primary process variables to be read continuously for each of the configured HART devices.

Note that the a Scan Period of 0 milliseconds is used to indicate obtain the maximum HART scan rate, but the actual communication delays are determined by built-in timing in required by the HART protocol, which makes the effective scan rate about 2-3 polls per second. Any non-zero Scan Period will add additional poll delay beyond the timing required by the HART protocol.

Although in the example above the Master Channel is only scanning for HART CMD 03 continuously, the other polls in the HART FieldUnit's Poll Table may be requested on demand using the device's Command Register (see RediGate-HART-Master).

...

PropertiesValues
Command Register

The Command Register is an integer register in the HART FieldUnit RTDB which is used to request the RediGate to send a HART command on demand.

To force a command in this device's Poll Table to be executed on demand, write into the Command Register the Poll Record row number of the poll to request. Note that the Command Register is the Poll Record number, not the actual HART command number. It is therefore recommended to configure the Poll Table for similar HART devices to be in an identical order, to avoid confusion over which Command Register value to use.

After a command is operated by writing to the Command Register, the resulting value in the Command Register indicates what was the result of the previous command, which may be read and acted on by a host system or internal RediGate logic.

The result values that appear in the Command Register are:

  • 0xFF00 (65,280) – Command was successful
  • 0xFFxx – HART device returned a command-specific response, where 'xx' is the command-specific Response Code (1st byte of HART Status)
  • 0xFEyy – Command failed, where 'yy' is the RediGate response code (02=Timeout, 03=Bad Data, 04=Invalid command)
  • 0xFDFF (65,023) – A fatal error occurred.
Response Register

The Response Register is an integer register in the HART FieldUnit RTDB that will contain the two Command Status bytes included in each response from a HART device.

The least-significant byte (LSB) in the Response Register contains the Field Device Status (2nd byte of HART Status):

  • Bit 7 – Device Malfunction
  • Bit 6 – Configuration Changed
  • Bit 5 – Cold Start (power failure or device reset)
  • Bit 4 – More status available
  • Bit 3 – Loop current fixed (4-20 mA not responding to process variations)
  • Bit 2 – Loop current saturated
  • Bit 1 – Non-primary variable out of limits
  • Bit 0 – Primary variable out of limits

The next most-significant byte (MSB) in the Response Register contains the 1st byte of the HART Status. This is either a command-specific Response Code, or a communication or command response error.
If the high bit of the MSB is 0, the MSB indicates a command Response Code (see HART command documentation for a list of possible Response Codes for each command). Some common Response Codes are: 0 = No error, 0x20 (32) = Device busy, and 0x40 (64) = Command not implemented.
If the high bit of the MSB is 1, the MSB indicates an error, with the other bits designated as below:

  • Bit 7 – Always 1 for a communication error.
  • Bit 6 – Vertical parity error
  • Bit 5 – Overrun error
  • Bit 4 – Framing error
  • Bit 3 – Longitudinal parity error
  • Bit 2 – Reserved
  • Bit 1 – Buffer overflow
  • Bit 0 – Reserved
#Timeouts to Identify

Enter the number of communication timeouts before the RediGate will revert to an Identity command to identify the HART device again.

This should typically be a low number (default is 5). The polling logic for the HART master protocol is:

  1. Identify the HART device. If polling by Short Address (0 through 15), use HART command 0. If polling by Tag, use HART command 11 (configure the Unit Name to the 8-character device Tag and set the Unit Address >100 to poll by tag).
  2. The Identity command (0 or 11) does not need to be defined in a HART Command object or a Scan Table entry – it happens automatically. The Identity command will return a unique 5-byte address for devices with HART protocol revision 5 or greater, but no data will be stored into the RTDB.
  3. For HART devices with protocol revision 5 or higher, all subsequent commands will use the 5-byte address instead of the device's Short Address or Tag.
    (NOTE: this means that if the device's Short Address or Tag is changed during operation, the RediGate will continue polling it successfully, even though the device address/tag no longer matches the RediGate's configuration.)
  4. However, if the RediGate loses communication with the device after timing out a number of times (#Timeouts to Identity), the RediGate will return to step 1 and poll the HART device again with Short Address or Tag in order to identify it again.
  5. For HART devices with protocol revision 4 or lower, the Short Address is always used, and the #Timeouts to Identify is not applicable.
ReservedUnused property

...