So last weekend I had some friends visit my layout and my friend Boyd brought is wonderful new SNCF loco.

We wanted to change the volume and protocol addressing settings of the decoder of the loco so we decided to use my Intellibox to do this.

We used the guide I have at http://cabin-layout.blogspot.com/2005/08/mfx-Decoder-Intellibox.html

Now, mfx decoders can't be programmed with the Intellibox on the programming track, so we did the work on the mainline as directed.

We were able to do what we needed and in testing that our efforts matched our goals we of course tested the sound volume, by switching sound on using F2.
All worked well.

Then I wanted to run one of my trains, we found it was no longer responding. Then it dawned upon us that we had forgotten to remove my only mfx loco from the track, and it had in fact also been the target of the programming changes we had made to my friends loco, including changing its address.

This surprised us a little, because in order to get his loco decoder into programming mode we thought that we had to remove power from it, and restore power once we were sending a stream of Motorola direction changes as the first packets it would receive. Thus we thought that other decoders would not have gone into their programming mode.

It turns out that because I have my Intellibox set to start up in power OFF mode, after the reset we did each time, it correctly did not switch track power on. Since I pressed the green power button after sending the change direction command for address 80, the first packets sent out after power on, were the plain Motorola packets, enough to make any mfx style decoders jump into programming mode. (This in fact means it is much easier to get the decoder into programming mode with the blinking lights.)

So that explained why my mfx loco had gone off the rails and we set about reprogramming it, including a factory reset.

As we were testing that loco, again using F2 and various functions, we heard a buzzing. I followed the sound of the buzzing, and found my mobile crane (46715) had raised its jib all the way up and the hook was pulled all the way up! We found that it too had had its address changed! It too was jumping into programming mode! Using the various functions was activating the delicate motor of the crane and doing crazy things.

So, I have updated the mfx instructions at http://cabin-layout.blogspot.com/2005/08/mfx-Decoder-Intellibox.html

We thought that we could rectify the crane by doing a factory reset, but alas after doing that, we could not get it to lower the hook! :-(

So the moral of the story is, remove all modern Märklin decoders from the layout when doing any programming on the main.

Can't be done? I always do it on the programming track, using the guide from Uhlenbrock.

You started with a suboptimal guide.
You own guide? Maybe time for an update ...

For decoders that support mfx and DCC, the normal DCC programming can be used. There are known workarounds for the bugs of the Märklin decoders.
For mfx decoders that support MM, but not DCC, the normal MM programming mode must be used

Using an Intellibox ? (Not Intellibox II)

Can you point to their guide?

Note: if you switch the relay of the Intellibox so that the programming track is using track current, all you have done is add your programming track to your mainline, and it is no longer a programming track per se.

Note also, that the guide I put together years ago, also used information from the Uhlenbrock page (now gone), the reason I created the page was because the Uhlenbrock page missed important steps because the author made certain assumptions of various Intellibox settings. My instructions were more comprehensive as a result.

https://cabin-layout.blogspot.com/2005/08/mfx-Decoder-Intellibox.html

As I suspected, it is switching track power to the programming track. Once that is done, there is no electrical difference between that piece of track and the rest of the layout. You can call it whatever you like, but it does not change reality. One could equally declare the entire layout a programming track. The important aspect of a programming track is that it does not get full power, not that it is located on the workbench or separated from the rest of the layout. The method of changing CV values using mainline voltage is called POM (Programming On the Main) and is distinct from using a programming track.

And, as you say, other locos on the layout may also go into programming mode, so there is little advantage. Certainly using the address itself instead of 80 will reduce that problem.

I looked on the Uhlenbrock site again, and they still omit to tell people to set the protocol of the addresses used to select the CV and data values being set etc. So anyone with DCC protocol as a default will likely end up tearing their hair out in frustration because it likely wont work.

Good link - thanks.

Digital signal integrity is not really high in a MRR setting anyway. Although technically feasible, I do not recommend POM, especially for initial registration. When modifying CVs and just reading from/writing to a decoder it generally works well for me, but I still prefer the prog track.

I just keep a short section of spur track which is wired to only the prog feeds on the CS2 and I have never had any problems.

My CS 2 supplies enough power to run my locos just as they would on the main, which is an advantage IMO. I never thought of it as a safe environment to protect me from screw ups, so full power to the programming track is what I prefer. Its main advantage is the lack of other decoders to confuse communications with the CS, allowing reliable, error free communication.

I know that there are not any issues where booster circuits join, all they need are to have the track power leads isolated between sections. In analog operation you had to place rockers between power circuits to avoid bridging, but that is not the case with any of the Märklin digital control systems that I am aware of.

I assume the same isolation logic applies to a programming track section although mine has always been physically seperated. It would be ideal to have a section where you could just run into the programming track without handling the models, but my layout is not that advanced yet.

I bet others here have dealt with this though and can advise us as to best practices for the electrical isolation of a programming track section.

so the issue was that some decoders I have cannot be programmed on the programming track. Period.

Using my equipment, I am forced to make changes on the non-programming track (mainline = POM).

I have since updated my software so that anytime I go into my decoder programming functionality, I can get a list of all items on the layout using decoders that can be changed using POM so that I can ensure they are all isolated or removed.