If the troubleshooting guide does not provide the answers you need, please file a support ticket and attach all relevant log files and screenshots to describe your issue.  

Include information such as:

  • Operating system and version
  • Test tool version
  • Your full name and company email address
  • Failure Point number(s)
  • Failure message(s)
  • Log files
  • Screen shots of relevant information
  • Steps to reproduce the failure

Please include your license number or service tag number for Product Service Program (PSP) status verification.

 

TABLE OF CONTENTS


HART Modems

What HART modems can be used with the HART Test System?  


Please note that many companies manufacturer RS-232 modems but only the HART-Registered modems are guaranteed to have passed the HART Protocol standards and will operate correctly with our tools. USB or other types of modems will not operate with the HART Test System correctly and are not supported. 


We do not make recommendations about specific products to buy. A list of modems can be found on the Product Catalog. Please contact the vendor about purchasing their products displayed in the Product Catalog. 

 

Replacement parts for the HART Physical Layer Test Kit are available on the tool order form (See HART Physical Layer Test Interface). Note that the modem supplied within the HART Physical Layer Test Kit is augmented with a potentiometer built to our specifications. This modem may be used with the HART Test System if used at the highest potentiometer setting, however it is recommended that this be used only with HSniffer (serial port 1). A commercially available HART-Registered RS-232 modem is required for the test application (serial port 0). See designation of the HART Test System serial ports.


How do I know if my HART modem is communicating?

If you are using a registered HART modem, it should communicate with a HART device that has passed the physical layer tests.


The modem functionality can be verified by running some diagnostics using an installed test or by sending single commands to the device from the HART Test System and observing the device response.


HSniffer

HSniffer does not generate .OUT files 


There could be several reasons for .OUT file not being created by the HSniffer. First, make sure that the two RS-232 HART modems for the HART Master and HSniffer are connected snugly on their designated serial ports and there are no loose connections between the modems and the DUT. Then perform the following steps to help eliminate possible user oversights and pinpoint the cause of the problem -


Open a terminal on the HART Test System and start a DLL test (e.g., type "DLL005" without quotes on the command line and press <Enter> to run this short DLL test). Then take the appropriate action as stated below based on the behavior you see in the following possible scenarios:


1. DLL Test Messages seen on the terminal

If, a few seconds after invoking the DLL test, the request and response bytes between the DLL test commands and the DUT are seen on the terminal from which the DLL test was invoked, it means the test is running. At this time, if nothing is seen in the HSniffer terminal window automatically opened by the DLL test, no .OUT file will be created. Verify that both modems are functioning correctly by swapping them, i.e., connect the modem from serial port 0 to serial port 1 and vice versa. Then run DLL005 again as specified above. 

  • If the request and response bytes between the test and the DUT are seen on the DLL test terminal, but nothing is seen again in the HSniffer window opened by the DLL test, no .OUT file will be created. In this case, the serial port designated for the HSniffer is most likely defective. Please open a Support Ticket (select Product Support, HART Test System) for further assistance. Include the Serial Number or Service Tag number of your HART Test System in your ticket for faster resolution. You may be entitled to an RMA if the Test System is enrolled in the Product Service Program.
  • If the request and response bytes between the test and the DUT are not seen on the DLL test terminal, the test is not running, so no .OUT file will be created by HSniffer. In this case, the RS-232 modem currently connected to the HART Master serial port is most likely defective (or loose). The modem functionality can be verified by sending single commands to the device and seeing if the device responds instead of running the whole test.


2. DLL Test Messages not seen on the terminal

If, a few seconds after invoking the DLL test, the request and response bytes between the DLL test commands and the DUT are not seen on the terminal from which the DLL test was invoked, it indicates that the test is not running. No .OUT file will be created by HSniffer in this situation. Verify that both modems are functioning correctly by swapping them, i.e., connect the modem from serial port 0 to serial port 1 and vice versa. Then run DLL005 again as specified above.

  • If the request and response bytes between the test and the DUT are seen on the DLL test terminal now, but nothing is seen in the HSniffer window opened by the DLL test, no .OUT file will be created. In this case, the RS-232 modem currently connected to the HSniffer serial port is most likely defective. The modem functionality can be verified by sending single commands to the device instead of running the whole test and seeing if the device responds .
  • If the request and response bytes between the test and the DUT are still not seen on the DLL test terminal, the test is not running, so no .OUT file will be created by HSniffer. In this case, the device is most probably not responding to the short frame Command 0 that identifies the device before sending any test commands. If the DUT has passed the physical layer tests, check the device response by sending single commands to the device instead of running the whole test.


Please note that only one instance of the HART Master can be running on the HART Test System at a time.


What happened to ANALYS? 

HSniffer replaced ANALYS in HART Test System version 3.0.  HSniffer runs on the same unit as the test system.


Common Test Case Failures

How does test DLL039A count failed messages?

If the device does not respond to a message it is considered an error. If the device does not respond to a retry it is another error. If the device answers the next retry the error count would remain at two. If no more messages are missed the final result would be two errors. Any more missed messages add to the error count.


During the test the device may miss no more than 20 messages in total. If the device misses four messages in a row (one STX plus three retries) the test fails.


Why do test cases DLL027 and DLL028 fail? 

These test cases are likely failed because a device is monitoring RT2 while in the RCV_MSG state machine. 


Remember that as soon as RT2 expires (and you are no longer in RCV_MSG), you should burst. See figures 15 and 17 in the Data Link Layer specification for more details. 



DLL028A Timing Error

Anomalous behavior

When a partial command is present on the bus the HART Test System improperly discards the first 2 preambles of the following packet. When this happens, the reported time between reported sequential complete packets is approximately 20 ms longer than it should be.

Consequence

False failures in DLL028A may be reported. Instances of Non-compliant time must be manually inspected and the idle-time reported shall be decreased by 20ms. Put another way. Any idle-time less than 325 ms shall be considered as PASS. any idle-time greater than 325 ms is a FAIL.

Corrective Procedure

From the HART Test System "bash" command line type the following commands

> conv -t -d -f BA00028A.OUT > BA00028A.OUT.tdf.txt
> egrep -i -n "idle time" BA00028A.OUT.tdf.txt | sort +1 |tail -100 

example data produced:

6346:idle time between frames = 311.6 ms, length of this frame = 329.6 ms
38242:idle time between frames = 311.6 ms, length of this frame = 330.0 ms
16092:idle time between frames = 312.0 ms, length of this frame = 329.6 ms
26281:idle time between frames = 312.0 ms, length of this frame = 329.6 ms
36913:idle time between frames = 312.0 ms, length of this frame = 329.6 ms
43558:idle time between frames = 312.4 ms, length of this frame = 329.2 ms
3688:idle time between frames = 312.4 ms, length of this frame = 329.6 ms
5460:idle time between frames = 312.4 ms, length of this frame = 329.6 ms
22737:idle time between frames = 312.9 ms, length of this frame = 329.2 ms
35584:idle time between frames = 313.7 ms, length of this frame = 329.6 ms
21:idle time between frames = 339.9 ms, length of this frame = 109.9 ms
10:idle time between frames = 3463.9 ms, length of this frame = 164.8 ms

There are request/response traffic at the beginning of the test that provisions the DUT. Consequently idle-time before line 100 of the data file shall be ignored.

Given that, the idle-times produced above shall be inspected and any > 325 ms shall be a FAIL.

Guide for DLL010 and DLL011

The test automation for DLL010 and DLL011 use the Token Passing Data Link Test Specification as a guide only. The implementation varies from the Test Specifications due to Linux limitation. The test automation are functionally equivalent and meet the intent of the Test specifications. 

Field Devices must successfully complete the test automation to be registered.

DLL010:



Call IdentifyDevice

FOR 0 to 25

Send Command17 with Parity Error in Data Field

IF (COMMUNICATIONS_ERROR != "Parity Error")
Fail 717

Send Command 3 with Parity Error in Address Field

IF (COMMUNICATIONS_ERROR != "No Response")
Fail 713

Send Command 1 with no error

if(number of ACKs < 25)
Fail 719

END FOR


DLL011:



Call IdentifyDevice

FOR 0 to 25

Send Short Frame Command 0 with Framing Error in the Address Field

IF (COMMUNICATIONS_ERROR != "No Response")
Fail 723

Send Command 17 with Framing Error in the Data Field

IF (COMMUNICATIONS_ERROR != "Framing Error")
Fail 727

END FOR



My device accepts any floating-point number for RANGE values, does it pass all test cases? 

This is why the test specification says to contact us if you exceed those values. 


It is reasonable to expect certain devices (such as flow) may support the complete range of floating point values. If you are certain this is implemented correctly, your sensor must be able to handle the range allowed in the device. You will need to submit a Change Request on why this range is valid for your device when you submit the device. The CR is necessary since your device will not reject any upper or lower range value.


Reference the approved CR number in your product registration submission.



Why is CAL073 failing? 

The Test Specification does not mention the setup required for the device before executing the test. Please disarm the device before running CAL073. 



UAL or CAL Test Case Starts But Does Not Send Any Commands

Some end users have reported the following scenario: 


They invoke a Universal or Common Practice test case (ex: UAL000) and the test case reports a start time along with the connection but then seems to hang up. It may take several minutes before the user sees a failure point message indicating that the test system cannot connect to the device.


When an Application Layer test case is executed, the hipserver and connection app is launched before the test case starts running. When the reported scenario occurs, it is because these two programs (hipserver and connection app) have unexpectedly terminated or closed. This is rare but when it occurs, it is due to the server window being closed by the user or a zombie process running in the background that prevents the server and communication app from running.

 

The hipserver and connected app would also terminate if a device is not connected to the HTS (HART Test System). An Application Layer test cannot run unless the hipserver and app are running.


The two methods to fix this situation are described below. First, make sure that you have connected a registered RS-232 HART modem between the HTS serial port designated for the HART Master and your device. Then follow these steps -


Method 1:

  1. Open a Linux terminal.
  2. Type the following command: terminateserver
  3. Rerun the test case.


If this does not fix the problem, continue to Method 2.



Method 2:

  1. Reboot the HTS.
  2. After the system has rebooted and you have logged back in, open a Linux terminal.
  3. Rerun the test case.


If this does not fix the problem, make sure that you are able to communicate with your device by sending a single HART command. If the device cannot be identified, nothing else will work. Make sure you quit from htest after sending single HART commands before you run any other tests.


Please make sure that only one instance of the HART Master is running on the HTS at a time. If a test is hung, abort it before trying to send a single HART command.



What is the correct Command 9 Response for UAL011A?  

If your device does not support Dynamic Variables or Device Variables, then the Universal Command Specification (HCF_SPEC-127 Rev 7.1) Section 6.10 states Command 9 MUST respond accordingly:


"When a Dynamic or Device Variable requested is not supported in the Field Device, then the corresponding 

Value must be set to "0x7F, 0xA0, 0x00, 0x00" (this is HART NaN); 

the Status must be set to 0x30, (i.e., Status = "Bad" and Limit = "Constant"); 

the Units Code must be set to "250" Not Used; 

and the Device Variable Classification set to "0", Not Yet Classified."


The HART Test System has improved the automated testing of this clause.  Developers may encounter the following failure points in UAL011A: 3210, 3220, 3226, 3227.


See the latest Universal Command Specification on our website.


Other Questions

Are there missing test cases in the HART Test System? 

Currently, test automation does not exist for CAL001, CAL060, CAL062, CAL063, CAL064, CAL065, CAL066, CAL067, CAL068, CAL069, CAL070, CAL078, CAL079, CAL080, CAL091, CAL101, CAL115, CAL512, CAL518. 


Members are encouraged to write their own test cases to verify the functionality in these tests. The procedure for the above test cases is described in the Slave Common Practice Command Test Specification (HCF_TEST-004). If you do not have the HART Protocol Specification documents, you can request them here.


For the purpose of device registration, logs are only required for tests for which test automation exists on the HART Test System.


Can I send a single HART command to my device? 

Yes.


HART commands can be sent to a HART device via htest, which is a customized CINT interpreter. It is a convenient and useful way to make sure that your hardware components are functional and connected properly, and you are able to communicate with the device successfully. This is a powerful tool installed on the HART Test System and allows you to check the response of the HART device to various HART commands before you start running full fledged tests. 


To send a command from the HART Test System to your device, connect a registered RS-232 HART modem between the serial port designated for the HART Master and the device. Then follow these steps -


1. start htest.

2. identify the device from within htest.

3. build the desired command message.

4. send the command message to the device, receive the response and display the request and response bytes.



1. To start htest, open a terminal on the HART Test System, type "htest" (without quotes) on the command line and press <Enter>. This will start the interpreter which will allow single HART commands to be sent to the device when composed with the proper syntax. For more information about htest command syntax and the API functions available for use with htest, refer to PS20017 HTEST Application Manual under User Guides.


2. Once htest starts, you will see the htest prompt on the terminal as follows -

htest>

 

Identify the connected device via the ident_device() function from within htest as follows -

htest> {ident_device(0);}


Any value between 0-9 can be used for the queue number as an argument for ident_device(). The same queue value must be used for all other functions once it is used in ident_device(). The ident_device() function prints the polling address of the device by sending the short frame Command 0 to the device. No other HART command can be sent to the device via htest unless ident_device() is successful. An unsuccessful command returns '-1'.


3. To build a message to send a HART command, say, long frame Command 0, use the bld_msg() function as follows -

htest> {bld_msg(0, 0, 0, "");}


See PS20017 HTEST Application Manual under User Guides for meaning of the various parameters.


4. To send the command last built via the bld_msg() function,  and see the response received, use the send_recv_msg() function as follows -

htest> {send_recv_msg(0);}


This would display the command bytes sent to the device and the response bytes received (if any). Once the device is identified via step 2, steps 3 and 4 can be repeated any number of times for various commands. Step 2 does not need to be repeated if the modem connection has not been broken and htest session not ended.


To quit htest and return to the command line shell prompt on the terminal, type q on the htest prompt as follows -

htest> q


To see the FSK bus traffic while sending single commands, connect a registered RS-232 HART modem between the serial port designated for the HSniffer and the device. Then, open another terminal and type "hsniffer" (without quotes) on the command line and press <Enter>. This will open a new terminal window and start hsniffer in it. HSniffer displays the bus traffic during the execution of short Command 0, which cannot be seen in the htest terminal. That is an additional way to verify that data is going to the DUT in case ident_device() fails. The HSniffer window can be closed by typing <Ctrl-C> in it.


Please note that only one instance of the HART Master can be running on a Test System at a time.



Can the Test System serial ports be used interchangeably? 

No, the serial ports on the HART Test System are designated for specific purposes and cannot be used interchangeably.


Serial port 0 is used for communication between the HART Master and the device via a registered RS-232 HART modem, and Serial port 1 is used by HSniffer to capture data on the FSK bus via a registered RS-232 HART modem when the HART Master and the device are communicating.


On Test Systems shipped after August 2015: 

- Serial port 0 (for HART Master) is the serial port labeled RS232-0.

- Serial port 1 (for HSniffer) is the serial port labeled RS232-1.


On Test Systems shipped earlier:

- Serial port 0 (for HART Master) is the serial port labeled RS232.

- Serial port 1 (for HSniffer) is the serial port with no label.


Without a registered RS-232 HART modem connected between Serial port 0 and the device, there can be no successful communication between the HART Master and the device.



Can I run two tests from two different terminals at the same time?

No.


Only one instance of the HART Master can be running (via htest or any DLL test or Application Layer test) at a time on the HART Test System. If htest or any DLL test or Application Layer test is running from one linux terminal, another CAL/DLL/UAL test or htest cannot be executed from another terminal.


Before starting any test or invoking htest, make sure that the HART Master is not running in another terminal that is minimized, hidden or forgotten. If you are not sure whether multiple copies of the HART Master are running, reboot the HART Test System for a clean start and and then start your testing.


Please note that TDMA layer tests (TML) can also not be run on a wirelessHART device from a terminal if any DLL test, Application Layer test or htest is running on the HART Test System from another terminal. Further, if System Level Tests (SLTs) are being run on a WirelesssHART device from a Windows PC, no other tests should be run on the same device at the same time from a Test System.


What happens to Device Specific Commands during testing? 

HART Test System

Device specific commands are ignored and will not affect the outcome of the test. It is up to the manufacturer to verify the correct operation of each command.


FDI Device Package IDE

Device specific commands must follow the HART Protocol Specifications for structurrules, refer to FCG TS20099 section 7.2 Command Requirements.



Can the output files correlate to error messages?

The log files generated from Post Processing can include complete logging information by using the –c and –l command line options. For instance: ppp000xxx –l –c –iBA000xxx.out –oRES000xxx.txt


What Commands are used for Event Notify?

Event notification requires, and is built upon, Burst Mode operation. If Burst Mode is supported then all commands for Event Notify should be supported.


Besides Burst Commands 103~105 and 107~109, the following commands must be implemented for Event Notification:

  • Command 115 Determine the configuration of the Event Notification
  • Command 116 Selects the bits that can trigger an Event Notification
  • Command 117 Controls the timing of Event Notifications
  • Command 118 Enable or Disable Event Notification
  • Command 119 Acknowledge the Event Notification


For more information, please refer HART_Spec-151 Section 6.10. 


DLL028: How do I Calculate BACK-BACK Time?

To calculate BACK-BACK time the test records the time (in ticks) when the last byte (the check byte) was received in the first BACK (call that BACK1).

 

Then the test records the time when the first byte (the preamble byte) was received in the second BACK (call that BACK2).


The test then performs the following calculation BACK2 - BACK1 == TotalTime. If the TotalTime (the BACK - BACK Time) is greater than RT1, set to 711 ticks, failure point 841 is issued.


To view all the HART packet timings, process the .OUT file with conv tool and record all of the data to a text file. This will aid you with debugging this test case. Documentation on conv can be found in the HART Device Testing Tools User Guide.


Known Issues and Possible Workarounds

Where can I find a list of known issues and workarounds for my version of the HART Test System?

The Change Log for the releases of the HART Test System include a list of known issues and workarounds. Please find the latest released change log in support here or visit the change log archives here. 


General System Questions

How do I take a screenshot on the HART Test System?

To take a screenshot on the HART Test System, click on the "Dash Home" white circular icon on the top of the launcher along the left edge of your Desktop which has various icons. It will open a search field where you can type text. Type "screenshot" in it (without quotes). You will see a camera show up on the screen. Click on the camera and it will open the Screenshot application which has several options for selecting the desired screenshot area. Select the area of your interest, then click "Take Screenshot". Save the screenshot file with a suitable name for your records.


Screenshots are sometimes useful for diagnosing problems when you open a support ticket.


How do I find the version of my HART Test System software?

To determine the current installed version of the HART Test System tools (Kit-192) on your HTS (HART Test System), open a Linux terminal on the HTS and type “kit192ver” (without the quotes) at the shell prompt. The Kit-192 version on the system will be displayed, e.g., KIT-192 v3.6A or KIT-192 v3.6E. The letter A or E in the version number represents the processor on the HTS and exists for historical reasons. The software version number is specified by the numerical value, e.g., 3.6. An HTS with v3.6A installed on it has identical Kit-192 software as an HTS that has v3.6E.


It is highly recommended that you use the latest released version of the tools for your device testing. Please note that, in general, test logs are not accepted for device registration from older versions of Kit-192 after a software update has been released.


If more than 6 months have elapsed since the last software update was released and your system has an older version installed, please update your system with the latest version.


Why do I get a System SW installation failed error?

See Do not update the Ubuntu Linux OS running on the HART Test System