It's my understanding that even an mfx decoder needs an address for the purpose of control. Also that when an mfx capable command station senses an mfx decoder, it simply assigns an address to cv1 -- if nothing is already stored in cv1. But if something is already stored (e.g. 3) in cv1 as a default, the command station (e.g. my MS2 60653) seems to register the decoder/locomotive using that address.

ESU's instruction manual for the LokSound V4.0 family of decoders (section 9.4, part no. 51972, May 2012, firmware 4.6) states that "the addresses can neither be programmed manually by the user nor can they be read out."

But to avoid conflict on my club layout with decoders/locomotives of other users also programmed to default address 3, using my MS2 I reset the address of my decoder/locomotive to 68. After resetting, my MS2 reads the address as 68.

I saved the cofiguration to a loco card and plan to read that information into the club CS2. Will the club CS2 register/recognize my decoder/locomotive using address 68 -- or some other address?

It seems that the ESU non-programming-reading statement applies only for the purpose of original registration. Perhaps the instructions should better simply say that an address is not "needed" for the purpose of initial registration. Is my understanding correct?

So, do I assume correctly that the club CS2 will assign a new consecutive numerical address when I plug in the card (even if it can read the irrelevant address of 68 I assigned to CV1 using my MS2)? Or should I register the mfx (actually ESU M4) decoder/locomotive into the club CS2 directly from the track?

Your explanation suggests that the mfx numerical addresses in the club CS2 and my MS2 are different. But hopefully both the CS2 and MS2 remember the mfx (consecutive but unique to controller) addresses correctly when the decoder/locomotive is switched between club and personal systems/controllers.

A decoder (operating in the Marklin/Trix ecosphere) may have any of 4 addressess and some decoders may be provisioned to support one or more of these 4 for use with the different types on controller.

1) MM/FX = MarklinMotorola (1-80) FX (1-255) - implementation limited by decoder version and controller
2) DCC = (1-10239) - implementation limited by decoder version and controller
3) SX = Selectrix V1 or V2
4) mFX = called a mfxUID = based on the decoders serialnumber - e.g. .mfxuid=0x7dfc6cfc

so while it is possible for users to remember 2 digit (MM) and 4 digits (DCC) in a decimal system, it gets a bit demanding to remember 8 hexidecimal characters.

From its first deliver mFX totally insulated the User from the need from knowing the mfxUID by inserting a translating layer that presented itself as a object with a human readable/definable name and a distinctive icon/picture

It was not until about v3.5.6 of the CS2 firmware, that (GUI) Users even became aware of a separate numbering range (starting at 1) as a shortcut.
It was at this firmware update where we saw the (re)introduction of a numeric keypad to emulate the 6021 operation that people were still experiencing withdrawl symptons from.

Comment: However software developers had been aware of this as a locomotive was addressed by it LOCAL UID . e.g. .uid=0x4006
In the CS2 archetecture the mFX address space is referenced from 0x4000 to 0x7FFF (MM =0x0000-0x03FF , SX2=0x8000-0xBFFF, DCC = 0xC000-0xFFFF)
from the CS2 work file ...
lokomotive
.name=218 245-9 DB
.uid=0x4006
.adresse=0x6
.typ=mfx
.sid=0x6
.mfxuid=0x7dfc6cfc
.icon=BR 218 247 5 DB

At this same firmware change we noted that the "address" represented in the settings screen of a mFX decoder changed its meaning.

- Whereas before it used to reflect the MM address of the decoder, (this was just as a nice convenience as users did not have to drill down into the CVs to find it, before taking they loco to a friends 6021 type layout.)
- After the firmware change this address became the local User/Gui/CS2 address as allocated by the CS2 (And no , you cannot set it yourself)
I am reluctant to call this simply a "mfx address", without adding the "local user" or "local CS2" prefix, as there is also a mfxUID and a LocalUID address associated with the same decode.

Looking at the keypad display we note , at the top, the mode may be selected MM, DCC, mfx. (MM equates to fx)

When choosing MFX you may make use of the LocalMFX address for quick reference - reinforcing the comment that this Local address may be different on another CS2.

From the image it can be seen that when local mFX address 6 is selected , the CS2 presents the name and functions of the loco as if you had called it up in the traditional manner.

That's about it.
The mfxUID is a serial number (32 bits).
mfx uses different data packets for some address ranges in the track signal and low numbers require fewer bits. Therefore it makes sense to assign the actual mfx addresses consecutively starting add 1. This is also somewhat "human readable" now that the CS2 shows the address to the user and allows the user to type it in for loco selection.

It's similar to DHCP: the computer has a MAC address (theoretically this is globally unique) and DHCP will give the computer an IP address which is unique for the domain of the DHCP server.

These addresses WILL (not may) be different, not least because the mfxUID is 8 characters and the local .uid is 4 (and for mfx limited to the 0x4000-0x7FFF address space- for the CS2)
Please also consider that even on the same CS2 the local address may vary - if you do housekeeping and delete unused references only to rediscover decoders/locos in a different order.

However even the local .uid is an intermediate translation step. In my previous post the 0x4006 .uid is represented alongside .addresse/.sid of 6 and a GUI of 6
The GUI value is the decimal conversion of the .sid


And before you say "its just the same but subtract 4000" it is not, as the .uid/.address/.sid are is hexadecimal and the GUI is decimal
This is best considered when we have .ids up to 9 and add one more. in this case the .uid will move to 0x400a ("a" being a "10" in base 16 hexadecimal)


In a prior query there was a reference to Loco Cards.
The Loco Card stores the .addresse value - which is derived from the value that was the .sid on a CS2 , where the loco was discovered, at the time of writing the card.

If you take that card to another CS2 then the CS2 will TRY, in the first instance, to map the .addresse to its own roster (.sid).
However if that .sid is already in use, it will pick the next available one.

Unfortunately , when subsequently reviewing the loco settings to show the "Address" , all you see is the value that the Card requested (.address), not the one that is actually in use (.sid). While these may be the same , on a club CS2 (for example) it probably will not be the same.
I think that showing the .sid (as well) would be more far more meaningful.

So in the following example ... (excerpt from the http://xxx.xxx.xxx.xxx/config/lokomotive.cs2 when browsing to the CS2)

lokomotive
.name=UP 4000 Big Boy
.uid=0x400b
.vorname=
.adresse=0x9
.typ=mfx
.sid=0xb
.mfxuid=0x73ff7a43
.icon=UP 4000 Big Boy


You may use the (6021) keyboard and type in "11" (the decimal value of "b") and this immediately gives you

along with the correct spreed, functions, direction information of the loco

BUT - 3 seconds later it changes to ...

which in my example is the .addresse from the Loco Card.

So, while the speed,functions and directions are retained and usable after this hiccup , seeing the number magically change is a bit scary work out what is happening.
As to WHY it behaves this way, is beyond me. Not least because I may have another "9" so the only way to be sure is to read the name (small print , hard to see etc...)


In summary, the (6021) numeric key pad can be very efficient in selecting a locomotive if you know its .SID.
If you go though an exercise and delete your locos and rediscover them in order you may be able to get your common locomotives with a single digit address. (1-9
although my personal experience is that the lowest number is more likely to be 5),

An extension of this is to somehow get hold of a backup file from a CS2 with 999 locos discovered and massage your own meaningful set of cards.
e.g. BR218 with a .addresse/.sid of "218"

In a Master/Slave(s) environment, all controllers use the loco list from the master and the track signal is generated by the master, thus there is no confusion.

For "Teppichbahning" events (large floor layouts) people often use independent controllers. They only use MM and DCC and disable mfx.
mfx locos stop when they arrive at a new controller and start to register. MM and DCC locos simply travel on and allow the controller to communicate using the manually set address.
I don't know whether RailCom+ works in such environments (negotiation a new address without stopping).

I use DCC protocol to control my locomotives.
I feel better to have full control of the locomotives decoder and decides to change the adresses if i want.
In this case i also welcome to adjust CV 2 which stand for the start voltage.
When i did used MS2,i couldn´t adjust adress CV 2 to change start voltage with an Märklin locomotive.
You see...with the mfx decoder you cannot do so much what DCC can do.
Sometimes i´m angry at Märklin by not present DCC protocol too in theirs 3 rail locomotives.