Nomis52 at 17:40, 9 November 2012

2012-11-09T17:40:57Z

Nomis52: Created page with "The RDM Responder Tests can produce quite a bit of output. This guide covers how to interpret the output and diagnose failures. First a quick overview…"

2012-11-09T17:11:16Z

Created page with "The RDM Responder Tests can produce quite a bit of output. This guide covers how to interpret the output and diagnose failures. First a quick overview…"

New page

The [[RDM Responder Testing| RDM Responder Tests]] can produce quite a bit of output. This guide covers how to interpret the output and diagnose failures.

First a quick overview of how the tests are structured:

== Test Categories ==

Tests are grouped according to the sections in the RDM Categories/Parameter ID Defines table in the E1.20 document. There are some extra categories for specific behavior like error conditions and sub device handling.

== Test States ==

There are four possible result states for a test:

; Passed
: The responder replied with the expected result
; Failed
: The responder failed to reply, or replied with an un-expected result
; Not Run
: This test wasn't run because the responder doesn't support the required functionality or a previous test failed.
; Broken
: An internal error occurred, this indicates a programming error or an error with the test rig.

== Log Messages ==

;Warnings
:Warnings indicate behavior that doesn't match the standard, but is unlikely to cause usability issues. Warnings are printed in the summary section of the test output.
;Advisory Messages
:Advisory messages indicate issues that are not covered by the standard but are likely to cause problems i.e a sensor temperature out side of the stated scale range.

← Older revision		Revision as of 17:40, 9 November 2012
Line 26:		Line 26:
	;Advisory Messages		;Advisory Messages
	:Advisory messages indicate issues that are not covered by the standard but are likely to cause problems i.e a sensor temperature out side of the stated scale range.		:Advisory messages indicate issues that are not covered by the standard but are likely to cause problems i.e a sensor temperature out side of the stated scale range.
		+
		+	== Test Output ==
		+
		+	Let's go over the output from the tests using some examples. If you're running the tests from the command line you can see the verbose output by adding <tt>-d</tt> as an argument. If you're using the Web UI the verbose output will be visible in the bottom third of the screen.
		+
		+	First a successful test:
		+
		+	<pre>
		+	GetDeviceModelDescription: GET the device model description.
		+	GET: uid: 7a70:00000001, pid: DEVICE_MODEL_DESCRIPTION (0x0080), sub device: 0, args: []
		+	Response: RDMResponse: ACK, PID = 0x0080, data = {u'description': 'Model 1'}
		+	GetDeviceModelDescription: Passed
		+	</pre>
		+
		+	The first line contains the name of the test, as well as a one line description of what the test does. The second line is the command we sent to the responder, in this case it was a GET
		+	DEVICE_MODEL_DESCRIPTION sent to 7a70:00000001 with no parameter data.
		+
		+	The third line is the response we received from the responder. In this case we received an ACK, with the response data "Model 1". This is a valid response so the test is declared to have passed (line 4).
		+
		+	Now let's consider a test that fails:
		+
		+	<pre>
		+	AllSubDevicesDeviceInfo: Send a Get Device Info to ALL_SUB_DEVICES.
		+	GET: uid: 7a70:00000001, pid: DEVICE_INFO (0x0060), sub device: 65535, args: []
		+	Request failed: Response Timeout
		+	Failed: expected one of:
		+	CC: Get, PID 0x0060, NACK Sub device out of range
		+	</pre>
		+
		+	In this test, we send a GET DEVICE_INFO to all the sub devices on the responder. In this case the responder doesn't respond with any data, so we declare a response timeout. The test then displays what it was expecting, in this case the correct response was a NR_SUB_DEVICE_OUT_OF_RANGE response code.
		+
		+	Let's consider another test:
		+
		+	<pre>
		+	GetSensorDefinitionWithNoData: Get the sensor definition with no data.
		+	GET: uid: 7a70:00000001, pid: SENSOR_DEFINITION (0x0200), sub device: 0, data: ''
		+	Response: RDMResponse: ACK, PID = 0x0200, data = {u'normal_min': -32768, u'name': 'Device Lifetime Hours', u'range_min': -32768, u'range_max': 32767, u'normal_max': 32767, u'supports_recording': 0, u'prefix': 0, u'sensor_number': 4, u'type': 32, u'unit': 0}
		+	Failed: expected one of:
		+	CC: Get, PID 0x0200, NACK Format Error
		+	GetSensorDefinitionWithNoData: Failed
		+	</pre>
		+
		+	Here we send a GET SENSOR_DEFINITION but without any parameter data. Recall that the GET SENSOR_DEFINITION command takes one byte of data which represents the sensor index to return the definition for. In this case the responder replies with an ACK, even though it doesn't have enough information to determine which sensor we asked for! This fails the test since the correct result would be a NR_FORMAT_ERROR.

RDM Test Output - Revision history

Nomis52 at 17:40, 9 November 2012

Nomis52: Created page with "The RDM Responder Tests can produce quite a bit of output. This guide covers how to interpret the output and diagnose failures. First a quick overview…"