Resolving ABB PC SDK License and Null Reference Errors

The failure occurs before any RAPID value is read: controller is first null, then construction of Controller stops at the PC SDK license check. Add the license references required by the installed Robot Application Builder help, rebuild the application, and create the controller only after confirming that the scan returned at least one entry. Treat controller discovery, licensed object construction, controller access, and RAPID lookup as separate gates.

Exception sequence and failure boundary

The two exceptions identify different failed gates. The initial call to controller.Rapid.GetRapidData("T_Rob1", "User", "reg1") dereferences controller while the field still contains its initialized value, null. No request can reach the robot in that state.

Adding controller = new Controller(controllers[0]); removes the null-reference condition, but exposes the next gate. The constructor calls ABB.Robotics.Controllers.Licenses.PCSdk.Check(); license validation fails and throws System.ComponentModel.LicenseException. The same license failure during a mastership attempt points to the shared PC SDK licensing layer, not to RAPID data type, task, module, symbol, or mastership behavior.

Object lifetime and licensing mechanism

The number that matters first is the count of usable controller objects, not the count of devices seen during discovery. NetworkScanner.Scan() populates scan.Controllers with controller information. It does not assign the application field named controller, and it does not prove that a licensed Controller instance can be constructed.

C# permits the field declaration private Controller controller = null;, but any instance-member call through that reference fails until an object has been assigned. This failure consumes no controller data and performs no RAPID access.

The second failure is a licensing boundary. The stack proceeds through PCSdk.Check(), the .NET license manager, and the ABB license provider before returning from the Controller constructor. Because the constructor throws, assignment never completes; controller remains unusable. This is application initialization, not robot logic. Repeating the RAPID read or requesting mastership cannot bypass the failed construction gate.

Project license configuration

Robot Application Builder 5.09 documentation contains the project license-reference requirements. Search the installed RAB help for license and add every reference it specifies for a PC SDK application. Use the documented entries exactly; a normal assembly reference alone is not proof that the design-time/runtime licensing data was included.

1. Close any execution path that constructs Controller during form startup while the project is being corrected.
2. Open the license topic supplied with the installed Robot Application Builder 5.09 material.
3. Add the required license references to the C# project using the documented project procedure.
4. Inspect the resulting project entries and their properties against the help topic. Correct names and build treatment matter because validation is performed by the .NET license manager.
5. Clean stale build output through the development environment, rebuild, and start a fresh process.
6. Set a breakpoint on new Controller(controllers[0]). Confirm that execution returns from the constructor without System.ComponentModel.LicenseException.

The constructor is the verification point for this correction. A successful network scan does not test the PC SDK license, while the constructor explicitly does.

Controller selection and RAPID read procedure

Separate discovery from selection so an empty collection or unintended first entry cannot be mistaken for a license problem. The minimal control flow is scan, validate the collection, select a controller, construct the licensed object, establish whatever access state the installed SDK documentation requires, and then resolve the RAPID item.

1. Call scan.Scan() and assign controllers = scan.Controllers.
2. Read controllers.Count. If it is zero, stop before indexing the collection and diagnose discovery or network visibility.
3. Select the intended controller from the returned information. Using controllers[0] is acceptable only when the application has established that the first entry is the correct target.
4. Construct controller = new Controller(controllers[0]); inside an error boundary that records the full exception type, message, and inner exception.
5. Complete the controller access or session steps required by the installed PC SDK documentation before reading data.
6. Call controller.Rapid.GetRapidData("T_Rob1", "User", "reg1").
7. Check the returned reference before reading its value, and report a lookup failure separately from construction or session failures.

The three strings form a lookup path: T_Rob1 identifies the requested task, User the module, and reg1 the RAPID data symbol. Verify spelling and location on the target controller after the license and controller-access gates pass.

Verification checkpoints

Verify one boundary at a time. First, the scan finishes and returns the intended controller information. Second, the Controller constructor returns and the debugger shows a non-null controller. Third, the required access state completes without a licensing exception. Fourth, the RAPID lookup returns an object for the stated task, module, and symbol. Finally, read the value and compare it with the value visible in the controller environment.

Repeat the mastership test only after controller construction succeeds. If both reading and mastership previously failed at PCSdk.Check(), successful construction removes their common licensing blocker; any later mastership error belongs to a different diagnostic stage and must be evaluated from its own exception and controller state.

Recurring implementation pitfalls

Form-load code can hide the order of operations because discovery and construction happen while the UI is being created. A constructor exception then appears under Windows Forms startup frames such as Form.OnLoad and ThreadHelper.ThreadStart(). The deepest application or ABB frame is more diagnostic than the final threading frame.

Other recurring faults include indexing controllers[0] without checking the collection count, assuming discovery creates a session, keeping a field null after a constructor throws, and diagnosing task or symbol names before the SDK object exists. Avoid requesting mastership merely to read a value unless the operation and installed documentation require it; mastership and basic data lookup are separate concerns.

Frequently asked questions