Cassini Error "nodeGraphSet not understood" appears when the Dut was renamed or obsoleted after being associated with a Testplan (see Figure1). This can be fixed by activating the correctly named Dut from the Tester > Change Dut... menu. This error can be avoided by always using Device > Save As... to create a new Dut. (and associated DutControl, DevicePins, etc...) Dut means "Device Under Test" and is also referred to as the "Device Definition" with a ri.sys.ObjClass = RiDeviceDef attribute. The Dut uses the pin and path names to assign digital bits and route RF signals. Cassini will not be able to successfully compile if this association is missing. In Figure 2, the green arrow is the new device definition, red arrow is the old device definition. (image obfuscated, values are subtly different)
Symptom: When compiling a testplan, an Error "nodeGraphSet not understood" prompt appears. (See Figure 1)
Root Cause: The testplan has a Dut which is no longer available. (Obsoleted or renamed)
To Fix Error "nodeGraphSet" not understood:
- From the affected testplan, choose Tester > Change Dut...
- Select the Dut from the list.
- Compile to confirm error is corrected.
- Save the Testplan.
Figure 1: Error "nodeGraphSet" not understood
Figure 2: Tester > Change dut...
Figure 3: Configuration window showing new Dut
Device definitions can be created independent of test plans.
Test plans can be linked to particular device definitions.
When a device definition is linked to a particular test plan, when the test plan is opened or the user clicks on the testplan window(when multiple testplans are opened) the 'Dut' instrument in the System configuration will automatically load the particular device.
A by-product of this configuration change is that this will nullify a compiled test plan.
In this case, the testplan pointed to a device with a different title, i.e. - a change was made to the device definition after the testplan had been linked to the original definition.
In this case, the title of the device was changed, and the testplan was not re-linked to the newly titled device.
So the test plan and device definition were out of sync.
When the testplan was compiled, the active 'Dut' in the system configuration(device definition) was different than the test plan.
This caused a walkback.
This is fixed by changing the dut to which the testplan pointed as show below and in the previous screen capture.
Testplan must be saved so the testplan pointer to to the device definition.