Start with one working App
This documentation is organized around customer tasks. First-time users begin with one local create, inspect, and run path. Use the user manual when you need a specific capability, then move to Runtime and field delivery when the App is ready to leave the development computer. Accounts, online services, and runtime targets have dedicated sections, so you do not need to learn them all during onboarding.
Start from your current task
| What do you need to do? | Start here |
|---|---|
| Install or update Theseus | Install and update |
| Learn App Hub and the editor | App Hub and editor tour |
| Finish a first working App quickly | Local quickstart |
| Follow one continuous Page, QG, debugging, and delivery example | Tutorials |
| Create, open, or clone a project | Manage projects |
| Create Pages, flows, Objects, or data capabilities | User manual |
| Build, Start, Debug, or diagnose runtime state | Build and debug |
| Connect an industrial PC, edge device, or Player | Runtime and field delivery |
| Use Qixin AI, Portal, online licenses, or organization services | Accounts and online services |
| Resolve a problem by symptom | Troubleshooting |
How the documentation is divided
| Section | When to use it |
|---|---|
| Getting started | Install for the first time, learn the interface, and complete the shortest local loop |
| Tutorials | Follow continuous steps toward a complete outcome |
| User manual | Complete a specific engineering task when you already know what must change |
| Build and debug | Understand Save, Build, Preview, Start, Debug, Stop, and runtime state |
| Runtime and field delivery | Connect remote targets, manage target access, configure Player, or accept a field delivery |
| Accounts and online services | Sign in to Qixin or use AI, Portal, online licenses, and organization capabilities |
| Advanced | Work with Page source and other advanced extensions; ordinary Page design does not require it |
| Concepts and reference | Look up terminology, project boundaries, data choices, or version-management rules |
A reliable engineering loop
- Define the outcome and boundary: State what must change and which equipment, process, or Safety areas must remain untouched.
- Inspect the current project: Confirm existing Pages, Objects, QG programs, settings, version state, and Problems.
- Make and save the change: Inspect real resources, properties, and diagnostics in the editor instead of relying only on an AI summary.
- Verify locally: Use the local runtime target for Build, Preview, Start, or Debug, including normal, failure, and recovery paths.
- Deliver to the field separately: Confirm the remote target, access, license, downtime window, and physical conditions before deployment, then record acceptance evidence.
Saving the project, Build, and runtime execution are different stages. Save does not update the version on a target. Build does not start the App. Switching runtime targets does not upload the project.
The boundary of AI collaboration
AI Command Center can inspect the current App, create or change project content, and explain diagnostics. A task should state the outcome, allowed scope, forbidden changes, confirmed device facts, and acceptance method. An AI “completed” status ends that task; it does not prove that the engineering result is safe or delivered.
AI does not replace physical equipment confirmation, safety-circuit design, or on-site acceptance. Engineers must confirm the purpose of axes, I/O points, cameras, and other physical devices. Emergency stops, hard limits, and safety control must be enforced by suitable hardware and engineering procedures.
If this is your first visit, start with Install and update. If you already have a defined responsibility, use Start from your goal.