in reply to: Hart Questions posted by Mo on 14 June 2002 at 15:59:58.
Some responses ...1) Data field length.
Until now (HART rev. 5), all universal and common practice commands have contained 25 bytes or less of data. That keeps the transaction speed reasonably good. The maximum possible data field is 253 bytes (allowing for the 2 bytes of status, still within the total limit of 255 to be represented by the 1-byte "byte count"). A few manufacturers have used device-specific commands with data up to this limit, typically for collecting large amounts of buffered data from a field device for diagnostics. You probably wouldn't want to use this long a message for regular real time data collection.
HART rev. 6 will bring a few slightly longer universal commands, to deal with a 32-byte tag. HART rev.6 also includes the block transfer scheme which appeared in rev. 5 but was not completely defined; this will allow data segments up to 255 bytes, but each device can impose a shorter limit if it wishes.
Of the existing commands, the master messages often contain quite a lot of data for configuring a field device, but apart from that, you are right to assume that the slave response messages usually contain more data (for example, reading four process variables in one message). You can check this out in the downloadable file www.romilly.co.uk/commands.doc (106kb, MS Word), which lists the universal and common-practice commands of HART rev. 5.
If you are designing a HART device (slave or master), you probably need to be able to handle the full 253 plus 2 bytes, either by accepting them all into a data buffer, or at least by counting the bytes and accumulating a checksum, since you should check the checksum, even if it's a command you don't understand. Or it might be a command you do understand, but which has been lengthened by additional bytes (which you can legally ignore) in a more recent spec.
2) Retries.No, there is nothing to provide automatic retries in the data link layer. Host (master) applications should make retries as appropriate. Two retries for a total of three attempts is usual, when collecting real-time data. Perhaps less, if you are only trying to identify devices connected in multidrop. Slaves don't even have to think about retries.
3) Extended response time.Up till now, the slave must respond within the allowed 256 ms. If it can't deal with the command, it could respond saying "busy". But that's not a good idea unless it's just a temporary situation, due to the slave doing some extended inner activity which cannot be interrupted. If a slave didn't reply at all, the master would probably do a retry (see 2 above) but you should not rely on this for satisfactory system operation - at the very least it throws out the scan timing.
I understand that HART rev. 6 will allow a properly-defined "delayed response" mechanism for use when a slave needs more time to reply properly. For field devices, it will only be allowed for "write" commands. For bridge devices running