ESU CabControl - Changing Address on LGB/MFX?

[Greg Elmassian]

Tom, POM is defined as programming on the main, i.e. NOT in service mode, but normal DCC operations.

By definition you cannot read back CV values in this mode.

I gave the caveats about railcomm and mfx...

I am using standard NMRA definitions.

It seems you are confused also. As I carefully explained:

having a "programming track" does not mean you are or are not in DCC service mode
not having a "programming track" does not mean you do NOT have DCC service mode available in some mode.

Again, the issue is not that track connections but whether you have service mode on the rails in question.

when people say "it was on the programming track", often it means nothing by itself.

POM means NOT service mode, so you CANNOT read CVs.

"programming mode" means nothing.

This happens all the time on many forums and confuses newcomers... as a person who derives income from this, I am indeed taking you to task for being unclear / ambiguous.

how many times have you seen on this and other forums "I was in programming mode, and set CVxx to this value but could not read it back" ? (typically they are POM and don't realize that no readback is possible in this mode)

I don't think I can make this any clearer. Please read carefully, I did not present any new information, just the same information in several ways.

Greg

 

[LGB333]

Tom, POM is defined as programming on the main, i.e. NOT in service mode, but normal DCC operations.

By definition you cannot read back CV values in this mode.

I gave the caveats about railcomm and mfx...

I am using standard NMRA definitions.

It seems you are confused also. As I carefully explained:

having a "programming track" does not mean you are or are not in DCC service mode
not having a "programming track" does not mean you do NOT have DCC service mode available in some mode.

Again, the issue is not that track connections but whether you have service mode on the rails in question.

when people say "it was on the programming track", often it means nothing by itself.

POM means NOT service mode, so you CANNOT read CVs.

"programming mode" means nothing.

This happens all the time on many forums and confuses newcomers... as a person who derives income from this, I am indeed taking you to task for being unclear / ambiguous.

how many times have you seen on this and other forums "I was in programming mode, and set CVxx to this value but could not read it back" ? (typically they are POM and don't realize that no readback is possible in this mode)

I don't think I can make this any clearer. Please read carefully, I did not present any new information, just the same information in several ways.

Greg

Greg - I don't think this forum's users will appreciate you and me continuing to back and forth debate the semantics of DCC terminology, so I will try to keep my response to your comments brief, only to point out exceptions to your strictly defined terms. I use the DCC WIKI Website - DCC Made Easy for DCC as my technical reference. I feel the NMRA definitions for Service Mode, Operations Mode, Programming Track, and Service Mode Programming and POM Programming you tout are too restrictive; there can be situations where the definitions' criteria overlap. So I feel the definitions should be updated, i.e., exceptions recognized, or hybrid conditions added, to the NRMA Standard's DCC definitions.

Specifically, my Piko Command Station does not have a separate Service Mode Terminal with lower voltage output for connecting to an isolated Programming Track. Its only output terminal is 5 amps, 20 volts DCC output continuously to the track. But, the Piko command station can READ and WRITE CVs on a locomotive's decoder using its assigned Address on the main track layout, or disconnect it and connect it to a piece of isolation track and READ and WRITE the CVs there.....that's Operations Mode, not Service Mode. For example, the NRMA definition states CV Read Back is not possible in Operations Mode; that's incorrect for the Piko unit which is capable doing so in Operation Mode either On the Main or on the Isolation Track. And in this use, the Service Mode Definition doesn't apply: Service Mode requires an isolated programming track that only switches on when in use, usually at lower voltage, and does not require a Decoder's Address. The Piko unit's full DCC power is continuously output, either to the main track or to the Isolation Track, and to READ and WRITE CVs, the Decoder's Address must be used. And with the Piko unit, the Decoder's Address can be changed on either the main or isolation track, but obviously if on the main track, only the one locomotive should be on it to prevent accidental CV changes to other locomotives. Note that I also use the Piko unit when connected to the Isolation track to not only READ and WRITE CVs, but to also concurrently use it as a DCC Test Track to check out the CV changes I've made, which also doesn't comport with the Service Mode definition or Programming Track definition. So, my conclusion is the NRMA definitions are not completely accurate; and the definitions should recognize some exceptions or hybrid situations such as the Piko command station's ability to READ and WRITE CVs in Operations Mode.

 

[PhilP]

Greg - I don't think this forum's users will appreciate you and me continuing to back and forth debate the semantics of DCC terminology, so I will try to keep my response to your comments brief, only to point out exceptions to your strictly defined terms. I use the DCC WIKI Website - DCC Made Easy for DCC as my technical reference. I feel the NMRA definitions for Service Mode, Operations Mode, Programming Track, and Service Mode Programming and POM Programming you tout are too restrictive; there can be situations where the definitions' criteria overlap. So I feel the definitions should be updated, i.e., exceptions recognized, or hybrid conditions added, to the NRMA Standard's DCC definitions.

Specifically, my Piko Command Station does not have a separate Service Mode Terminal with lower voltage output for connecting to an isolated Programming Track. Its only output terminal is 5 amps, 20 volts DCC output continuously to the track. But, the Piko command station can READ and WRITE CVs on a locomotive's decoder using its assigned Address on the main track layout, or disconnect it and connect it to a piece of isolation track and READ and WRITE the CVs there.....that's Operations Mode, not Service Mode. For example, the NRMA definition states CV Read Back is not possible in Operations Mode; that's incorrect for the Piko unit which is capable doing so in Operation Mode either On the Main or on the Isolation Track. And in this use, the Service Mode Definition doesn't apply: Service Mode requires an isolated programming track that only switches on when in use, usually at lower voltage, and does not require a Decoder's Address. The Piko unit's full DCC power is continuously output, either to the main track or to the Isolation Track, and to READ and WRITE CVs, the Decoder's Address must be used. And with the Piko unit, the Decoder's Address can be changed on either the main or isolation track, but obviously if on the main track, only the one locomotive should be on it to prevent accidental CV changes to other locomotives. Note that I also use the Piko unit when connected to the Isolation track to not only READ and WRITE CVs, but to also concurrently use it as a DCC Test Track to check out the CV changes I've made, which also doesn't comport with the Service Mode definition or Programming Track definition. So, my conclusion is the NRMA definitions are not completely accurate; and the definitions should recognize some exceptions or hybrid situations such as the Piko command station's ability to READ and WRITE CVs in Operations Mode.

No.
The NMRA definitions are accurate..
It is just Piko (like many manufacturers) have decided to add additional features, to the way their system works.

It is when users decide these defacto standards, are the standards, the problems start.

PhilP

 

[palmerston]

Ive read a lot of manauls of DCC equipment and NEVER come across the therm SERVICE MODE. So once again irrelevant information which only brings more confusion and drives away potential newcomers to this hobby.

 

[Greg Elmassian]

Palmerston, why don't you read the DCC specification first?

You and your nasty "irrelevant" comments (again) only evidence ignorance and arrogance. Keep your issues to yourself.

Tom, you are DEAD WRONG with the statement:
"READ and WRITE the CVs there.....that's Operations Mode, not Service Mode"

What you don't understand is that some systems will write in Operations Mode, but SWITCH to Service Mode to read, then switch back.

The detail is important when trying to help people, and I gave you examples of how the confusion happens all the time, any times on this forum.

But it seems that all you want to do is argue and not understand, as evidenced by your continued attempt to explain how the Piko system works, when the clues to understanding are in your post itself.

While you maintain that the Piko system is in Operations mode when reading a CV, and you tell me how service mode must be an isolated track, you then indicate that the Piko "operations mode" must not have any other loco on the track when reading a CV.

Clearly it is switching the entire track to service mode.... like many other systems... if you don't get it finally, then you really are lost.

The DCC wiki is flawed and "hybrid" definitions are not needed, just a little thinking and understanding.

Greg

 

[palmerston]

The consumer and I dont need to know which therms or definitions where used way back in the last century and never made it into a operations manual.

 

[JimmyB]

Do we really need this nasty bucking on the forum - Time to stop.

 

[LGB333]

Palmerston, why don't you read the DCC specification first?

You and your nasty "irrelevant" comments (again) only evidence ignorance and arrogance. Keep your issues to yourself.

Tom, you are DEAD WRONG with the statement:
"READ and WRITE the CVs there.....that's Operations Mode, not Service Mode"

What you don't understand is that some systems will write in Operations Mode, but SWITCH to Service Mode to read, then switch back.

The detail is important when trying to help people, and I gave you examples of how the confusion happens all the time, any times on this forum.

But it seems that all you want to do is argue and not understand, as evidenced by your continued attempt to explain how the Piko system works, when the clues to understanding are in your post itself.

While you maintain that the Piko system is in Operations mode when reading a CV, and you tell me how service mode must be an isolated track, you then indicate that the Piko "operations mode" must not have any other loco on the track when reading a CV.

Clearly it is switching the entire track to service mode.... like many other systems... if you don't get it finally, then you really are lost.

The DCC wiki is flawed and "hybrid" definitions are not needed, just a little thinking and understanding.

Greg

Do we really need this nasty bucking on the forum - Time to stop.

JimmyB - I totally agree. I for one will no longer respond to Greg's highly derogatory comments to participants on this forum which he has a tendency to do when anyone brings up a different perspective to his position. This is not conducive to a professional dialogue on the discussion topics, and likely discourages others from participating.

 

[muns]

Play nice everyone. I'm a work stressed Mod and I may not hesitate to get angry and the consequences are unknown....

 

[AMuller396]

Actually ESU's V4.0 and V5.0 multi-protocol decoders are mfx compatible (ESU calls it M4 protocol because of trademark issues). These decoders will self register and operate without problems with a CS3 or earlier Märklin mfx central stations. I converted and ran my first LGB analog locos with ESU V4.0 LokPilot decoders using the M4 protocol on my Märklin CS3 based RR. I bought the ESU LokProgrammer to do their programming so can't vouch for ease of programming with the CS3. Eventually, I disabled the M4 (mfx) protocol on these decoders and now run these locos with DCC protocol mainly because I wanted to assign my own loco addresses.

If one is able to purchase a ESU V5.0 with the sound already downloaded for you by the seller, does one still need the ESU Lokprogrammer? Or would that not be necessary and it would be plug and play (of course some installation etc still required).

 

[Diesel2000]

In my estimation you would still want the Lokprogrammer. Loading sound files is the easy part, but configuring all the options is a lot harder. Function mapping has multiple layers from ordering the keys, to logical/physical functions, to creating function conditions. Its possible to do it all by CV setting, but I honestly could not imagine trying to do it with something like the Massoth Nav. You could do it with JMRI if your CS is supported. I find the Lokprogrammer indispensable for my 5 XL decoder programming.

 

[LGB333]

If one is able to purchase a ESU V5.0 with the sound already downloaded for you by the seller, does one still need the ESU Lokprogrammer? Or would that not be necessary and it would be plug and play (of course some installation etc still required).

Andrew - Concur with Diesel2000's comment about the LokProgrammer. The ESU LokSound 5XL DCC Sound Decoders are highly complex devices. Using a LokProgrammer to set up the lights and smoker voltage outputs, remap F Keys functions if desired, setting the type motor, and changing the default whistle and bell sounds available in the decoder, is essential. Most ESU Dealers won't do more than load the sound file into the decoder for the buyer; but I'll set up the entire decoder and test it out on my test stand motor block for customers buying the 5XL from me for a nominal additional fee......and I also provide a 5XL Wiring Diagram annotated with the terminals settings I've made. So, then the customer only needs to wire the decoder to their locomotive. But obtaining the LokProgrammer would give you the maximum flexibility for installing sound files, replacing the existing sound file on your locomotive, and accessing all the features of the decoder for the initial install and future changes.

 

[LGB333]

No.
The NMRA definitions are accurate..
It is just Piko (like many manufacturers) have decided to add additional features, to the way their system works.

It is when users decide these defacto standards, are the standards, the problems start.

PhilP

PhilP - The NMRA DCC Definitions may be accurate for the era they were developed for the DCC technology at the time. But having worked with US and International Standards in my 38 year career in the U.S. Government and U.S. Military, Standards should be periodically reviewed to see if they need updating, changed, etc. So, perhaps the DCC Standard's definitions may need to be updated to match with the ever advancing technology.

For example, the Standard states that you can't Read a CV in Operations Mode (POM Programming). Why does the Standard state that.........was it that Reading a CV in Operations Mode doesn't technically work for the state of the technology when DCC was first developed , or was it some arbitrary decision by the Standard's developers "let's not allow hobbyists to Read a CV in Operations Mode and force them to use Service Mode for Reading a CV"? It would be much more helpful for the DCC learning experience for all participants on this Forum if more complete answers are provided by the "DCC Experts" instead of "You're Dead Wrong", or "You obviously haven't read the Standard", or "I already answered that in my prior posting......you need to read more carefully", or "the NMRA definitions are accurate".

So, I would still like an explanation why the Standard states you can't Read a CV in Operations Mode.......is it because the engineering design for Operations Mode can't accommodate it? If the manufacturers of DCC systems could produce the capability to Read a CV in Operations Mode, why not recognize that in the Standard.......and it certainly would help to make the DCC technology more user-friendly for hobbyists instead forcing everyone to understand what you can and cannot do in Service Mode v. Operations Mode. I will be interested receiving responses to my question from the "DCC Electrical Engineering Experts" if it's provided in a helpful and courteous manner and without derogatory statements.........not an unreasonable request!

 

[Greg Elmassian]

The mode of sending commands and reading the result in Service Mode is different than Operations Mode, and there is no readback possible in Operations Mode.

It is as simple as that. I don't see what your issue is. If you were an engineer and used instruments to look at the signalling you would see that the system in question changes mode.

It's not that the NMRA is some kind of secret police stopping you from reading in Operations mode, reading in Operations mode is impossible. If you would read the standard of how this works (and it is simple), after you brag about working with standards, then you would understand.

The way readback works means there can be no other loads on the track on the time.

This is simple, and since you just want to argue and stamp your feet, GO READ ABOUT THIS AND HOW IT WORKS and shut up about others that not only know more than you do, but are now unwilling to educate you since you are so sure you are right.

Greg

 

[AMuller396]

Guys, lets calm down. lets get back to topic

So apparently Thomas has gotten a response from ESU N. America, here is what Alec Herman has said:

"The issue is with the Marklin MSD3 decoders not following the DCC standards on the amount of current draw during programming. They draw more current during programming than the standards allow. The CabControl sees the current is above what the standards allow, and is cutting itself off to protect itself. That is why the track status light is going from green to red. Have the customer try programming the CVs on the mainline instead of the programming track. He will not be able to read CVs when programming on the main but he should be able to write them . He can also try installing a 47-100 ohm resistor in one of the wires leading to the programming track. I have attached the diagram showing the resistor."

So there we have it. For those reading this in the future we now have the definitive answer.

 

[LGB333]

The mode of sending commands and reading the result in Service Mode is different than Operations Mode, and there is no readback possible in Operations Mode.

It is as simple as that. I don't see what your issue is. If you were an engineer and used instruments to look at the signalling you would see that the system in question changes mode.

It's not that the NMRA is some kind of secret police stopping you from reading in Operations mode, reading in Operations mode is impossible. If you would read the standard of how this works (and it is simple), after you brag about working with standards, then you would understand.

The way readback works means there can be no other loads on the track on the time.

This is simple, and since you just want to argue and stamp your feet, GO READ ABOUT THIS AND HOW IT WORKS and shut up about others that not only know more than you do, but are now unwilling to educate you since you are so sure you are right.

Greg

So, Greg, unfortunately for me and most of the participants on this forum, you failed to meet this Forum's standards of conduct criteria: "I will be interested receiving responses to my question from the "DCC Electrical Engineering Experts" if it's provided in a helpful and courteous manner and without derogatory statements.........not an unreasonable request!"

You have a reputation on this Forum and the other two large scale forums, MyLargeScale.com and LargeScaleCentral.com for replying with nasty, derogatory and mean-spirited comments to participants that frustrate you. Why do you continue to participate on these Forums since it obviously gives you great stress and anger?! You tout that you're here to be helpful, but your tone and demeanor to many of the participants including me are terrible.

At least I finally received a technical answer to my question about CV Readback: "The way readback works means there can be no other loads on the track on the time."

 

[LGB333]

Guys, lets calm down. lets get back to topic

So apparently Thomas has gotten a response from ESU N. America, here is what Alec Herman has said:

"The issue is with the Marklin MSD3 decoders not following the DCC standards on the amount of current draw during programming. They draw more current during programming than the standards allow. The CabControl sees the current is above what the standards allow, and is cutting itself off to protect itself. That is why the track status light is going from green to red. Have the customer try programming the CVs on the mainline instead of the programming track. He will not be able to read CVs when programming on the main but he should be able to write them . He can also try installing a 47-100 ohm resistor in one of the wires leading to the programming track. I have attached the diagram showing the resistor."

So there we have it. For those reading this in the future we now have the definitive answer.

Andrew - What I don't understand, however, is why are other DCC command stations for large scale trains, such as the Massoth DiMax 1210z, able to Read and Write the CVs in Service Mode on LGB locomotives with the MSD3 mfx/dcc/analog sound decoders installed, but the ESU CabControl cannot. I think it's what you may have previously stated, the CabControl was designed as a multi-scale DCC system and that appears to be hindering the unit's ability to Read and Write the CVs on the MSD3 decoders. It's not the MSD3 decoders being out of compliance with the DCC Standard.

 

[phils2um]

What I don't understand, however, is why are other DCC command stations for large scale trains, such as the Massoth DiMax 1210z, able to Read and Write the CVs in Service Mode on LGB locomotives with the MSD3 mfx/dcc/analog sound decoders installed, but the ESU CabControl cannot.

That, I think, is the key. Most command stations limit the current output in service mode. They are primarily designed for the smaller scales and want to minimize the chance of frying a decoder. Even the Märklin CS3/3+ limits the programming track to 1.5 amps irregardless of what power supply is connected.

 

[LGB333]

That, I think, is the key. Most command stations limit the current output in service mode. They are primarily designed for the smaller scales and want to minimize the chance of frying a decoder. Even the Märklin CS3/3+ limits the programming track to 1.5 amps irregardless of what power supply is connected.

Appreciate your input. So, if I understand your point, you agree, the problem with the CabControl is its multi-scale design weighted in favor of the small scale, and these voltage-limited DCC decoders whereas large scale decoders require more voltage to Read and Write CVs? We know my Massoth 1210z DCC Command Station and my Piko 35010 DCC CS have no problem Reading and Writing CVs on Marklin's MSD3 multi-protocol decoders, only the ESU CabControl system. In fact, I now also sell the MD-Electronics DCC product line and tested their generic DCC Programming Module and it also can Read and Write the CVs on the MSD3 decoders, and amazingly, and its furnished power supply output is only 15 volts 1 amp! I need to measure the CabControl's DCC output in Service Mode with my RRampMeter.

Last night I emailed Marklin's Customer Service asking to confirm whether their MSD3 decoder's Service Mode current draw for the DCC protocol complies with the DCC Standard's current draw limitations. I'll let everyone know their response, although it takes sometimes weeks to receive a response.

 

[LGB333]

Guys, lets calm down. lets get back to topic

So apparently Thomas has gotten a response from ESU N. America, here is what Alec Herman has said:

"The issue is with the Marklin MSD3 decoders not following the DCC standards on the amount of current draw during programming. They draw more current during programming than the standards allow. The CabControl sees the current is above what the standards allow, and is cutting itself off to protect itself. That is why the track status light is going from green to red. Have the customer try programming the CVs on the mainline instead of the programming track. He will not be able to read CVs when programming on the main but he should be able to write them . He can also try installing a 47-100 ohm resistor in one of the wires leading to the programming track. I have attached the diagram showing the resistor."

So there we have it. For those reading this in the future we now have the definitive answer.

Andrew - Another customer actually took his LGB locomotive with the MSD3 mfx/dcc/analog sound decoder installed to the ESU LLC USA Repair Shop for testing. Alec, the technician, was able to Read and Write CVs on the decoder with an ESU ECOS DCC Command Station but he probably used the M4 protocol that's equivalent to mfx. He tried another CabControl DCC Command Station on the decoder and again it error faulted. The customer was told that the design of the multi-scale CabControl unit prevents it from Reading and Writing CVs in Service Programming Mode. When I communicated earlier with the ESU tech, he suggested to use the Operations/POM programming mode for Writing CVs (Reading CVs not possible in Operations Mode). However, here's the rub: I checked the User Guide on one of the latest LGB locomotive models, the LGB 20283 D&S Mogul, clearly states on Page 9: "The CVs can be programmed in any order desired. (POM - Programming can be done on the main track). POM is not possible with CVs CV1, CV17, CV18, and CV29. POM must be support by your central controller." So, ESU's solution to use POM programming with the CabControl will not solve the problem of changing the default CV1 3 Address to another address. I haven't had time yet to test out ESU's other workaround for the MSD3 decoders, "installing a 47-100 ohm resistor in one of the leads to the programming track."