DCC++ programming on main

wvgca Jan 28, 2021

  1. wvgca

    wvgca TrainBoard Member

    while i have always used the program track to program, i was wondering about programming on the main ..
    now ... programming on the main
    1] does NOT work at all
    2] doesn't work for -most- of the programing
    3] not recommended
    4] only if a single loco is on the main
    5] is perfectly fine , works great ..

    so which is it ??
  2. wvgca

    wvgca TrainBoard Member

    i had hoped that someone had DCC++ up and running to tell me which was correct ?? unfortunately my DCC++ setup is sitting in a bin somewhere beside the layout, i currently have a MRC prodigy DCC system fitted ...
  3. Sumner

    Sumner TrainBoard Member

    Won't help but I've never tried on the Main as I thought that wasn't possible with DCC++. If no one pipes in I'll try and do it before tomorrow,

  4. KC Smith

    KC Smith TrainBoard Member



    Short answer is #5 for a competent DCC++ JMRI Decoder Pro user.

    If ,Then, Else a #3 for a non-competent DCC++ JMRI Decoder Pro user.

    Other controller manufacturers mileage varies.

    Programming On Main, POM is a tried and tested feature of JMRI, DCC++, with NMRA standards when done correctly.
    With JMRI you can only Write changes to a predesignated Decoder Address and can not Read decoders on the Main*.

    I have used POM at large public exhibits of our Modular Layout to demonstrate simple changes to a familiar locomotives with other multiple engines running on the layout and in the staging yard.

    Examples are changing the 'Whistle/Horn, Lighting effects or Sound levels in real time' to show an audience various features of DCC.

    I don't recommend the average DCC user changing more important or complex CV's while on the Main such as Addresses and Consists. Take your time and do those on the Prog Track.

    With that in mind, *There are newer features being developed and tested in DCC++EX Command Station & NMRA standards such as RailCom Cutout which allows a higher level of bi-directional communications with loco's equipped with multi function RailCom decoders to aid in Identifying & acknowledging a new Loco's Address, direction and speed in block detection and other enhanced operations.

    FlightRisk and the DCC++EX team can clarify and elaborate more.

    KC Smith
    Last edited: Feb 3, 2021
  5. craftech

    craftech TrainBoard Member

    My understanding is that "programming on the main" has two caveats:
    1. You must use the exact address of the loco
    2. You can only write to the decoder, not read from it.
  6. FlightRisk

    FlightRisk TrainBoard Member

    Sorry I'm late on this one. There is no difference between regular programming and POM technically. On the program track it is a broadcast command. There is no loco address sent. That means any loco on the programming track would get its address set to 59 if that is the command you sent ;)

    On main, commands go to the address you send it to. Any CV can be written. In other words, anything you can set on prog, can be set on main. The only limitation is reading CV's. Since the track is sending outgoing pulses, there is no way in the DCC spec to read anything back. (That is what Railcom tries to do by shorting the track for a fraction of a millisecond during a dead period, cutting out the CS, and sending a few pulses to communicate using the rails. But I digress)

    The only way for a loco to communicate in DCC is like trying to get information from a hostage on a phone with the bad guy in the room. "OH, you are being watched... pulse your engine when I am right...is it 1? No..is it 2?.. no. Is it 3?. Pulse!. Ok. That's a three...next..." we can do that on a programming track and read the little jolt of current from the the motor getting voltage for a few thousandths of a second since the engine is sitting still and the resting current is stable. Obviously, that can't work on main with your train moving, other Trains could be on the track, etc.

    I agree with Kevin that certain settings like he mentioned should still be done on a program track. Plus you can read it back to know you got it right. Send the wrong command on the main track and your loco could go flying off a curve. The loco cannot move on prog due to a safety feature
  7. CSX Robert

    CSX Robert TrainBoard Member

    I really wish the phrase "Programming on the Main" hadn't become common because it has led to a lot of confusion. There is no NMRA standard for "Programming on the Main"; however, there is a NMRA standard for Operations mode programming (as opposed to service mode). While Programming on the Main usually refers to operations mode programming, many people have used it to refer to service mode programming on the main layout tracks, usually when talking about DCC systems that do not have separate program track and main track outputs. This is where the "only if a single loco is on the main" confusion comes from - if you are doing service mode programming on the main layout tracks, you can only have one loco there at a time (unless you want to program the same value to multiple locos), but with operations mode programming you send the commands to a specific loco address and can have as may as you want on the layout as long as they have different addresses.
  8. FlightRisk

    FlightRisk TrainBoard Member

    Not using standard terms is an issue as well. Almost no one calls it "service mode", they call it "programming mode". Or they just refer to it by track as in "main" or "programming". When you say that some DCC systems do not have a separate program track, are you referring to a user setup or tsome cheap Command Stations that allow broadcast commands on the main track and read back ACKs? In other words, they allow reading CVs on the main track? This would be very bad and not to the NMRA spec. POM and OPS Mode programming should just be different names for the same thing. For someone to corrupt that into allowing broadcast commands on the same track as addressed commands definitely would confuse people.

    Operations Mode - Addressed commands that go to a one specific loco. Normal operations commands control functions such as throttle, lights, horn, etc. Operations Mode programming (aka POM) must also be an addressed command to change the value of CVs. The decoder must support ops mode programming. The intent was to allow for changing things that make sense to change when the loco is on the main track like sound profiles, speed tables, speed matching, momentum, etc. It would be tedious to adjust motor settings by putting them on PROG, changing them, moving them to MAIN, testing it, and then repeating the process. Instead, the loco could be on the track, other locos could also be on the same track, and you can adjust your settings via blind writes to CV locations and see the results of the change in real time. There is no acknowledgement from the decoder, therefore there is no way to read CVs. When an addressed command is received by a decoder, it bypasses its internal ACK mechanism. Since the loco could be in motion, and the ack pulse is usually created by sending a current pulse to the motor when it is idle, this would make no sense. In addition multiple locos and any number of accessory decoders and things that affect current could also be on the track.

    Service Mode (AKA Program Mode) - Broadcast commands that are received by any decoder on that track and should be sent ONLY to an isolated track separate from the main (ops) track. This mode is designed primarily to program ONE decoder at a time, though you could set CVs for all decoders to a specific value with the understanding that you can't use an ACK to sense if the value was written correctly. Some software will fail because it is written to look for the ack. But even in the absence of the acknowledgement, the CV value will still be changed. However, service mode on an isolated piece of track is the only specified method for reading CVs and the proper place for changing most CV settings such as the loco address, CV29, etc. Changing the address of a loco to which you are sending an addressed command to that very address, also makes no sense.

    Now if a manufacturer wants to include a method to switch the same track from ops to service or a user wants to use a 4PDT switch to do the same, they are on their own. And IMO, they should certainly not call it "Program on Main". They should just create a feature like "switch ops track to program for when you don't have a dedicated program track". Or like in our case where DCC++ EX allows track joining where you still have an isolated program track (say as a siding) but is still part of your layout. When you aren't programming, it is just a separate power district of your ops track powered from a second H-Bridge (like the A and B outputs of motor shields). You can drive on and off the track. But when you drive the loco you want to program onto that isolated section and issue a program command, the track automatically switches to program mode and then back to ops when finished. We call it "Drive away programming" since you can then just drive of what was the programming track. Engine Driver supports this option.

    wvgca likes this.
  9. CSX Robert

    CSX Robert TrainBoard Member

    When you say "standard terms", do you mean the terms "everyone" uses, as opposed to the terms used in the Standards and Recommended Practices, because I consider those the "common terms" and the ones in the Standards and Recommended Practices as the standard terms. If everyone used the true standard terms, it would save a lot of confusion. Calling service mode "programming mode" is incorrect, because you can also program in operations mode. "Programming on the main" is referring to where you are programming, not what mode you are using, so it doesn't make sense to use programming on the main to refer to operations mode programming.

    When I refer to command stations that do not have a separate program track output, yes, I am referring to systems that allow Service Mode commands on the main track, although not all of them allow reading of the ACK. These are not necessarily "cheap" systems - in the early days of DCC it was quite common and it does not go against the NMRA standards. In fact, several command stations without a separate program track output have received a NMRA Conformance Warrant, meaning that they adhere to all NMRA Standards, applicable Recommended Practices and Industry Norms. Standard 9.2.3 states that it is recommended (not required) that Service Mode operations occur on an isolated section of track and with limited energy. It also does not state that the isolation and energy limitation should necessarily be done by the command station itself, so it used to be quite common for the command station to only have one set of outputs and if the user wanted a separate "program track" he would isolate and current limit it himself.

    Note that Operation Mode commands can be sent to primary address '0', which makes it a broadcast command because all decoders are supposed to respond to primary address '0' (although some don't).

    Again, referring to Operations Mode programming as POM or Programming on the Main has led to much confusion.
    Last edited: Apr 6, 2021
  10. FlightRisk

    FlightRisk TrainBoard Member

    I was trying to refer to "standard" as what we had interpreted from all the documentation and notes as the NMRA standard. But the more we work with it, the more we would challenge *anyone* to understand it. It's a mess. And it is open to interpretation. People *generally* follow it, but seem to either make up their own rules or figure if no one complains and it seems to work, it's "close enough". It seems a decent portion of the decoders on the market have to have "special rules" to make them work, at least with regard to programming and ack detection.

    We need a council, like a supreme court, that can help clarify the rules, but if there is such a body who can actually give definitive guidance, we haven't found them.

    Trying to wrap my head around this. Can you describe what you are saying a bit more?

    As I believe you are saying with the common use of "programming", people think there is a "program track" to program locos with ACK detection and to set train addresses, and the ability to "program on main" without ACK for things like speed matching. I wonder how this could be made more clear and NOT confusing?

Share This Page