CANtrip Headless

CANtrip

Headless mode, by example

cantrip.exe --headless · v1.5.0 - Yukari
0:00 / 2:38

    Every command, output line and log excerpt matches what CANtrip v1.5.0 prints; frame counts depend on the bus. Long runs are shown sped up.

    Transcript
    1. cantrip.exe --headless. Capture without a window.
    2. Built for CI and test benches. The same capture, log formats and DBC decode as the GUI, driven from a command line. It isn't a scripting language: wrap it in the scripting your CI already uses.
    3. Try it with no hardware. --headless with the synthetic source and --duration 5: one line when it starts, one when it ends, exit code 0.
    4. Log to a file. --log run.asc writes CANalyzer-compatible ASC; a name ending in .csv writes CSV instead. --dbc fills in the message names.
    5. Real hardware, CAN FD. --channel must match the hardware list exactly. --fd and --data-bitrate set CAN FD timing.
    6. Reuse a rune. --rune loads channel, timing, DBC and messages; any flag overrides just its own field.
    7. Send the rune's messages. --send starts the rune's cyclic messages two seconds into the capture. Without --rune it's a config error.
    8. Run until Ctrl+C. Leave out --duration and stop it by hand; the shutdown is the same clean sequence.
    9. When it goes wrong. No channel, an unknown channel or a typo in a flag: one line on stderr, exit code 1, nothing captured.
    10. Drop it into CI. Run the capture, check $LASTEXITCODE, keep the log as an artifact.
    11. Under the hood. main.cpp picks QCoreApplication and HeadlessRunner, which wires the same classes the GUI uses.
    12. Where it stands. Verified: config errors, synthetic captures to ASC and CSV, --dbc. Not yet verified on real hardware: Ctrl+C delivery and --send. Still open: JSON output, a separate send file, trigger-based stops.
    13. One bus to sniff them all. Every flag is documented on the Headless Mode page.