Electronics data model

Electronics object model basics

Once you have a reference to an Electronics product—for example, a Schematic or Board cast from Application.activeProduct—you traverse the object model the same way you do in the ULP: you move from the product, to the collections and properties on that product, to the child objects and their collections, until you reach the object you need. The API is structured so that nested design data (such as multiple schematic sheets or a library broken into device sets and devices) is exposed as properties and collections on those types.

Four top-level products

You get one of the following by casting a Product to the type that matches the document and workspace, as described in Introduction to the Electronics API.

Product	Role in the design
`EcadDesign`	The design project that ties the schematic and board of one electronics design.
`Schematic`	The schematic side: pages (sheets), connectivity, and schematic-specific collections.
`Board`	The PCB side: elements (placements), signals, layers, and board geometry.
`Library`	A component library document: symbols, packages, device sets, devices, and related data.

How these connect

From EcadDesign: use schematic and board to move between the two sides of the same project.
From Schematic: use linkedBoard to reach the board in the same design (when it exists), and parentDesign when the schematic is part of a design.
From Board: use linkedSchematic and parentDesign the same way.
From Library: use parentDesign when the library is embedded in a design; it is None (or null in C++) for a standalone library document.

Walking the hierarchy

Every child set in the Electronics API is exposed as a collection with:

count — how many items are in the set
item(i) — the item at index i, where i is 0 for the first item

You obtain a product, then read a property (such as sheets) to get a collection, then use item to get each child object, then read that object’s own properties and collections, and so on, until you are done.

The example below walks sheets on a schematic, then instances on each sheet, using the same count / item pattern at both levels. Your own scripts can follow the same structure for other collections; see the object types reference for the exact property names on each type.

# Get the application and cast to a schematic, as in the Introduction topic.
import adsk.core
import adsk.electron

app = adsk.core.Application.get()
schematic = adsk.electron.Schematic.cast(app.activeProduct)
if schematic is None:
    return

# Outer collection: all sheets in the schematic.
for si in range(schematic.sheets.count):
    sheet = schematic.sheets.item(si)

    # Inner collection: instances on this sheet; same count / item pattern.
    for ii in range(sheet.instances.count):
        inst = sheet.instances.item(ii)
        # Print position of instance to Text Commands pannel
        app.log("({inst.x}, {inst.y})")

Typical deeper nesting

Schematic → Sheet — A schematic has a sheets collection. Each Sheet has its own child collections (geometry, instances, connectivity, and so on).
Library → DeviceSet → Device — A Library has deviceSets, each DeviceSet has a devices collection, and each Device has further child data. The same count / item rule applies at every step.