kiwi64ajs
commented
2 years ago Hi Marko,
Actually, it's difficult to answer this as the terms you are using are confusing me.
CV Programming can be done in two different ways, which the DCC Spec calls:
1) Service Mode Programming, which is usually done by connecting a dedicated Programming Track to the Programming Track outputs on the Command Station. With Service Mode programming you can read/write CVs
2) Operations Mode Programming (OPS Mode), which is done on the normal layout track and can be done while operating the locomotive or accessory. You can only Write CVs with OPS Mode.
Refer: https://dccwiki.com/Decoder_Programming https://dccwiki.com/Decoder_Programming for more details.
I’m presuming you’re meaning Operations Mode Programming (OPS Mode) programming on the main track when you say: "programmed via the command track”.
On 2/09/2021, at 10:17 PM, marko-pi @.***> wrote: I'll start with a description of the situation as I see it - NmraDCC's documentation is sparse, so I had to "learn" from the examples. Unlike multifunction decoders, it seems that accessory decoders are not supposed to be programmed via the command track.
No, the DCC specs support Accessory Decoder Operations Mode Programming, it but some DCC Command Stations (my Digitrax DCS100 to name one) don’t support it. I found that using the FLAGS_DCC_ACCESSORY_DECODER flag tells NmraDCC not to change the CVs on the command track and to ignore CV1, CV9, CV17 and CV18.
This is a safety mechanism so you can’t easily change the Decoder Address while its running as that is almost always a bad thing to do. However, there is a loophole: two additional CVs can be defined and given as an argument during initialization, so that an accessory decoder can also be programmed on the command track. However, this solution is very clumsy. Most likely you want to have the same decoder address on both the programming and command track, which means that the same address is in three places: CV1/CV9, CV17/DV18, and additional CV pair. (You also need to put the address in CV17/DV18 so that the DCC controller can recognise it and communicate with it as a virtual multifunction decoder).
Is what I have written so far correct?
Not quite. I presume the “and additional CV pair” is what is specified in the OpsModeAddressBaseCV parameter to the Dcc.init() method:
void init (uint8_t ManufacturerId, uint8_t VersionId, uint8_t Flags, uint8_t OpsModeAddressBaseCV); CV1/CV9 is only used for Accessory Decoders
CV1, CV17/DV18 are used for MultiFunction (loco) decoders
The reason for providing the extra OpsModeAddressBaseCV parameter to the Dcc.init() method was mostly a ugly/clumsy work-around to provide a way to do Accessory Decoder OPS Mode CV programming using Dcc Command Stations that didn’t support that capability.
Essentially it lets you enter the Multifunction Decoder address into your DCC System that matches the Address in the OpsModeAddressBaseCV CVs and lets you do OPS Mode programming of the Accessory Decoder, even though the DCC Command Station thinks its OPS Mode programming a MultiFunction decoder.
This is a very clumsy solution.
Yes, indeed. I know that by default the accessory decoder should ignore CV change requests on the command track. But it would be easier to control this directly from CV17/CV18. If those two values are 0x00 (or 0xC0 and 0x00), the decoder should ignore changes to CV, while the NmraDCC library should listen to CV change requests if those two values would specify a viable address.
I guess you could do that - I decided to do it differently… ;)
Also, I’ve just discovered that JMRI now has the capability to generate Accessory Decoder OPS Mode CV programming DCC packets and send them to the Command Station as a raw DCC packet and it will send them to the main track outputs and allow OPS Mode programming of the Accessory Decoder.
So this probably means we don’t need this ugly/clumsy work-around any more, and it could probably be removed.
Does that answer your question?
HTH
Regards
Alex Shepherd
m: +64-21-777764 e: @.***
marko-pi
I'll start with a description of the situation as I see it - NmraDCC's documentation is sparse, so I had to "learn" from the examples.
Unlike multifunction decoders, it seems that accessory decoders are not supposed to be programmed via the command track. I found that using the FLAGS_DCC_ACCESSORY_DECODER flag tells NmraDCC not to change the CVs on the command track and to ignore CV1, CV9, CV17 and CV18.
However, there is a loophole: two additional CVs can be defined and given as an argument during initialization, so that an accessory decoder can also be programmed on the command track. However, most likely you want to have the same decoder address on both the programming and command track, which means that the same address is in three places: CV1/CV9, CV17/DV18, and additional CV pair. (You also need to put the address in CV17/DV18 so that the DCC controller can communicate with it as a virtual multifunction decoder).
Is what I have written so far correct?
This is a very clumsy solution. I know that by default the accessory decoder should ignore CV change requests on the command track. But it would be easier to control this directly from CV17/CV18. If those two values are 0x00 (or 0xC0 and 0x00), the decoder should ignore changes to CV, while the NmraDCC library should listen to CV change requests if those two values would specify a viable address.
Best regards