Originally Posted by: TEEWolf 
No changes to that, because only for mfx you do not need this track.
Not correct, why do you think POM stands for "Programming on Main"?
I will try and break out a couple of aspects that have been merged and made murky.
1) the programming track has (certainly had) a number of functions
- a) to
write CVs to
any/all decoders -
- - This is most logically done for an initial address setup.
- b) to
read all DCC decoder CVs
- - MM decoders (or decoders in MM mode) can only be written to
- - DCC (non Railcom decoders) may be read but this requires that they are the only device on the programming track, as the controller sends a broadcast command with no address, and any decoder will respond
- c) restrict power
- - Today this is considered rather moot because of the need to support sound, but originally limiting the current meant that a badly installed decoder (crossed/shorted wires) might possibly be survived
- d) as an operational design of a controller , programming of bulk data items like firmware and sound is done using the programming track
- - while it would be possible with modern decoders to do this on the main track, the limitation is a pragmatic one as these functions are best done in a clean environment with a single device, rather than having to support the electrical noise and chatter on the main line
2) PoM = Programming on the Main Track is a DCC concept for
- a) making use of a known address to target a decoder
- b) is limited to
write only
- c) because of the need to know the address before programming others, it is an operational design limitation that the one CV that cannot be programming this way is CV1 - the primary address
3) MM Register (CV) programming
- a) never designed for reading
- b) May be used in an environment that has static decodes (m83/m84) embedded in the layout and a controller without a specific programming track
- c) This is a
device implementation whereby it will only respond to a programming command if the immediate prior command (normal switching) that it heard on the wire was for itself.
4) mFX or Railcom
- a) bidirectional by design
- b) require Controller (booster) support of the ability to read (listen) to someone else on the track
There is a lot more that can be said on this topic, but hopefully it has indicated that when you are asking about programming there are a number of important bits of information that you must also take into account
- is the decoder capable
- is the controller capable
- are you setting the decoder address, or another configuration aspect
- are you needing to read or is write only acceptable
- are you do advanced programming for sound uploads
- are you do advanced programming for decoder firmware update
- is the manual sufficient or do you have to read between the lines