Testing Your Configuration's Response to CAN Data

When testing your configurations response to CAN data it is important to recognize the display or controller may behave differently depending on how you send the CAN data. Always test using the various methods listed below. CANcapture is referenced in the examples below.

Before beginning it is helpful to know what is on your applications CAN data bus - Reference This Article.

Static Data - Static data is used to test the basic functionality of all the gages, calculation events, and user events. When a fixed number is sent in a CAN variable the corresponding gage should display that number, any calculation events should indicate the proper result of its calculation, and any events that will trigger from the message should fire. These can all be observed using the Remote view from the PV tool bar.

Dynamic Data - Dynamic data will help you visually see the response of a gage when it receives data that is changing. This is a good way to verify the smoothing setting of the gage is correct for that type of data. Be careful to only change the data at a rate consistent with the real world measurement. In CANCapture a script routine is used to create dynamic data, an example workspace is provided in the CANCapture Tutorial article called Dynamic Data. These snippets of the individual scripts are found in the workspace and are easily modified for your application.

Requested Data - Some J1939 data is not automatically transmitted by the engine ECM or other controller and is only sent when it receives a Request Message (RQST PGN 59904) from the display. In order to test this properly a script is used in CANcapture that listens for the request data message and responds to it. If you simply send data to drive the gage you wont know if the request message is working properly. There is an example CANCapture workspace that has a RQST handler script in the CANCapture Tutorial article called Dynamic Data. This snippet can be found in the workspace and is easily modified to add any additional RQST handling needed.

Live Data - If you have a tool like CANcapture and access to the equipment the display will be connected to, acquiring a data log of all the CAN data on the bus is very useful. This data can then be played back and you can verify the display responds as expected.

Source Address - Its always good to send CAN messages from other source addresses other than what is expected to make sure there is no adverse effect. This is especially important in a marine application where there are two engines with two different source addresses. It is very easy to copy paste Port and STBD gages then forget to tie one of them to the correct data variable. Verify the source address of each device you have created in the configuration matches the source address in your application.

Units - Keep in mind when you send a data variable that you use the appropriate units expected for that variable. For example in J1939 formatted data, pressure is almost always in units of kPa. If your gage is set to psi the library functions will automatically make the conversion but the CAN message must be in kPa. Double check the units settings on all the gages to verify they are correct.

Scaling - Verify the scaling of the data variable you are sending matches the settings for that variable which will be found in the PV J1939 Library or if it is FreeForm from your product specification. For example J1939 engine speed has a scaling of .125 RPM. To obtain a reading of 1 RPM you must send a value of 8.

Data Rate - When testing the CAN data output of your configuration verify the rate at which the message is sent is correct. This can be done by setting up a packet watch in CANcapture which will show you the data rate statistics. Verify data you are sending to the display is at the correct data rate to make sure any programing activities or gage response functions as expected.

Fault Messages - Use the data logging feature of your CAN tool to log data from your application to see if there are any nuisance fault codes that need to be ignored. These can then be added to the list of dropped messages in the Library of your configuration. When creating custom fault messages in the Library be sure to send the corresponding DM1 messages over CAN to verify the text message that appears is correct for all the languages in use.