in reply to: Message longer 256 bytes posted by Jeff on 11 January 2011 at 16:41:55.
I don't know of any special format for longer messages. Since the HART message must include the data byte length (including 2 for the status bytes) as a single byte quantity, I can't see any way to extend beyond 253 bytes of real data in the response.
If you only need a fixed number (up to 250 or so) of blocks to be readable, you could define each block as a separate device variable, then read each using command 9 or 33 (requesting only a single block). The host would have to know how many blocks to read, or I suppose it could give up when it came to a block of all zeros or NANs.
Otherwise, your new device-specific command could specify the block number to read (which could be a 2-byte integer if you like) in the command's data, with the response data containing the requested block. I don't think you would need two commands to do this, unless you want the field device to be in control of which block to send. Even then, you could include the block number as the first data byte(s) of the response to a single read command. (Tricky to deal with any missed responses due to communication errors, if the host can't specify the block number in a retry).
Be aware that a large data field badly impacts the overall responsiveness of a HART network - for example any burst mode device will be held up while the long message is being passed. Command 93 (Read Trend Data) is, I think, the longest standard command so far with 75 bytes of data.