Troubleshooting

Explanation: The triage mindset minimizes wasted effort. Most failures have cheap, common causes (cable, app conflict, power state). Working through the cheap causes first resolves 80-90% of issues in minutes. Escalating immediately wastes Support time + your time. Changing multiple things at once destroys diagnostic information.

Explanation: The single most common cause of “CAPP doesn’t see camera” is another app holding the camera connection — typically Canon EOS Utility running in the background. Close it first; CAPP detects the camera within seconds. Cable damage, broken body, and reboot are less common causes addressed later in the 8-step triage.

Explanation: Exposure Simulation enabled on the Canon body causes Live View to simulate the exposure that would be captured — in studio with flash, that simulation is dark/black because no flash is firing during Live View. Setting Exposure Simulation to Disabled (m08 Section 7 baseline) restores normal Live View.

Explanation: The canonical 4-step robot detection check (textbook Section 3.1): Ethernet connection + same local network + no firewall + power on. Camera USB and lighting subnet are unrelated to robot detection. CAPP reinstall is excessive — only escalate after the 4 basics.

Explanation: Strobe recharge can’t keep up with maximum-speed non-stop spin → some frames fire before strobe is fully recharged → darker frames. The 3 fixes in order of cost: (1) reduce robot speed (free, instant), (2) reduce light intensity (less power = faster recharge), (3) upgrade to Broncolor (faster recharge hardware, more expensive). Start cheapest.

Explanation: CAPP’s Editing interface requires ≥ 2 GB GPU memory. Systems with integrated graphics may have less. Fix on Windows: Settings → System → Display → Graphics settings → Add CAPP as a classic app → set to High Performance (forces use of discrete GPU if present).

Explanation: Settings → System → Display → Graphics settings → Browse for classic app → C:\Program Files\PhotoRobot Controls\PhotoRobot Controls → Set graphics preference to High performance. This is a per-app Windows setting; CAPP will use the discrete GPU from then on.

Explanation: Service GUI bypasses CAPP’s workspace logic to talk directly to robots and cameras. Use it when CAPP can see hardware but can’t drive it — Service GUI confirms whether the hardware itself responds. If Service GUI can drive the robot but CAPP can’t, the issue is in the workspace / preset configuration upstream.

Explanation: Three subsystems failing at once is almost always common infrastructure, not three coincident hardware failures. Check the network switch + lighting access point first (LEDs, power). The clean restart sequence (textbook Section 10) resolves ~60% of these. Independent hardware failures coincident on the same morning are statistically rare.

Explanation: Burning smell, smoke, sparks, or visible physical damage = immediate stop + escalate. This is m02 Safety territory. Continuing operation risks equipment damage, fire, or injury. Power off the affected equipment, document the symptom, contact PhotoRobot Support before attempting any further operation.

Explanation: The 5-item escalation packet (textbook Section 9): customer ID + one-sentence symptom + what you’ve tried + timing + exact error text/screenshot. Tickets that lead with this packet close in half the time of tickets that say “it doesn’t work.”

Explanation: Parallel fixes feel faster but destroy diagnostic information. If you change 3 things at once and it works, you don’t know which change fixed it — next occurrence, you have to retry all 3. Bisect: one change → test → if not fixed, undo and try the next. Slower per-try, but each try teaches you something concrete. Critical for recurring or intermittent issues.