Skip to main content

Configure Objects and equipment

An Object turns registers, protocols, device SDKs, and connection details into App-level business capabilities such as read station state, home an axis, or run an inspection. A Page presents state and expresses operator intent, QG (.qg) owns steps, waits, timeouts, and recovery, and the Object interacts with the concrete capability.

When to use this page

  • Connect an App to a PLC, robot, Motion, Vision, or external-data capability.
  • Resolve a missing Object type, invalid property, or broken reference.
  • Investigate saved equipment settings that do not affect online behavior.
  • Plan low-risk commissioning, failure tests, and delivery acceptance.

For the complete Motion, Vision, and Safety setup, see Configure Objects, Pulsar, Vision, and Safety.

Common entry points

TaskEditor entry point
Add, edit, or delete an ObjectResources → Objects; use the Objects context menu to add and Properties to edit
Create a QG programResources → Scripts → New QG Program
Create an App-local C# ProviderResources → Scripts → New C# Provider
Install or inspect a packageSettings → Packages
Enable Motion or VisionSettings → General
Configure the Pulsar bus, axes, groups, and IOSettings → Axis/IO
Configure Cameras and InspectionsResources → Vision
Configure engineering interlocksResources → Safety

Choose the right capability

NeedPrefer
EtherCAT motion, axes, interpolation, and IOMotion module and theseus.pulsar.controller
Camera capture and visual inspectionVision module and theseus.vision.runtime
Modbus TCP / RTUtheseus.modbus.tcp-master / theseus.modbus.rtu-master
S7-200 Smarttheseus.siemens.s7-200-smart
Omron Host Linktheseus.omron.hostlink
Epson RC+ 7.3 Remote Ethernettheseus.epson.rc7
AUBO i-series ARCStheseus.aubo.i-series
Lightweight App-local rowsInstall Table Store, then use theseus.table-store.table
Custom protocol or customer equipmentAdvanced: Custom C# Object capabilities
Pure App-local logicQG (.qg)

Do not substitute a Provider just because its name looks similar. Read the capability description in the Add Object dialog, then confirm the site protocol, controller version, and required methods.

Object configuration principles

Add and maintain Objects through Resources → Objects, then fill parameters and choose references to other Objects in Properties. Daily work does not require handwritten configuration files.

Every Object should have a unique, stable ID and a name that expresses its process meaning. Select a capability from the description in the Add Object dialog, the site protocol, and the equipment version. Do not alter system identifiers, guess methods, or substitute a similarly named capability.

1. Start with an equipment inventory

Record model, firmware / control-software version, protocol, network or serial parameters, address range, units, direction, limits, timeouts, and safety preconditions. Separate confirmed facts from site questions; never let a default value stand in for an engineering decision.

2. Add an Object instance

  1. Open the context menu under Resources → Objects and select Add Object.
  2. Choose the exact capability available to the current App.
  3. Use an Object id and name that express process meaning.
  4. Fill Properties and select existing target Objects for reference fields.
  5. Save and immediately resolve red fields, missing types, and reference errors.

Display position helps navigation; references in Properties express actual dependencies. Before deleting or renaming an Object, search its references in Pages, QG programs, and other Objects.

3. Wrap low-level capability in business actions

Pages and QG should call semantic methods such as start inspection or read station state instead of copying register addresses in several places. Put reusable equipment steps, waits, retry limits, timeouts, and recovery branches in QG or a custom C# Provider. A Page should trigger the intent and show in-progress, success, failure, and recovery states.

4. Save, Build, then create a new runtime instance

Saving an Object, equipment setting, or QG program changes only source and never hot-replaces the current runtime instance. After configuration:

  1. Stop and wait for Stopped.
  2. Save every related file.
  3. Run Build and resolve Object, reference, module, or source errors in Problems.
  4. Use Start or Debug to create an instance from the new deployment.
  5. Begin with read-only verification, then allow real outputs in stages.

Start, Debug, and Preview do not implicitly include unsaved equipment settings.

Custom C# Providers

Create a custom C# Provider for the current App only when installed packages cannot express a vendor SDK, custom protocol, or customer device. It should offer stable business methods to Pages and QG while owning connection, cancellation, resource cleanup, and persistent state within a clear boundary.

Prefer QG for ordinary sequencing and state composition. When you need to code custom types, methods, and Object references, continue with Advanced: Custom C# Object capabilities; this manual page does not expand source conventions.

Motion and Pulsar

Enable Motion in Settings → General, save, then maintain the bus, axes, groups, and IO in Settings → Axis/IO. The App uses the fixed pulsar Object for Controller capabilities and passes explicit axis, group, or IO point numbers.

Recommended online order:

  1. Confirm the Runtime target, License, bus, and drive state.
  2. Read position, limits, enable state, and IO feedback without issuing outputs.
  3. Under low-speed, low-risk, immediately stoppable conditions, verify one action.
  4. Then verify combined QG steps, timeouts, and recovery.
  5. Record axis direction, units, limits, and manual recovery after a fault.

After Motion is disabled, local configuration can remain for later work but is excluded from a disabled module's Build. Build and accept again after re-enabling it.

External PLCs and robots

Communication Providers

Modbus, S7-200 Smart, and Omron Host Link require site confirmation of addresses, data types, byte / word order, station number, serial or network parameters, and timeouts. Test reads first, then idempotent writes. Do not blindly enable retries for non-idempotent writes.

After a connection or call is canceled, times out, or disconnects, do not assume equipment state. Read explicit state again and reconnect or restart according to that Provider's behavior.

Epson RC+ 7.3

Before using theseus.epson.rc7, confirm the Remote Ethernet port, terminator, timeout, password, and Control Device in RC+. This capability targets RC+ 7.3; do not assume later-version status bits or another remote interface are compatible. If the connection fails after a command may have been sent, its outcome is unknown and must not be replayed automatically. Confirm it through explicit status and physical feedback.

AUBO i-series ARCS

theseus.aubo.i-series targets modern i-series controllers running AuboStudio / ARCS and uses the 9012 JSON-RPC interface by default. It is not compatible with the legacy 8899 interface. Probe the controller and robot name first, then read operational, safety, and runtime state before testing Power, program control, or IO. Treat a timeout as an unknown outcome; do not infer protocol from the arm model or automatically clear a protective state.

danger

Network control, Stop, Abort, and software interlocks are not hardware emergency stops. Independent safety circuits, controller safety functions, limits, and site risk assessment must protect robots, motion, and real outputs.

Vision

Enable Vision in Settings → General, then create Cameras and Inspections under Resources → Vision. Verify connection and capture after creating a Camera. When creating an Inspection, choose a live Camera or offline samples.

Before an Inspection enters production:

  1. Create or edit a draft version.
  2. Run a validation set with representative OK, NG, and boundary samples.
  3. Have the responsible vision or process engineer review false positives, false negatives, and boundary results and approve it.
  4. Activate only an approved version, then Build and deploy.
  5. In a new runtime instance, retest the result and failure branches used by Pages / QG.

OK / NG are business results, not service-health states. A disconnected Camera, unavailable service, algorithm failure, or unreadable result must remain an error. Never present it as NG or reuse the previous result.

Safety

Safety depends on confirmed Motion configuration. Create Safety Inputs, Safety Outputs, and Safety Interlocks in that order. Save changes source only; an explicit Build includes saved rules in the deployment and writes issues to Problems.

danger

Theseus Safety provides engineering interlocks. It is not a certified safety-control system and cannot replace hardware emergency stops, safety relays, a safety PLC, or certified robot safety functions.

Site acceptance order

  1. Offline review: confirm Provider, properties, references, units, ranges, and credential handling.
  2. Build review: Build succeeds, Problems has no blocker, and Git contains only intended source changes.
  3. Read-only commissioning: verify connection, identity, version, state, and data types without issuing outputs.
  4. Single-action commissioning: under controlled conditions, verify one output, movement, or task plus timeout and cancellation.
  5. Process commissioning: use Debug for normal QG behavior, equipment failure, communication loss, and recovery.
  6. Runtime acceptance: use Start and a real Page to verify authorization, duplicate-action prevention, error text, and manual recovery.
  7. Evidence: record the parameter baseline, test results, responsible person, and unresolved risks.

Acceptance checklist

  • Object ids, names, and descriptions make sense to process and site staff.
  • The Object list contains only expected capabilities, with valid properties and references.
  • Pages and QG call business methods instead of scattered equipment addresses.
  • Connection, timeout, cancellation, disconnect, duplicate action, and recovery have been tested.
  • Motion, robots, and real outputs progressed from read-only checks to low-risk actions.
  • A production Vision version has validation-set, human-approval, and activation evidence.
  • Safety and independent hardware safety circuits have separate acceptance evidence.
  • A configuration change was followed by Stop → Build → Start / Debug rather than treating save as a runtime update.

Common issues

The required Provider is missing when I add an Object

Check whether its module is enabled, its package is ready under Settings → Packages, and its custom C# Provider built successfully. Do not substitute a similar Provider. Record the exact missing ID and original error.

An Object has a missing type or Properties cannot be saved

Resolve duplicate Object IDs, invalid properties, and broken references first. When Object configuration is invalid, related Page and QG completion and Build also stop. Do not bypass the issue with empty types or handwritten fields.

Settings are saved, but online behavior did not change

The current runtime instance never hot-replaces Objects or equipment configuration. Stop, Build again, then create a new instance with Start or Debug. Confirm that the intended Runtime target is selected.

QG cannot find an Object or method

Confirm that it is a configured Object instance, then resolve type, reference, and Build diagnostics. Reopen the QG and use current completion instead of guessing a method name.

A Page or QG fails after an Object was deleted

Restore the Object, or explicitly migrate every Page, QG, and Object reference before running Build again. Searching references before deletion prevents this issue.

A device times out and I cannot tell whether the action happened

Mark the outcome as unknown, block automatic repetition, read independent status, and request site feedback. Retry only when the action is proven idempotent and the project explicitly permits it.

How AI can help

AI can perform a read-only equipment inventory, inspect references, and draft configuration or tests. For example:

Perform a read-only review of the current Objects, Motion, external equipment, and Vision configuration. Group findings by equipment semantics, missing references, unit or range risks, and unverified actions. Do not connect equipment or issue outputs.

The responsible specialist must still review equipment, Vision, and Safety content generated or changed by AI. AI cannot approve a site action or safety design.