Re: [Jmri-developers] GUI design issue gotcha with DecoderPro

[Bob J. <bob...@lb...>]

On Aug 17, 2011, at 8:41 PM, Dick Bronson wrote:

> Andrew,
> As already noted by Walt, the problem is that you can only write them 
> one at a time in OPs mode. The first write destroys the address before 
> the second write can take place. The second write then goes out to some 
> pseudo random unit address, not the one being changed. The 'tricks' to 
> do this require switching to short addressing before changing the 
> extended address. This unit does not support short address mode.
> 

I think you've misunderstood the confusing language in the DCC standard.  (The NMRA seems to actively try to write poor specs)

The intent was that the decoder would only change its internal value of CV17 and CV18 when it sees programming packets for CV17, followed by programming packets for CV18, with no other programming packets in between.  Most decoders don't do this, but there are at least a few that do. If the decoder does do it, it's a safe operation to write a new value to CV17 and CV18 while using ops mode programming.  You can't go on to write CV20, CV21, without switching to the new address, though.

This is a little moot, because I think JMRI will fail long before this.  As far as I know, if you change JMRI's idea of the long address, it starts using that _immediately_.  It would then send ops mode programming to the new address, which the decoder isn't listening for yet.

Bob

> On 08/17/2011 12:43 PM, Andrew Crosland wrote:
>> Dick,
>> 
>> THe decoder behaviour is incorrect in that case. CV17 should only be
>> written when CV18 is written as they form a "paired CV". See footnote 9
>> in RP9.2.1
>> 
>> Then you will at least get the consistent new value for the long address.
>> 
>> Andrew Crosland
>> <snip>
> 
> 
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
> user administration capabilities and model configuration. Take 
> the hassle out of deploying and managing Subversion and the 
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Jmri-developers mailing list
> Jmr...@li...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

--
Bob Jacobsen, LBNL
Bob...@lb... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG