Skip to main content
Firmware Stable

Getting started: connect a new siliXcon device and set it up

Applies to​

Every siliXcon device before its first setup: a motor controller (most often), a BMS or a display. It starts with the device not connected yet and ends when the device communicates with emGUI and the playbook for its setup has taken over. The Getting started page sends the user's assistant here.

Before you start​

  • The rules of the general method apply, the battery-voltage rule among them. This is a setup playbook: propose each step that changes the device, say what it does, and run it only after the user's yes.
  • The user may be new to all of this. Give one action at a time, with the link for it, and wait until the user says it is done.
  • Levels (emGUI's Servers menu, set by the operator, applied at once): reading and search_devices need nothing more; parameter writes and save need Allow writes; commands that move a motor need Allow dangerous commands. Ask for a level when a step needs it, not earlier.
  • When emGUI is closed (a firmware upgrade needs that), you lose the connection. Before, tell the user how to bring you back: start emGUI from Launchpad, tick Servers → Allow AI assistants (unless Remember settings is ticked), then tell you to continue. Some clients need the server reconnected (Claude Code: /mcp) or a restart; the user then repeats the request.

Steps​

1. emGUI and the interface​

emgui_status: the interface must be loaded and connected. The default connection is USB: in Launchpad's Options... the interface usb and the address -1 (any device answers) or 0. If the interface is not loaded or not connected, the user fixes it in emGUI (Connection → Load interface..., Connection → Connect) or in Launchpad (addressing, interfaces).

2. Connect the device over USB, nothing else​

Tell the user: connect only the device to the PC with a USB cable - no battery, no motor power yet. USB powers the device's logic, which is enough to talk to it and to configure it. Avoid USB hubs. Wait until the user confirms.

3. Find it​

list_devices. Empty: say that a search rebuilds emGUI's device tree and discards unsaved work in it, then search_devices (no flags) and list_devices again. The user can also click Search in emGUI. Repeat until the device shows up. Still nothing after a few searches: go through Could not discover any nodes with the user (cable, driver, address).

4. Identify it​

From list_devices: name, serial number, hwid and swid (HWID, SWID). Tell the user what it is, for example "an SL-series motor controller running LYNX". Several devices: ask which one to set up.

  • hwid starts with bms: a BMS. With _CAPRA_ in the swid, continue with the CAPRA playbook. Another BMS application: search_docs for its getting-started page.
  • hwid starts with ift: a display, step 5.
  • hwid starts with esc: a motor controller, step 6.

5. Display​

Tell the user: for basic use a display needs no settings. It shows what a siliXcon motor controller running LYNX sends it over CAN, so it needs that controller, set up first (steps 6-10 with the controller).

  • Wiring: the display's KEY, POWER and GND go to the controller's, its CAN to the controller's CAN (display wiring, display and controller powering).
  • Battery: CAN starts working only when the system is powered from the battery through KEY and POWER; USB alone powers the display but not the link.
  • Check: with the system on the battery, /controller/apptim above 0 means the controller is connected; 0 means not, and the display shows "no connection". /simulate must be 0. The /controller folder is hidden without the service login: the user enters the LYNX login (credentials) in Launchpad's options and restarts emGUI from Launchpad.
  • No connection: the controller must run LYNX at its default address 0, and both devices at the default CAN speed. Another display application: search_docs for its page.

6. Motor controller: choose the application​

Ask what the controller will drive and how it is controlled, and match the answer to one application from How to choose a firmware application: a road vehicle with throttle and power maps and no separate control unit is LYNX; an RC vehicle FALCON; a starter-generator IGNIS; control by the user's own unit over CAN ECHO; a potentiometer or PLC signals OPHION. Anything else: the user contacts siliXcon. The answer must fall into one of them.

The controller's basename limits which applications it takes (a titan takes all of them): if the chosen one is not available, a basename change goes through siliXcon (basename).

7. The firmware variant​

The swid must be VECTOR_<APP>_<mod>: the chosen application, the VECTOR driver (always suggest VECTOR), and a mod that supports the motor sensor.

  1. Ask which motor sensor the motor has and how it is connected, as in step 4 of the motor identification playbook ("encoder" can mean anything).
  2. Hardware: decode_hwid - motor_sensors must include it (sensorless needs nothing).
  3. Mod: read_doc the application's Mods page and pick the mod that lists the sensor: LYNX, OPHION, ECHO, IGNIS, FALCON. Hall, Sin/Cos and sensorless are in generic.

The installed swid already matches: step 9. Otherwise: step 8.

8. Upgrade the firmware (only if needed)​

The upgrade tool cannot reach the device while emGUI holds the USB connection, so emGUI must be closed, which also disconnects you. Before, tell the user the whole sequence and what to say when it is done (firmware upgrade):

  1. Close emGUI.
  2. In Launchpad, click upgrade; in the updater, install VECTOR_<APP>_<mod> (the stable release unless siliXcon said otherwise) and wait for the success message. A new device has no settings to keep.
  3. Start emGUI from Launchpad, tick Servers → Allow AI assistants, click Search, and tell you to continue.

Then list_devices and check the swid.

When the upgrade fails or the firmware is not offered:

  • the current SWTools - older versions cannot reach the upgrade server;
  • USB straight into the PC: no hub, dock or UART; over CAN, every node on the same bitrate;
  • an interrupted upgrade: run it again - the device waits in its bootloader;
  • the firmware not in the list: releases expire, so pick the stable release (firmware lifetime); the controller's basename limits which applications it takes, and a change goes through siliXcon (basename);
  • a device already in use: export its configuration first, because an upgrade to an incompatible version starts from new defaults (export).

Still failing: diagnostic report to siliXcon.

9. Wiring​

Have the user unplug USB, then wire the controller following the typical wiring of its series (the series is in the hwid; decode_hwid links the series page): AX, AM, TX, SX, SC, SL.

  • Motor phases (their order does not matter yet), the motor sensor, the power switch (off), the fuse and the battery.
  • Throttle on GPIO0, with its +5 V and GND as drawn. Not needed for ECHO and IGNIS; FALCON takes the receiver signal instead (its wizard).
  • Supply: a battery or a 2- or 4-quadrant power supply (one that can absorb energy as well as deliver it), never a single-quadrant one. Its voltage must be within the controller's working range from its specification page.
  • Vehicle lifted, the motor free to turn.

Then power on: battery first (power switch on), USB second. list_devices (search again if the address went stale) and /driver/error 0; an undervoltage error right after power-up means USB was plugged in first (trivial values).

10. Motor identification, then the application​

Continue with the motor identification playbook. It ends with a power cycle; then the application's own setup takes over: LYNX, OPHION, ECHO, IGNIS. FALCON has no playbook yet: its wizard.

Report​

  1. Device: name, serial number, hwid, swid (before and after an upgrade).
  2. The application chosen and why; the motor sensor and the mod.
  3. What the user did (connection, upgrade, wiring) and which playbook took over.

Escalate​

The device never shows up, the upgrade fails, or no application fits: a diagnostic report to siliXcon.