Skip to content

Cinebot Nano Track + Focus Random Trips — FlairBridge=True in ini

Summary

A Cinebot Nano on Flair Classic (7.32 Beta) tripped Track and Focus randomly while moving — never while energised and holding position — with the terminal reporting Unexpected end of fast move in compute stop, eflag set true. After ruling out BTL reloads, connector checks, and network cabling, the fix was unchecking FlairBridge=True in flair.ini. Separately, on Cinebot Max, a loose Ethernet connector at the back of the robot base was confirmed to cause the same class of intermittent Track/Focus trip — worth checking both causes since they present almost identically.

Symptoms

  • Track and Focus axes trip randomly while a move is running; no trips while stationary and holding position (energised).
  • Terminal/debug output shows: Unexpected end of fast move in compute stop, eflag set true.
  • Trips are not consistent or repeatable at a fixed point in the move.
  • Reloading the BTL and restarting does not resolve it.
  • On Cinebot Max specifically: intermittent Track/Focus trips correlate with tension or looseness on the Ethernet cable at the back of the robot, before it reaches the base's locking connector.

Community Guidance

[RESOLVED] Uncheck FlairBridge=True in flair.ini

Community — Peter Constan-Tatos, Timothy Heys Cerchio — 3 July 2026

Track-and-Focus-together tripping (rather than a single axis) pointed toward a QuadBox network-level issue rather than a mechanical one:

Timothy Heys Cerchio: "Track AND Focus... This might indicate a QuadBox Network error/issue... In fact, if the trip happens while moving on Track, and not shaking the workstation around, I would possibly look for something loose on the Robot side. And, in your case, with custom Rails under Nano, the UltiBox controlling Track."

The confirmed fix:

"So Cosmin said he unchecked Flairbridge True in the ini file and that seems to have fixed our issue so far. It's working without tripping now."

Steps:

  1. If Track and Focus trip together (not a single isolated axis) with eflag set true in the compute-stop message, and the rig is not visibly being shaken or bumped, suspect the QuadBox network path or the FlairBridge setting before assuming a mechanical fault.
  2. Open flair.ini and set FlairBridge to disabled/unchecked (FlairBridge=True → not set / commented out) if it's currently enabled but not actually needed for your setup.
  3. Restart Flair and re-test the same moves that were previously tripping.

confidence_score: 0.72

[RESOLVED] Cinebot Max — Loose Ethernet at the Robot Base Causes the Same Symptom

Community — 3-4 July 2026

A separate operator reported the identical Track/Focus trip pattern on Cinebot Max, traced to cable routing rather than the ini setting:

"If we have any tension on the network Ethernet connection on the back of the robot we experience intermittent trips of both track/focus. I try to ensure it's going straight out before sideways to the locking mechanism on the base (Cinebot Max). But a loose Ethernet anywhere in the sequence can cause that."

Steps:

  1. Check the Ethernet cable at the back of the robot base for tension or a loose connection before it reaches the locking mechanism.
  2. Route the cable straight out from the connector before any sideways bend, rather than putting sideways tension directly on the connector.
  3. Check the rest of the Ethernet run for any other loose joints — a loose connection anywhere in the chain can produce the same intermittent trip pattern.

confidence_score: 0.72