Cant set up long address with Zimo 618N Next 18

[john dew]

I have programmed many Zimo decoders and this is definitely a first.

 

I have fitted a Zimo 618 (non sound) Next 18 to my new Accurascale Manor. On the Lenz programming track I can read the address as 0003 - when I change the address to 7801 the loco does the usual little shuffle and I can subsequently read the address back as 7801. However when I enter 7801 in the Lenz throttle the number is not recognised - "Fetching data" message ie unrecognised number!

 

The default CV 29 setting is 14 - I changed this to my normal setting of 34 but Lenz still failed to recognise 7801

 

I have reset the decoder a couple of times and if I do not change the default address of 0003 the Lenz throttle accepts that number and operates the loco perfectly (its amazingly smooth in fact)

 

I suspect I am missing some very simple step but right now I am totally baffled - any help would be much appreciated

 

Best wishes

[PaulRhB]

Odd that it can read it but not address it in control mode.
Can you enter other four digit numbers for locos not on the track without ‘fetching data’ showing? The three systems I’m familiar with allow you to enter an address even if the loco isn’t present so is this a normal response if it can’t find the loco on track as unless there’s railcom I didn’t think there was any feedback from the chip. Your cv29 value of 34 suggests railcom is switched off so I can’t see how it can fetch data from the decoder? 34 would mean 28 speed steps (value 2) and long address (value 32) as the only active bits. 

Asking as it sounds more like a control station glitch than the decoder unless that’s a quirk of the Lenz system. 
 

[john dew]

I can enter 4 digit loco #s not on track without a problem. "Fetching Data" only shows for numbers not recognised by Lenz - typically when I make an errot keying in a number

 

I dont use railcom and I disconnect DC hence the 34.

 

I wondered if it could be the Accurascale PCB?  have a Next 18 in my Dapol Manor maybe I should swap them over and see what happens?

[PaulRhB]

21 minutes ago, john dew said:

I can enter 4 digit loco #s not on track without a problem. "Fetching Data" only shows for numbers not recognised by Lenz - typically when I make an errot keying in a number

So what is prompting the ‘not recognised’ response when there’s no feedback from the chip?  If you can set codes for locos not on track but you can’t set this number it would suggest something is blocking the number from entering but if there’s no feedback I can’t see how it’s the decoder because it would be suggesting it’s requiring a confirmation to say I can’t talk to it. 
 

21 minutes ago, john dew said:

I wondered if it could be the Accurascale PCB?  have a Next 18 in my Dapol Manor maybe I should swap them over and see what happens?

Worth a try but I still can’t see what’s causing the ‘fetching data’ display unless the control station is in program mode. In control mode, without railcom, it should simply send commands and not get, or require, any response that would cause the error display. 

 

 

Edited October 3, 2023 by PaulRhB

[john dew]

I think Lenz stores the loco#s in memory somehow. I always get that message if I enter a number that has not been set up - I have to turn the power off to get rid of it.

 

If the default Cv 29 value is 14  does that mean long addresses are enabled? Its not something I have ever previously had to worry about.

[jpendle]

The Zimo CV29 default value of 14 means 28/128 speed steps , DC operation on, Railcom on, and short addresses stored in CV1.

 

So technically the default address is 3 NOT 0003.

 

If you then change CV29 to 34 and program a long address of 7801 CV’s 17 & 18 should end up set to 222 & 121 respectively. CV1 should remain at 3 as you haven’t re-programmed the short address.

 

If CV’s 17 & 18 aren’t being programmed then you’re not doing long address programming.

 

Regards,

 

John P

[john dew]

Thank you - I think I follow the logic although I havent come across this problem before - how do I programme the decoder to operate off 7801 with 28 speed steps on Lenz DCC? 

 

[PaulRhB]

You’ll find this cv calculator useful, long address calculator is beneath the cv29 one. 
 

https://www.2mm.org.uk/articles/cv29 calculator.htm

 

Your cv29 value is ok as long as you have cv17 = 222 and cv18 = 121 as said above. 
 

The only oddity is what you said earlier that you can read the long address which suggested 17 & 18 had been programmed. 
But the ‘fetching data’ appears to be within the command station because unless you’re in program mode there’s no way for it to get a response from the chip to be fetching data. Have you used long addresses before programmed from it or have locos been set up as long addresses by someone else? 

 

 

[john dew]

Thanks Paul that is very useful.

 

Cv 17 and 18 read out as 222 and 121 but I guess I need to set Cv 29 to 34 before entering the 4 digit number?

 

I can read the 4 digit number when on the programming track but when I switch to DCC running the throttle will not recognise the recently entered 4 digit number.

 

What is so strange is that I am very familiar with Zimo decoders and have Next 18 Zimos in the Dapol Manor, two Dapol Moguls and the Bachmann 94xx all were installed with 4 digit numbers without any issue at all.

 

The Next 18 I am attempting to install is brand new albeit not from my usual source. I will keep trying but I guess the last resort is to buy a Lokpilot from Accurascale.

 

Thanks again for all your advice

[PaulRhB]

Just trying to eliminate randomness 😉 The other thing to try is unseat and click back in the chip, it’s possible it’s not fully seated and that may disturb things. The fact you can read it suggests there’s no short so the chip doesn’t seem to be giving any indication of a fault with it. 

[Nigelcliffe]

19 minutes ago, john dew said:

Thanks Paul that is very useful.

 

Cv 17 and 18 read out as 222 and 121 but I guess I need to set Cv 29 to 34 before entering the 4 digit number?

 

 

Yes, that is correct.    But its very odd that your system won't just do things "normally".     Just maybe there's something around a stay-alive or similar in the loco that's pulling the power down, and your programming setup can't then cope with rapid sequences of several CVs associated with a single action.  

 

If the supplier is a reputable one, go back to them and ask what's happening.   The MN series decoders are new, and there have been a few small bugs in the firmware, most of them now fixed, but if you've got an earlier example if may be buggy.  They can be upgraded, but it requires a Zimo programmer, or a Roco Z21 system to do the update. 

 

 

[john dew]

2 hours ago, Nigelcliffe said:

 

Yes, that is correct.    But its very odd that your system won't just do things "normally".     Just maybe there's something around a stay-alive or similar in the loco that's pulling the power down, and your programming setup can't then cope with rapid sequences of several CVs associated with a single action.  

 

If the supplier is a reputable one, go back to them and ask what's happening.   The MN series decoders are new, and there have been a few small bugs in the firmware, most of them now fixed, but if you've got an earlier example if may be buggy.  They can be upgraded, but it requires a Zimo programmer, or a Roco Z21 system to do the update. 

 

 

 

Ah that may be it - Accurascale have stay-alive wired into the Manor PCB

[WIMorrison]

@Nigelcliffe the OP says is a 618n decoder which means it is a MX decoder and this is a solid decoder using proven firmware.

 

i think that the stay alive I may be the root cause of the issue.

[McC]

Worth bearing in mind the stay alive will need 14v or so to work but otherwise shouldn’t impact the normal running of the chip