CAN-Bus
A two-wire differential bus for talking to industrial and automotive controllers — motor drivers, battery management systems, PLCs — from code running on your fleet.
What CAN-Bus actually is
CAN (Controller Area Network) is a message-based bus, not an address-based one. Every node on the bus sees every message; each message carries an ID that says what it is, not who it's for, and any node that cares about that ID reads it. There's no single master — any node can transmit when the bus is idle, and if two nodes transmit at the same instant, arbitration resolves it by priority (lower numeric ID wins) without corrupting either message. This is why CAN shows up in cars and industrial machines: it keeps working correctly even with a dozen controllers chattering on the same two wires.
It was built by Bosch in the 1980s for in-vehicle networking and has since spread well beyond cars — battery management systems, motor controllers, agricultural equipment, and marine electronics all lean on it because it's electrically robust (differential signaling rejects noise well) and deterministic under load.
How this fits into a General Infinity fleet
General Infinity doesn't speak CAN on your behalf — there's no platform-level "CAN plugin." What it does is deploy and supervise the code you write that talks to it. On Linux, a CAN adapter (native controller or a USB/SPI bridge chip like the MCP2515) shows up as a network interface through SocketCAN, so your code opens it the same way it would open any other socket:
import can bus = can.interface.Bus(channel='can0', bustype='socketcan') msg = bus.recv()
That process is whatever you push to the fleet through the General CLI, same as any other deployment. General Infinity's job is making sure it's running, restarting it if it crashes, and giving you visibility into whether it's alive — the CAN traffic itself is between your code and the bus.
Wiring notes that actually matter
- Termination. A CAN bus needs a 120Ω resistor at each of the two physical ends of the bus — not at every node. Skip this and you'll get intermittent, load-dependent corruption that's miserable to debug because it often looks like a software bug.
- Topology. CAN wants a linear bus with short stubs, not a star. Long unterminated stubs off the main line cause reflections at higher bit rates.
- Ground reference. CAN_H/CAN_L are differential, but every node still needs a shared ground reference to the others, or you'll see marginal signal integrity that gets worse with cable length.