ABB FP SDK: GetMechanicalUnits, Not MechanicalUnits

After the fix, axis discovery returns a typed collection of mechanical units, and the active unit is selected by name instead of being assigned from a string. The number that matters is the API return type: the FP SDK exposes a method for collection access and text for the active-unit identifier. This is an API contract mismatch, not a robot motion fault.

Two Compile Errors, Two Type Boundaries

The failing statements cross separate compile-time boundaries. First, MechanicalUnits() is not a member of the FP SDK MotionSystem type. The page 175 example uses the PC SDK interface, where that member is available; FP SDK code must call GetMechanicalUnits().

Second, the compiler resolves ActiveMechanicalUnit as a String in the failing FP SDK project. A string identifies a unit by name, but it is not a MechanicalUnit object. Assigning it directly to a variable declared as MechanicalUnit therefore produces the reported conversion error.

PC SDK and FP SDK Access Patterns

The two SDKs model the same controller domain through different interfaces. Copying an example between them can preserve recognizable type names while breaking at the member level. The compiler rejects that mismatch before controller communication or motion data retrieval begins.

The recommended FP SDK approach is to obtain the complete MechanicalUnitCollection and select the required MechanicalUnit by its Name. This uses the collection’s actual object type and treats the active-unit value according to the type reported by the compiler.

Mechanical-Unit Collection Retrieval

The FP SDK Reference Help pattern creates a controller reference, gets its motion system, and calls GetMechanicalUnits(). It then iterates through the returned objects and tests each Name.

Controller c = new Controller();
MotionSystem motion = c.MotionSystem;
MechanicalUnitCollection mecUnits = motion.GetMechanicalUnits();

foreach (MechanicalUnit m in mecUnits)
{
    if (m.Name == "ROB_1")
    {
        // Use the matching MechanicalUnit object here.
    }
}

ROB_1 is a comparison value from the reference example, not a universal robot name. Read the names returned in mecUnits and compare against the name configured on the target controller. A hard-coded name that is absent from the collection produces no match even though collection retrieval succeeds.

Active-Unit Resolution Procedure

1. Confirm that the project references the FP SDK rather than the PC SDK. Use the SDK Reference Help associated with those references when checking member signatures.
2. Replace the unsupported MechanicalUnits() call with GetMechanicalUnits().
3. Store the result in a MechanicalUnitCollection.
4. Read ActiveMechanicalUnit into a String, matching the type reported by the compiler.
5. Iterate over the collection and compare each MechanicalUnit.Name with the active-unit string.
6. Use the matched collection object for subsequent mechanical-unit operations. Handle the no-match path explicitly so later code never operates on an unresolved reference.

Dim motion As MotionSystem = aController.MotionSystem
Dim units As MechanicalUnitCollection = motion.GetMechanicalUnits()
Dim activeName As String = motion.ActiveMechanicalUnit
Dim activeUnit As MechanicalUnit = Nothing

For Each unit As MechanicalUnit In units
    If unit.Name = activeName Then
        activeUnit = unit
        Exit For
    End If
Next

This conversion is a lookup, not a cast. Casting would attempt to reinterpret a string as a controller-domain object; lookup resolves the string key to the object already supplied by the motion system.

Verification and Recurring Pitfalls

Build the project after changing the collection accessor. The member-not-found diagnostic should disappear. Inspect units at runtime and record every returned Name; then compare activeName character for character with those values. A successful result leaves activeUnit referencing one member of the returned collection.

If compilation still reports that GetMechanicalUnits is missing, inspect the referenced SDK assemblies and the Reference Help selected in the development environment. That symptom points to a different API surface than the FP SDK interface described here. If compilation succeeds but no unit matches, separate collection acquisition from selection: first prove that units were returned, then inspect the configured names and the active-unit string.

Common failures include copying a PC SDK example into an FP SDK project, declaring a textual identifier as an object, assuming ROB_1 exists on every controller, and using the first collection member without checking whether it is active. Each failure is visible either in the compiler’s resolved types or in the names returned by the collection.

Frequently Asked Questions