Slowing down a loco

[WIMorrison]

I have just created a loco out of bits from various previous models that have ended up in my ‘to fix’ drawer I’ve many years and to my surprise it runs like a dream - but with one issue.

the top speed is a scale 174kph which for narrow gauge is a tad too fas, especially when the prototype was 40kph! To bring it down to 60kph I have set the top end of the  speed table to 75 and the bottom end is at 10 which gives me 4kph - a reasonable and acceptable top and bottom.

 

it would nice though to have a greater variation in the speedsteps and I wonder if anyone knows of a setting in the Zimo decoders (mx 617) to slow the motor down other doing what I have done?

 

i will let it run as is if there aren’t any suggestions as it runs very sweetly - it should do as all the bits are well run in over many years!

 

iain

Edited May 16, 2019 by WIMorrison
Added image

[NIK]

Hi,

 

Could you expand on what you mean by greater variation in the speed steps?.

 

Regards

 

Nick

[WIMorrison]

There are only 65 decoder steps used within the decoder rather than 255 which means that each speed step on 28 speed step controller is just over 2 decoder steps, if I change to 128 speed steps then the decoder will step in almost 2 decoder notches for each controller speed step.

 

normally you would get 9 decoder steps for each 1 controller speed steps on a 28 step controller or 2 decoder steps if using 128 speedsteps on the controller

 

result is that the control is much coarser 

[pauliebanger]

I would set CV5 and CV6 and any others you have changed back to their defaults, (1 in each case) and use the default 3 point speed table. (CV29 Bit 4 = 0)

 

The simplest way to reduce top speed on ZIMO decoders but retain full range on your Throttle is to reduce the value in CV57. This is not the primary purpose for this CV but ZIMO recommend this approach. Suggest starting at values around 60, lower to reduce top speed further, higher to increase top speed.

 

There are specific reasons why this is prefered for ZIMO sound decoders, but the action applies equally to non sound decoders.

 

Best regards,

 

Paul

Edited May 16, 2019 by pauliebanger

[NIK]

4 hours ago, WIMorrison said:

There are only 65 decoder steps used within the decoder rather than 255 which means that each speed step on 28 speed step controller is just over 2 decoder steps, if I change to 128 speed steps then the decoder will step in almost 2 decoder notches for each controller speed step.

 

normally you would get 9 decoder steps for each 1 controller speed steps on a 28 step controller or 2 decoder steps if using 128 speedsteps on the controller

 

result is that the control is much coarser 

Hi,

 

I think just because the difference between the top of the speed curve and the bottom end is 65 it does not necessarily mean the decoder will only change the speed in 1/65 ths increments. It may interpolate the speed table into its own internal speed steps (from min speed to max speed) and then if in 128 step mode then may change the speed in 1/128th or 1/256th steps.

 

As has been mentioned CV57 can be used as an adjustable speed divider.

 

Regards

 

Nick

[WIMorrison]

Quote

 

The CV57 suggestion has worked a treat, much better control and a straight line from 50kph all the way down to zero - well almost a straight line

[NIK]

1 hour ago, WIMorrison said:

The CV57 suggestion has worked a treat, much better control and a straight line from 50kph all the way down to zero - well almost a straight line

Hi,

 

I haven't tried the following but if you have a good DCC command station and low resistance wiring you could try:

 

Set CV #57 back to default.

 

Use CV#66 (forward trimming) and CV#95 (reverse trimming)  as speed step multipliers.

 

Regards

 

Nick

[WIMorrison]

The forward and reverse trim are to enable you to get the same speeds in both directions which isn't an issue for me in this case  

 

My issue was (now solved by using CV57) that the speed was stupidly high and even on a toy train layout it would have looked wrong, much more realistic now that it has a max of 45kph set in iTrain and a full range is speed steps within the decoder.

[Phil S]

I thought this had been posted last night - but obviously not 8-(

 

You may be making a fundamental error in assuming that the 'internal speed steps' are the same as the 'external control' range ??

Whilst most manufactuers do not reveal their internal coding,  one aspect that LGB ( and therefore Massoth ) revealed about the inner workings of THEIR decoders, over 10 years ago, was that they used 1024 steps internally   ... and this was on a system which only used 14 extenal steps at the time.....  their point being that  accel and decel   cv3 and 4  used the additional steps when changing from one commanded value to another to smoothe transitions   ...

Equally we made/make  use of CV5 to limit the maximum speed to 1/2 or1/4  of full potential on our g shunting puzzles, but still have smooth control via cv3 and 4.   How many 'speeds' can a diesel or electric unit switching rheostats be set to  ??  Modern thyristor or similar units may be fully variable. 

[WIMorrison]

Phil

 

i am most definitely not confusing them and that is why I was trying to ensure that the full 255 binary steps are used and not a limited range caused by reducing the binary steps to only 65.

 

I wanted (and have now succeeded) to retain the fine control offered by using all 255 binary steps which will then be mapped by the decoder to whatever it uses (probably 1024 due to chip design).

[pauliebanger]

2 hours ago, WIMorrison said:

The CV57 suggestion has worked a treat, much better control and a straight line from 50kph all the way down to zero - well almost a straight line

 

That's because the default speed curve is not a straight line. To get a linear progression, CV5 = 254 and CV6 = 127

 

Best regards,

 

Paul

[WIMorrison]

You may have missed that I use a custom speed curve which provides me with linear control

[NIK]

1 hour ago, WIMorrison said:

The forward and reverse trim are to enable you to get the same speeds in both directions which isn't an issue for me in this case  

 

My issue was (now solved by using CV57) that the speed was stupidly high and even on a toy train layout it would have looked wrong, much more realistic now that it has a max of 45kph set in iTrain and a full range is speed steps within the decoder.

Hi,

 

Yes, but can't forward and reverse trim (changed to keep the same ratio between forward and reverse) be used as an alternative multiplier to the speed table?.

 

For example on the Zimo decoders change forward trim to 40 and reverse trim to 40 should give a top speed of 40/128 th of the top speed of the speed table.

 

Regards

 

Nick

 

 

[WIMorrison]

I think that CV57 is much easier, no calculation to bother with - simply change it, measure the speed and change again if required - simples