[solved] RocPro Extended Address programming issue

Post Reply
Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

[solved] RocPro Extended Address programming issue

Post by Dagnall » 01.04.2018, 19:22

Rob,
I have been experimenting with RocPro extended address programming and have uncovered an issue.
I am not sure how many decoders this will affect. But I think it is universal.

The issue I found is that RocPro programs any changed extended addresses by sending CV[17] first, using the current loco address known to RocPro, then it sends CV[18] to the revised/new address.
But until both CV17 and CV18 messages are received, the loco decoder does not know it's revised address. :!:

For example, I have a loco with (short) address 36.
I write "extended address 37" and RocPro sends: CV[17] (192) using the Address (RocData [1] and [2]) "0" "36" .. so this is set ok, ..
BUT it then tries to send CV[18] to the NEW Address of "0" "37", which of course the Loco cannot respond to as it has not received this yet......

I think the solution is to send CV17/18 BOTH to the "current address", and update the RocPro loco address AFTER BOTH "set CV17" and "set CV18" messages have been sent..

(The alternatives use pseudo addresses which I think may introduce more errors..
OR, Send CV[18] first, then send CV[17] to a pseudo address calculated from the previous CV17 and the current CV18
OR, Send CV17 first, as at present, then Send the new CV18 to an address calculated from a previously read CV18 plus the (just sent) CV17.)

Cheers
Dagnall

rvooyen
Posts: 973
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: RocPro Extended Address programming issue

Post by rvooyen » 01.04.2018, 20:10

I agree.

On an intelliboox using POM, you set both CV17 and CV18 first. However you also then need to set CV29 to at least 32 (bit 6), since this then activates the long address under CV17 and 18. (ESU decoder).

Robert

rjversluis
Site Admin
Posts: 41610
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: RocPro Extended Address programming issue

Post by rjversluis » 01.04.2018, 20:31

AFAIK you cannot change the decoder its address with POM.

rvooyen
Posts: 973
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: RocPro Extended Address programming issue

Post by rvooyen » 01.04.2018, 22:54

I do it all the time.
Robert

peter&basti
Moderator
Posts: 6554
Joined: 09.01.2012, 22:09
Location: Vienna, Austria

Re: RocPro Extended Address programming issue

Post by peter&basti » 01.04.2018, 23:14

Hi Rob,

i do the same with ZIMO Decoders.
  • - Brandnew Loco with brandnew Decoder placing on the track.
    - Setup the loco in RR with address 3 and then changing the address via RocPro.
    - Afterwards changing in the RR loco definition to the new address.
Works perfect via PoM.

I do not have a PT since i buried my IB COM some years ago.

But until now i used short addresses only.

rjversluis
Site Admin
Posts: 41610
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: RocPro Extended Address programming issue

Post by rjversluis » 02.04.2018, 06:14

Hi Dagnall,

OK, I can reproduce the problem.
:coding:

rjversluis
Site Admin
Posts: 41610
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: RocPro Extended Address programming issue

Post by rjversluis » 02.04.2018, 06:57

Hi,

OK, fixed.
The new address is saved in the loco properties after the CV18 has been written.
13790+

rjversluis
Site Admin
Posts: 41610
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: RocPro Extended Address programming issue

Post by rjversluis » 02.04.2018, 10:02

Hi Peter,
peter&basti wrote: But until now i used short addresses only.
as expected because in this case only one CV value changes.
In case of a long address there are two CV values which must be change.

However I do not know how the decoder react in case it has already a long address and CV17 changes by POM...
If CV17 would be active instantly, the CV18 POM write will fail because the loco address is no longer the same as with writing CV17.

rvooyen
Posts: 973
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: RocPro Extended Address programming issue

Post by rvooyen » 02.04.2018, 11:51

On esu decoder cv 29 bit 6 (32) activates and deactivates a long address. There are always two addresses on a loc, the short in cv1 if bit6 of cv29 is 0 and the long in cv17and18 if bit is 1.

Robert.

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: RocPro Extended Address programming issue

Post by Dagnall » 02.04.2018, 15:01

Thanks all, I sent the message last night and did not expect such a big discussion!
I was surprised that the issue had not been seen before, but I suppose many people just use short address, when it works fine!. - or had not dug deep enough to find out why they were having errors. I was lucky that my home brew decoder could tell me exactly what was happening so I could debug the issue.

Rvooyen and Peter&basti do seem to have spotted an additional issue: RocPro seems to (Immediately) assume that if you set a long address you will be using long addresses for communications immediately afterwards... and It does this without taking CV29 bit 6 into account.

This extra issue (as I see it) is that RocPro changes to using long addresses even if you have not set CV29 bit 6 to "long address", so the decoder will be looking for messages to the short address, but RocPro is sending them to the long address.....
The work around when initially setting long addresses (but untested!) is to first set the long address to the same address as the short address, and then set CV29 to "long address", and then change the long address to the address you want....

I am not sure exactly how all commercial decoders are expected to work, but I would logically expect them to respond to a message to address (say) "3" if they had "3" set as either short or long address regardless of CV29 bit 6.

But, if they had "3" as the short and "200" as the long, andCV29 bit 6 set, I would expect them to onlyrespond to messages addressed to "200"..... Perhaps some of you can test this?

If my logic is correct, then RocPro should look at Bit 6 of CV 29 and use either the short address (CV1) or the long address(CV17/18) for communications with the loco.
More coding for Rob :coding: , but it ultimately might make for more convenient / conventional behaviour from RocPro.

I'm eagerly waiting for the 13790+ builds to do some testing!...(sorry that this may add a little extra coding!)

Huge thanks
Dagnall

rjversluis
Site Admin
Posts: 41610
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: RocPro Extended Address programming issue

Post by rjversluis » 03.04.2018, 06:20

Hi,

RocPro uses always this address and does not care about CV29.
There is no long/short address in the loco properties.
And how should RocPro read CV29 with POM if this address is not correct?

Dagnall
Posts: 278
Joined: 15.05.2015, 14:41

Re: RocPro Extended Address programming issue

Post by Dagnall » 03.04.2018, 11:39

Rob
Good point!.
Rocrail has to make its best guess as to which address (cv1 or cv17/18) the loco decoder is using.

I have just tested v 13791 and I can confirm that my suggested "Set Extended Address work around" does work.

Code: Select all

Starting with a Loco using a Short Address 
Check that CV 29 bit 5 is set 0 (if you can) {this is not possible when POM, but gives confirmation that the loco CV settings can be set and changed and that there are no other issues};
Set the Extended Address to the same address as the current Short Address.
Set CV29 bit 5 to 1;
Change the Extended Address to the new (Long) Address.
I guess you can mark this one "Solved"... :beer:

Thanks
Dagnall
PS I have uploaded a Zimo decoder xml in English to the wiki (as a zip) to add to the German version.
I have attached a RocPro decoder xml for my ESP8266 based sound decoder here, not sure where you may wish to put this?
Attachments
ESPMQTTSound.xml
Decoder file for ESPMQTTROCNETSOUND decoder.
(2.69 KiB) Downloaded 2 times

Post Reply

Return to “General”