Check the decoder manual for the specific decoder, but CV11 = 0 usually means "never time out" so it should work.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Think I'll leave well-enough alone, but it sounds like if I'd re-set CV11 to zero, that would have fixed the problem as well?
CV11 (in these cases) sets the length of time before the decoder "times out". If set to 1, it means "wait one second, and if you haven't received an instruction, then stop". If set to 5, it waits 5 seconds, etc. If set to 0, the decoders will not time out, they will run indefinitely. Some DCC systems send instructions several times per second, on a constant basis, others may only send an instruction every so often.
Brad
EMD - Every Model Different
ALCO - Always Leaking Coolant and Oil
CSX - Coal Spilling eXperts
Yup, strange stuff at least to me! Makes me wonder... if I had increased from 1 to 2 as opposed to 5, would I have had the same results? Think I'll leave well enough alone!
richhotrain Interesting, this concept of "sending packets". I have an NCE PH-Pro 5 amp system. Does this affect all decoders? I wish that I understood this more. What makes this happen, how often does it happen, what causes it to happen, and how do you resolve it? Rich
I also have a PHP system, and I have experienced this before, but only with older Digitrax DH120 decoders.
I adjusted the stop packet rate, and it fixed it.
ONLY problem is I can't remember how I did it any more see, it was 10 years ago and the "fix" was emailed to me from NCE!
Karl
NCE über alles!
Thanks to all for your suggestions. Brad, not sure if this is exactly what you were suggesting, but I checked CV11 which I believe has something to do with packet time outs, and it was set at 1 (by the factory, presumably!) I reset it to 5 (for no particular reason, other than thinking it needed to be increased by at least a few levels) on both locos prone to stalling, and the problem now seems to be fixed. Not being anywhere near an authority on dcc and cv's, I'm not sure why this appears to have worked, but I expect there are others out there who can explain. I also have a BLI SD40-2 with sound that doesn't have the stalling problem, and it's CV11 is set at 2 (again, by the factory), so perhaps CV11 being set at 1 is the problem. Thanks again!
There was a bit of discussion here: http://cs.trains.com/mrr/f/744/t/182056.aspx and here http://cs.trains.com/mrr/f/744/t/189784.aspx
Since CV11 is not a requirement, some manufacturers use it slightly differently. The most known example is the default of CV11 in Digitrax sound decoders ends up having the sounds stop periodically on other than Digitrax systems. The way Digitrax command stations work, in a client-server model, any loco that is selected always gets a constant packet stream. Other systems will skip sending data to speed up the throttle polling, if no change was detected from the last poll. They send as often as required by the NMRA specs and no more. The idea of this use of CV11 is so that when you dispatch or release a loco, it will no longer get data, and the sounds will automatically shut off - no need to do a shutdown or mute when 'parking' the loco, but since the Digitrax command station keeps sending data even if you set the speed to 0, you can wait on a siding and the sounds keep going, but when you tie up and release the loco at the end of a run, it will go silent by itself.
Put both engines on the layout, and turn on the headlights. Run one of them, but keep a close watch on the headlights. When the running engine stalls, does its headlight stay on completely, or does it flicker momentarily? Also, does the non-running engine's headlight flicker when the other engine stalls?
I'm thinking that what you are seeing is a brief short. It could be a loose wire brushing against something beneath the layout.
Since a Lenz system doesn't come with a power supply and needs one to power it, what are you using to drive the Lenz base station? The system is good for 5 amps, but if you are running it with a smaller supply you may be underpowering it.
It takes an iron man to play with a toy iron horse.
Did you actually clean the wheels or do they just look clean? Are these new locomotives or have you used them awhile. New locomotives sometimes come with an oily coating on the wheels that should be removed.
I suggest you clean the wheels with the fluid of your choice and also look at the internal contacts and clean them.
Peter
Alton Junction
That may be it. I keep forgetting Lenz and NCE stop sending packets if you don't actively do something with the loco. Easy to verify this, instead of just letting the loco run, either contasntly adjust the speed up and down, even just 1 step, or keep blowing the horn every so often, and see if it stops then. If not - it's the packet timeout.
I had a similar problem, Intermountain F units (QSI deoders) on CVP Easy DCC system. It was suggested that I check (I forget the CV #'s) but the CV's that control how long the decoder waits for the next packet. One should be factory defaulted to 0 (it will wait indefinitely), the other was for DC operation (on or off only, 200 millisecond delay, non-adjustable). I haven't changed the second CV (yet). My units seemed to have a mind of their own at times, they would stop (but lights and sound didn't), the engine sounds would even "rev-down", then resume motion at the previous throttle setting. It was also mentioned, something about adjusting the command station's refresh rate, but changing the CV's was a much simpler solution.
What I was trying to convey is that stalling is not just limited to turnouts, and that there is no pattern as to when it happens... it happens randomly.
After setting the 4 digit address set CV29 to equal 34. There could be a speed curve that is corrupted. This has happened to one of mine that drove me nuts for awhile. Activating the custom speed curve in CV29 would cause the same thing you are experiencing.
Pete
I pray every day I break even, Cause I can really use the money!
I started with nothing and still have most of it left!
richhotrain I am confused by the OP's apparently contradictory statement on stalling. In his initial post, he states " The track / wheels are clean, and this does not happen only on turnouts" In his follow up post, he states " No pattern with stalling.... very random". So, do the locos stall only on turnouts, or is the stalling totally random? And, when the OP states that "this does not happen only on turnouts", does he mean that it only happens on turnouts or that the stalling is not limited to turnouts? The answer could be critical. Rich
I am confused by the OP's apparently contradictory statement on stalling.
In his initial post, he states " The track / wheels are clean, and this does not happen only on turnouts"
In his follow up post, he states " No pattern with stalling.... very random".
So, do the locos stall only on turnouts, or is the stalling totally random?
And, when the OP states that "this does not happen only on turnouts", does he mean that it only happens on turnouts or that the stalling is not limited to turnouts?
The answer could be critical.
Rich
Rich:
Read what you wrote carefully. I think the OP was very clear on that point.
Dave
Lackawanna Route of the Phoebe Snow
Do the chuffing sounds stop with the motion, or does it continue with the chuffing plus all the other stuff?
If it wasn't a Lenz system it would almost 100% be the same address on two cabs issue, but since Lenz doesn't allow that, that can't be it. The fact that the lights stay on and the sounds keep going mean it is not losing power, the rails are clean enough, the wheels are clean enough, and the pickups are clean enough. Very puzzling, since if there is a mechnical issue causing the motor to bind up, it would do so on address 3 as well as any other address you'd care to assign.
You could check to be sure the decoder's CV29s are set to allow 4-digit numbers (assuming that's what you're using). You could try adjusting it to a low number, like the last two digits of the engine no., and see if it works. Maybe also adjust the CVs to not allow it to run on DC power. I think sometimes if the engine loses power for a split second, it can get confused whether it's on DCC or DC and that might cause it to stop (unlikely either is the cause here, but worth a try.)
Thanks for all the feedback / suggestions. To further clarify, I have only one throttle plugged in, and no duplicate addresses within. Mine is a small switching layout but there are plenty of feeders from the bus. Both locos are set for 128 speed step. No pattern with stalling.... very random. And, when stalling occurs, everything remains working (lights, sound, etc.) Loco simply stops for a couple of seconds, then starts again on its own. On the 0-8-0, I too thought the tether between the loco and tender might be the problem, and therefore separated the plug, cleaned the pins, and reconnected it. No luck! When it happened with my Trainmaster, I figured something else was going on. After I reset both locos to factory default, I did not re-program any cv's... I just ran them on cab 3, and for both locos things seemed fine at that point. It's when I program in the cab numbers (but making no other cv changes) that the stalling begins, but agreed that this shouldn't be the cause of any problems. Any other thoughts / suggestions?
MisterBeasley I think the locomotive address is a red herring. I can't see how that could possibly cause stalling. However, if you changed other CVs along with setting the address, that might have something to do with it.
I think the locomotive address is a red herring. I can't see how that could possibly cause stalling. However, if you changed other CVs along with setting the address, that might have something to do with it.
Equally strange is the fact that it does not happen when he resets the locos to factory defaults and runs on the short address. He says that it only happens when he programs to the long adress.
Hmmmm???
.
Stalling or just stopping? Sound and lights still on when stalled/stopped?
Check CV29. It could be set for 14 speed steps. You can also see the head light flash on and off if it is set for 14 speed steps and trying to run on 28/128. Earlier versions of the Lenz command stations would not configure CV29 automatically. Programming with an LH90 can be a pain in the neck. If you know someone in the area with an LH100 you could borrow it would be a whole lot easier.
I've got a Lenz system, too, with both LH-90 and LH-100 throttles. Lenz doesn't have the "2 cabs at once" issue because the base station only allows one throttle to be in control at a time.
Do these engines stall completely at random, or is there some pattern? You've mentioned that they don't stall just at turnouts, but is there anything about the other places where they stall? How do you feed power to your rails? It could be that you don't have enough feeders, and you're depending on rail joiners to transmit power over too many pieces of track.
Excellent advice from Randy (whate else is new... ), however in the case of steamers with a tethered tender, it is almost as safe a bet that the tether connection is the problem.
If the stuttering/stalling happens with a new or newly connected steamer, suspect the tether. BLI's tether seems to be hit and miss until you learn just how firmly you must seat the plug. I have gotten used to using light, an Optivisor, and long thin needle-nose pliers with the tines placed on either side of the wire bundle. I grasp the loco carefully and firmly around the boiler/cab, and keeping control of the tines to ensure I don't inadvertently squeeze them together, breaking one or all of the thin wires, I firmly push the plug as deep as I can into the receptacle. If the steamer still stutters, it has something else going on.
Other times, with the P2K 0-6-0 that I have, upon closer inspection I could see why the coupling seemed to be getting sloppier and sagging, with the resultant intermittent behaviour. It was that the coupler was coming apart! I took the opportunity to back out the tiny screw entirely, wipe the tiny pins with 600 grit paper with just the briefest and lightest of swipes, wiped with a Q-tip and alcohol, and then restored the cover and screw, but snugly. No more probs.
Crandell
Do they stall and then start up again withotu actually touching them? If so, you probably have accidently done the same thing that happens with Digitrax systems and selected the same loco on more than one cab, if that is possible with Lenz. There should be a procedure to reset the command station which should clear such issues. What happens is one cab says 'stop' and the other, the one you are using, is saying "go some speed" and as the cabs are polled, it responds to one then the other. That it doesn;t happen on address 3 means you've never mistakenly done this with address 3. If the run fine on address 3 and only act up when changing JUST the address to the cab number, then there's not much else could be wrong. If you ARE changing other settings after the reset, try just changing the address and leaving everything else alone. Just changing the address sets nothing that would affect any movement other than the address itself.
A couple of my H-O dcc / sound locos stall frequently (a Proto 2000 0-8-0, and an Atlas Trainmaster. The track / wheels are clean, and this does not happen only on turnouts. What's strange is that it does not happen when I reset the locos to factory defaults and run on "3"... it happens only after I program in the cab #. Per a mfr rep's suggestion I tried a "hard" reset (which is on a dc track), but that didn't work. I'm using a Lenz system (LZV100 with LH90 throttles.) My Lenz system is at least 8-years old and has never had upgrades, if that makes any difference. Any suggestions? Thanks in advance!