CanXM Studio, in your browser

The real Studio application, compiled to WebAssembly, driving a simulated two-board CAN fixture. No hardware, no install.

Open the demo

Nothing here is a hardware measurement. The application logic is the product's own code, but the boards, the CAN buses, and every timing figure are simulated. Rates shown in the demo are model output and must not be quoted as device performance. The published hardware figures come from a two-board acceptance run on real boards.

Two devices, one tab

The demo runs both simulated boards at once in a single tab. Each is a separate Studio instance with its own trace, project, and measurement, and the two are joined by one simulated fixture wired the way the lab bench is:

board A  can0 <--------> can0  board B
         can1 <--------> can1
         DO0  --------->  DI0
         DI0  <---------  DO0

The green Switch Demo Devices button above the status bar moves you between them. The device you are not looking at keeps running, keeps its board, and keeps receiving.

Start a measurement, transmit a frame, then switch devices and find it in the other board's trace.
Drive a digital output on one board; switch, and the other board's input has followed it.
Record on one board while the other puts traffic on the wire, then download the .asc file.

What is real, and what is not

Part	In the demo
Trace, filters, inspector	Real product code
Statistics and bus load	Real product code, simulated inputs
Transmit, cyclic, DBC decode	Real product code
Diagnostics, ISO-TP, UDS, ODX	Real product code
Projects and settings	Real product code
Two-board fixture and wiring	Simulated
Switching between the two devices	Demo control — the desktop app has no such button
Throughput, bus load, timing	Simulated — not measurements
Electrical / physical layer	Not modelled at all
Device firmware	Reimplemented from public specifications
Firmware package inspection	Header only — see below

Firmware files stay on your machine

If you point the demo at a .cxmfw package, it reads at most the first 96 bytes — the public header — using the product's own parser, and nothing is uploaded anywhere. It can show you the format version, target, firmware version, security counter, and key ID.

It cannot tell you the package is intact. It does not check the payload length, the ciphertext hash, or the authentication tag, and it holds no key and performs no decryption. A package that is corrupt after byte 96 will still be reported as a valid header, because that is all a header can prove.

If a tab closes

One tab runs the demo — both devices, one fixture. A second tab says so rather than starting a second simulation, and takes over on its own if you close the first, restoring the bench from a checkpoint: board claims, digital output levels, memory-card contents, and reboot telemetry all come back.

Anything that was running does not: a live measurement, a replay, an in-flight diagnostic request, or a firmware transfer is abandoned and has to be restarted. The demo says so when it happens rather than letting the UI appear to carry on.