Configure equipment and Safety

When to use

Use this guide when an App must connect to a PLC, robot, motion bus, Camera, or custom device, or when real outputs need engineering interlocks.

Objects are the business interfaces that Pages and QG use for equipment. A Page displays state and operator intent, QG coordinates steps, waits, timeouts, and recovery, and an Object owns the concrete device capability. Do not scatter register addresses across Pages or bypass Objects by duplicating low-level control logic.

Before you start

• Prepare an approved equipment list, model, firmware / control-software version, protocol, addresses, units, ranges, axis parameters, and IO table.
• Confirm that the current Runtime target, License, packages, and physical equipment match this test.
• Confirm that the App and motion bus are stopped and the equipment is in an approved commissioning state.
• For real outputs, arrange site supervision, an emergency-stop method, an isolated area, and low-speed / no-load conditions.
• State which actions require a qualified engineer and which results need retained acceptance evidence.

danger

Theseus software commands and Safety engineering interlocks are not certified safety control. Hardware emergency stops, safeguards, safety relays, safety PLCs, controller safety functions, and risk assessment must remain independently effective.

Steps

1. Configure a general Object or custom device

1. Open the context menu under Resources → Objects and select Add Object.
2. Choose a Provider that exactly matches the site protocol and equipment version; do not substitute a similar-looking type.
3. Use an Object id and name that express process meaning. In Properties, enter connection parameters, units, ranges, and Object references.
4. Save and immediately resolve red fields, missing types, and broken references.
5. In QG, wrap low-level operations in business actions, waits, timeouts, and recovery branches. A Page should trigger intent and display the result.
6. Verify simulated input or read-only state before any method that can cause an action.

When no built-in capability fits, continue with Advanced: Custom C# Object capabilities. Build and verify the custom capability with read-only checks before returning here to configure the Object and field equipment.

2. Configure Motion and IO

1. Open Settings → General, enable Motion, and save.
2. Open Settings → Axis/IO and configure the bus, axes, groups, and IO from the approved point list.
3. When live master information must be captured, first use App Start or Debug to enter a test state, then select Scan Devices. Confirm device identity and layout before selecting Capture Master Config.
4. Stop the App, save changes, and run Build. Resolve module, point, or configuration errors in Problems.
5. Start or Debug again, select Pulsar Scan Devices, compare physical equipment with saved configuration, then select Pulsar Start.
6. Read the bus, drive, position, limit, and IO feedback without issuing outputs.
7. Verify homing and motion one axis at a time under low-speed, no-load, immediately stoppable conditions. Test coordinated motion, process actions, and real outputs only afterward.

Saving configuration never hot-updates a running instance. Every axis, IO, or interlock change must go through Stop → Build → Start / Debug and another online check.

3. Connect an external controller

1. Add a communication Object under Resources → Objects that matches the site protocol, such as Modbus, Omron Host Link, or S7-200 Smart.
2. In Properties, enter explicit network / serial parameters, station number, addresses, data types, byte / word order, and timeout. Do not let AI or the runtime guess points.
3. In QG or a custom Object capability, wrap low-level calls in business actions with explicit cancellation, timeout, unknown-outcome, and recovery paths.
4. After saving and Build, verify connection and reads in an isolated environment before testing idempotent writes. Do not blindly retry non-idempotent actions.
5. After a disconnect or timeout, mark any possibly transmitted action as unknown. Confirm it through independent state and site feedback instead of automatic replay.

Maintain the external controller program and certified Safety logic in its vendor engineering tool. Theseus does not replace a controller project.

4. Configure Vision

1. Enable Vision in Settings → General and save.
2. Open the only configuration entry, Resources → Vision, and create a Camera from the Cameras group.
3. In Camera WorkArea, choose Simulator or GigE, enter connection settings, and complete discovery, connection, and capture checks.
4. Create an Inspection from the Inspections group. Choose a configured Camera for online inspection or offline samples for early algorithm work.
5. Define the inspection goal and prepare representative OK, NG, and boundary samples.
6. Generate or edit a draft and select Run Validation Set. Have the responsible vision or process engineer review false positives, false negatives, and boundary outcomes, then approve it before activation as the production version.
7. Stop the App, save, and Build. Use Start or Debug for a new instance, then retest normal outcomes, Camera disconnect, and service failure from a Page or QG.

OK / NG are inspection business outcomes. Camera, service, algorithm, or parsing failures must remain errors. Never present them as NG or reuse the previous result.

5. Configure Safety engineering interlocks

1. Complete Motion, axis, and IO configuration first, with site confirmation of units, direction, and safe state.
2. Open Resources → Safety.
3. Define Safety Inputs, Safety Outputs, and Safety Interlocks, in that order.
4. For each interlock, state its trigger, target output, safe state, reset condition, and abnormal-value behavior.
5. Stop the App, save, and run Build. Resolve every Safety issue in Problems.
6. After Start or Debug, recheck site state, then test input activation, output response, reset, communication loss, and invalid values separately.
7. Record the test steps, actual outcome, responsible person, and unresolved risk.

danger

Safety interlock acceptance does not certify the hardware safety circuit. A software-interlock failure must never weaken protection from emergency stops, safeguards, drive safety functions, or certified controllers.

6. Complete site acceptance

1. Offline review: confirm types, parameters, units, ranges, references, credentials, and the Git diff.
2. Build review: Build succeeds and Problems has no blocker.
3. Read-only commissioning: verify identity, version, connection, state, and data types without issuing outputs.
4. Single-action commissioning: under controlled conditions, test one action, timeout, cancellation, and recovery.
5. Process commissioning: use Debug for normal QG behavior, faults, disconnects, and duplicate-action prevention.
6. Runtime acceptance: use Start and a real Page to verify authorization, error text, long-running behavior, and manual recovery.
7. Evidence: retain the parameter baseline, test outcomes, owner, and risk-acceptance decision.

What success looks like

• Object names and descriptions in Resources make sense to process and site staff, with no missing or duplicate type.
• Online Motion equipment, axis, and IO feedback agree with the approved point list and physical hardware.
• External-controller parameters, addresses, data types, and business actions agree with the vendor project.
• The production Vision version passes validation-set and site boundary testing, and technical errors never masquerade as business outcomes.
• Every Safety interlock enters its intended state for the expected input and resets according to the approved procedure.
• Every real motion and output has independent hardware protection, site supervision, and traceable acceptance evidence.
• Configuration changes were followed by Stop → Build → Start / Debug rather than treating save as a runtime update.

Troubleshooting

Symptom	Action
An Object type is missing or red	Check its module, package, and custom C# Provider Build; keep the exact error and do not substitute a similar type
Motion / Safety is saved but online behavior did not change	Stop → Build → Start / Debug, then run Pulsar Scan Devices and Start; confirm the target
Scan Devices differs from saved configuration	Keep the bus stopped and do not Capture / Start; check wiring, identity, order, firmware, and the point list with the responsible engineer
An external-controller method is missing or fails	Check Provider and protocol version, connection settings, references, and Build diagnostics; read independent state after disconnect instead of repeating a write
Vision still uses an older version	Confirm validation, human approval, and activation; Stop, Build, then Start / Debug, because saving a draft is not enough
Production should continue while Vision is offline	Stop steps that depend on inspection; never substitute a simulated image, previous outcome, or technical error
A point is unavailable in Safety	Fix and save upstream Motion / IO in Settings → Axis/IO, run Build again, then return to Safety

Human confirmation

• Protocol, equipment version, addresses, units, ranges, data types, and timeout.
• Axis direction, software and hardware limits, homing, speed, load, tooling, and safety zones.
• External-controller writes, unknown-outcome handling, task intervals, and recovery.
• Vision sample coverage, false-positive / false-negative cost, validation evidence, human approval, and active version.
• Test conditions, site supervision, emergency stop, and reset for every real action.
• Safety risk analysis, independent hardware safety circuits, and final interlock acceptance. AI cannot approve a site action or safety design.