Unexpected Large GOTO When Back-Running a Move — Cartesian Convert Trick¶
Target Tracking Resolved All rigs BOTH
Summary¶
After forward-running a Target Tracking move, attempting to back-run (run from the end position) triggers an unexpected large GOTO — the rig drives off to a distant position before reversing through the move. This happens because the axis positions stored in the job file at the end of the move do not match where the axes actually ended up after the kinematics-driven run. Flair sees the stored end position and sends a GOTO to reach it. The fix is to use the "Convert" button next to Cartesian Priority, which updates the stored axis positions to match where the rig actually is.
Symptoms¶
- Move runs forward correctly
- Attempting to back-run produces a large GOTO first
- The rig is already in the correct end position, but Flair still goes on a GOTO before the back-run starts
- Issue is especially pronounced when:
- Pan or tilt has rotated >180° in the move (e.g. pan going from 0° to 360°)
- Roll Relative is active (motor positions are not shown directly)
- The move was not built sequentially from start to end
Root Cause¶
When Flair runs a move under kinematics (Target Tracking), it drives the physical axes to computed positions that may differ slightly from the axis values stored in the job table. The stored end-of-move position might show pan at 360° even though the rig physically ended up at a mechanically equivalent but different position.
When back-running, Flair reads the stored start position and sends a GOTO from wherever it thinks the rig is to wherever the stored start position says it should be — even if the rig is already there.
"Getting unexpected large GOTOs when you back-run a move you just forward-ran? This is related to the axis positions stored at the end of the move not matching where the axes ended up when running through the move when driven by the kinematics." — Simon Wakley (2024-09-25)
A classic example: a 2-point Target Tracking move where the second waypoint has pan at 360°. The camera target doesn't move and neither does the camera in space — but pan is stored as 360°, not 0°. Forward-running is fine. Back-running triggers a GOTO because Flair tries to reach pan=360° when it's at pan=0°.
"Second line pan at 360. The cart target does not move and the cart camera does not move. Run it and nothing happens. Back run it and the software sees 360 at the end and wants to start there." — Simon Wakley
Resolution¶
Use the Convert button (Cartesian Priority)¶
After forward-running the move (and ending at the correct position):
- Open the job's Job Type controls and locate the Cartesian Priority section.
- Click the Convert button next to "Cartesian Priority."
- Flair runs through the move internally and stores the actual motor positions reached during the kinematics run.
- Save the job.
- Try the back-run — it should now work without a large GOTO.
Always save before converting
The Convert button modifies the stored axis positions in the job file. Save a backup before converting in case the change produces unexpected results.
"Save the job and try using the 'convert' button next to Cartesian priority and see if it helps." — Simon Wakley (2024-09-25)
"You don't really convert to carts and then convert back. You're just running through the move and storing the actual motor positions that are reached by the move. But just in case always save the move and run carefully after such a change." — Simon Wakley
Roll Relative — additional complication¶
The problem is especially tricky with Roll Relative because motor positions are hidden — only the relative value is shown. To see the actual motor positions:
- Turn off Roll Relative.
- Inspect the stored roll motor values.
- Program the roll motion last (after all other axes are set).
- Use the Convert Carts trick to resolve any discrepancy.
"The really tricky one of these is the roll motor position being different when you are in roll relative as the motor positions are not shown, only the relative value. Turn off roll relative to see this." — Simon Wakley
Prevent the problem during programming¶
- Build moves sequentially from start to end.
- Avoid storing positions with pan/tilt angles that are mathematically equivalent but numerically different (0° = 360°, -180° = 180°).
- For pan values near ±360°, consider programming roll last and using the Convert trick as a standard step.
Evidence from Community Chat¶
"Most often caused by not building the move from the beginning to the end and getting the pan or tilt twisted a little between the start and end." — Simon Wakley (2024-09-25)
"I still struggle with that roll axis goto, when in roll relative, even though I try to store the actual position (motor position) at all points along a move." — Jeremy Andrews (30 years experience)
"Program the roll motion last. Use the convert carts trick. Run to a position and when you turn on carts it should init the roll relative to the last run position." — Simon Wakley (2024-09-25)
WhatsApp Excerpts¶
- 2024-09-25 00:43 - ~ Simon Wakley: Getting unexpected large gotos when you back run a move you just forward ran? This is related to the axis positions stored at the end of the move not matching where the axes ended up when running through the move when driven by the kinematics. Save the job and try using the “convert” button next to Cartesian priority and see if it helps
- 2024-09-25 00:47 - ~ Simon Wakley: To demonstrate this: 2 point normal target tracking move with some target distance. All axes at zero. Second line pan at 360. The cart target does not move and the cart camera does not move. Run it and nothing happens. Back run it and the software sees 360 at the end and wants to start there. Run the convert and it fixes it.
- 2024-09-25 00:49 - ~ Simon Wakley: The really tricky one of these is the roll motor position being different when you are in roll relative as the motor positions are not shown, only the relative value. Turn off roll relative to see this
- 2024-09-25 00:59 - ~ Jeremy Andrews: I still struggle (yes, me....30 years running Flair...😂) with that roll axis goto, when in roll relative, even though I try to store the actual position (motor position) at all points along a move. Roll relative is such a useful tool and avoids the complications that can sometimes arise in Roll Up - but do you have a suggested procedure when programming in Roll Relative and rolling more than 180 degrees - or is there now a fix in Miscellaneous settings?
- 2024-09-25 01:02 - ~ Simon Wakley: Program the roll motion last. Use the convert carts trick. Run to a position and when you turn on carts it should init the roll relative to the last run position. This is based on a recent change that should be on by default in misc setups
- 2024-09-25 01:04 - ~ Simon Wakley: You don’t really convert to carts and then convert back. You’re just running through the move and storing the actual motor positions that are reached by the move. But just in case always save the move and run carefully after such a change
Related Issues¶
- See also: Camera Orbital + Carts Mode Causes Rig to Drift (Target at Infinity) — Related: Camera Orbital drift when entering carts mode
- See also: Bolt Runs Unexpectedly in Carts After Switching from Camera Orbital — E-Stop Required — Related: unexpected rig movement after mode switch
Related Tutorials¶
▶ 00:22 — Graph View overview: viewing axis curves can help identify pan/tilt wrapping issues
Revision History¶
| Date | Change | Editor |
|---|---|---|
| 2026-05-24 | Initial extraction | Tom D / Claude Code |