Dear All -

A few weeks ago, dave55uk mentioned an interaction between two MS2s that I'd never heard of previously. He said,



I would like to know the digital details of this interaction. By digital, I mean that the only way that the two MS2s can communicate is over the CAN bus connecting them to the gleisbox that they are both attached to. Consequently, there must be undocumented commands in Marklin's CS2 protocol that allows one MS2 to query the other to download loco information (name, address, protocol, etc.) I'm familiar with the public documentation for the CS2 protocol, but this interaction is not described anywhere in it.

Does anybody have a CAN bus trace of this happening that they could share? Or a link to another forum where it is described? I would like to incorporate it into a program that I'm developing to run my own layout.

Osoraku

Would that not be the same thing that happens with the new MS2 software connecting to a CS2/CS3? Upon boot they resync from the "master" the set of loco's they are aware of and recopy down the settings of each. Or put another way, they are just re-adding the loco's from the "master" so they have the most current settings for each loco they are configured with.

Dear All -

Here's a brief summary of the MS2 - MS2 interaction. For full details (annotated trace of the exchange), see the attachment. Recall that all of the devices are attached through the CAN bus connecting them to the CS2/CS3 or to a Gleisbox.

A key command used by the MS2s (probably CS2/CS3s, too) is the "Anfordern Config Data (0x20)" command (ACD for short henceforth). The ACD command is followed by a response as a "Config data stream (0x21)" that all other agents connected to the CAN bus can read and use to update their internal state. Hence, the config data stream is never flagged as a response packet according to the Märklin CS2 v 2.0 protocol document.

The boot process starts with the master MS2 (lowest serial number MS2) issuing a CAN BOOT command. The Gleisbox responds. A SYSTEM STOP is issued, presumably for safety. Then another slightly different CAN BOOT command is issued to the Gleisbox to tell it to start.

The master MS2 sends a PING to discover other MS2s, followed by another general CAN BOOT and SYSTEM STOP. Then the master queries the other MS2 about its onboard files (an ACD "ms2-conf" inquiry). The ACD response is a config data stream labeled [config]. Next, the master MS2 asks the other MS2 what files it has (akin to a Windows dir command / Unix ls command). The response is a [files] data stream.

Loco information can only be changed on the master MS2. When it is, it is automatically rebroadcast to all other devices by a config data stream with the [lokliste] identifier.

When a loco is selected by an MS2 that is not the master, it asks the master for an update of the loco's properties. This interaction is an ACD inquiry for "lokinfo xxxx" where xxxx is the loco name. The response is a config data stream labeled, [lokomotive]. It contains all the info about the loco (name, functions, MFX UID, etc.)

The [config], [files] and [lokliste] are not documented data streams. [lokomotive] is, however, in Sec. 8.1 of the protocol document.

Sorry, not so brief (but compared to the attachment, it is).

Osoraku

Attachment (updated 16 Jan. 2026): v2 MS2-MS2-log.pdf (55kb) downloaded 1 time(s).; v1 MS2-MS2-log.pdf (54kb) downloaded 5 time(s).; v0 MS2-MS2-log.pdf (55kb) downloaded 13 time(s).

Edited by user 16 January 2026 15:59:15(UTC)  | Reason: Uniformly referred to master MS2; updated attachment

I would caution against using the term expander, certainly without context.
And also ensure that the term "CAN bus" is not used in the fuller context of the "System Bus" cabling for Central stations

A few initial points
* the 60122 will not work directly with a CS2/CS3 - as it picks up/passes on its power differently
** similarly plugging a 60122 into another 60122 will not work (You may have one in each of the TrackBox's 2 x 10pin device ports)
* the CAN bus (usually 2 wires) is incorporated in System Bus , which also accommodates a sync signal (TrackSync/RailSync(sic) ) for boosters.

The main point being that the CAN bus needs correct termination at each end.
"Devices" - e.g. (Mobile Stations, L88, 6021-Connect, Booster) may tap onto the bus in such a way that they do not upset the quality of the main bus signal. And the length of that connection is restricted and nothing like the 100m of the main CAN-bus as specified.

Sorry, if the above is off topic for the OP. (Marklins command implementation over the CAN-Bus Master<>Slave )
In that discussion, I cannot add anything other than to agree with interest.

However, related, there has been much expectation/hope in some quarters that Marklin would provide
a) devices for the MS2 like a CAN-bus connected 7072/Keyboard for accessories
b) a supported configuration for direct Booster connection. (The cable plugs might be a show stopper but the wires are there)
Most of this is just software, and I note FWIW, that a number of years ago one version of MS code had a setting referencing "Booster" that didn't appear to do anything and disappeared in the next release.