Brief Introduction to HART protocol commands and languages

After introducing the HART protocol physical layer and the HART data link layer, we also elaborate on the HART service. Through these series of explanations, I believe everyone has a certain understanding of the HART Protocol application in the software platform. The last part is about the HART application layer specifications and related languages and commands.

HART Protocol application layer Specification

1HARTCommand

Common commands: All devices implement these commands. Command number range: 0 ~ 30;

Common behavior commands: Most devices support the implementation of these commands. Command number range: 32 ~ 127;

Dedicated transmitter commands: Only one or several devices support these commands. You can execute special commands to complete some special functions and data processing. The command number ranges from 128 ~ 255;

2. Data Format

①. Unsigned integer: used to represent the original number raw numbers), for example, "Last Installation Number ".

②. IEEE 754 floating point format:

The floating point value passed through the Protocol is based on the IEEE 754 single precision Floating Point Standard.

Data bytes

#0 #1 #2 #3

S eeeeeee e mmmmmmm mmmmmm MMMMMMMM

S-tail number symbol; 1 = negative

E-index. The difference from decimal number 127 is expressed in binary complement.

M-ending number; 23 digits lower, decimal part.

The value of the above floating point number is obtained by multiplying the zero-offset exponent power of 2 with the 24-digit ending number. The 24-digit ending number is composed of a hypothetical highest digit 1 followed by a decimal point and 23 digits of the ending number. S1.M X

③. ASCII data format:

This format can refer to any ASCII code table.

④. Compressed ASCII6-bit ASCII) data format:

This data format is unique in the HART protocol. The compressed ASCII is a subset of ASCII, which is generated by removing the two-digit height of each ASCII character. This allows four compressed ASCII characters to occupy space of three ASCII characters. The specific format is as follows:

Compressed ASCII Data byte #0 #1 #2...

ASCII Data byte #0 #1 #1 #2 #2 #3...

ASCII data bit 543210 54 3210 5432 10 543210...

From the HART character set, we can see that the HART Protocol cannot contain lowercase English letters.

⑤ Variable description:

The transmitter provides four variable output channels that can be accessed. Each transmitter variable corresponds to a code. The host computer sets different variable codes for each channel of the transmitter to obtain the corresponding variable values. The variable code table is provided by the manufacturer of the transmitter.

Device Description Language

With the development of the HART protocol, there are new obstacles for the developers of Main devices and on-site devices. The primary device developer must provide support for the emergence of new on-site devices. At the same time, the on-site device developer must develop corresponding interfaces for the number of Primary devices that are rapidly increasing.

Device Description Language (DDL) is a simple structured English language used to describe HART field devices. DDL aggregates all the information required for the operations on the master device and the on-site device. Currently, the information is stored in different places in different forms. The HART document describes some of the information (such as common commands, Common commands, and common tables ). The transmitter-specific documentation describes special device information (for example, deviations from Common commands, and support for common commands and special transmitter commands ). The CAD diagram provides the appearance and process of the handheld terminal, and even some information is described by the application of the handheld terminal. For example, the process of adjusting the D/A converter is defined according to the processing method of the handheld terminal. The DDL language combines all this information to provide a clear, unambiguous, and consistent description of the on-site device.

A developing handheld terminal will operate only on the device description and on-site equipment, rather than on-site equipment without the device description. This has very attractive advantages.

New field devices can be released without relying on the version of the handheld terminal. Once the device description of the field device exists, the description can be loaded into the handheld terminal, and then the field device can operate with it. On-site device developers no longer need to confirm the operation of the handheld terminal, but only need to check the device Description Language. Therefore, the close relationship between the current on-site devices and handheld terminal versions will no longer exist.

On-site equipment developers have great flexibility in introducing their products to the site and upgrading their users. The device description can reside in the field equipment, so the appropriate device description is always valid. The device description can be provided in the form of a module and can be introduced to a handheld terminal. You can use a floppy disk for upgrade, or you can use PC software to download it to a handheld terminal. The upgrade of a floppy disk can be completed by the user or the service center.

The DDL language will replace the special transmitter document and CAD line chart, so this will eliminate many previous document problems.

Since the price of DDL and Its Compiler is relatively high, manufacturers do not provide corresponding devices that support DDL. We do not recommend using or implementing the DDL support function, instead, the proprietary attributes of various devices are separated from the general attributes. The proprietary attributes are implemented using different dynamic link libraries.