Now this is interesting. I have an under construction layout with Zephyr Extra and four locos:
Genesis GP 15 address 54
Genesis SD70 address 83
RTR p42 self converted to Tsunami address 1
Spectrum 4-6-0 address 85
My SD70 runs flawlessly with no issues. It's got 12wheel pickup. Spectrums does too, except a couple spots. But suddenly the other two are jumpy ALL the time. I am sick of cleaning ... I have a dusty environment admittedly, but I am fixing that right now.
Thoughts?
Clearing the 'slots' fixes issues with Digitrax systems as well. The Chief series system can hold up to 128 active addresses, and old ones do not always get 'purged' by users(using the'dispatch' function). This results in a 'Max Slots' message when trying to assign an engine from a throttle. Every two weeks we clear the addresses from JMRI(switch 36 on the system).
We also do not leave JMRI 'running' when we shut down the DCC system. For some reason, it hangs up the system when we power up the next time. This has happened on our old 600 mHz system and on our new 1.6 gHz system with 1GB on memory(XP on both). This just happened again last week - Someone left JMRI Decoder Pro running and shut down the DCC system before leaving. The next Wednesday when the system was powered up, we could not get the 'track power' started. Ending Decoder Pro released the hang and we could power on from the throttles as usual.
Jim
Modeling BNSF and Milwaukee Road in SW Wisconsin
cacoleAs soon as we realized what was happening, we established a new rule that all decoder addresses must be a number above 128. For a loco that has only a two digit road number, we pad it out to make it four numbers, such as 3232 in the above example.
Really unnecessary to do that. All you need to do is give those two digit locos a four digit address, filling out the first two or three digits with zeros. So the loco with the short address of 32 has a long address of 032.
Of course the argument might be made that it will be hard for some members to remember that there is supposed to be that added zero, to which my counter argument would be that it is just as hard to remember that it should be 3232. And somewhere along the way another member will show up with his Mudville and Phoenix GP40 with unit number 3232 and you'll have the same issue.
Clearing the stack was probably the main reason your problems cleared up. We recently encountered a different DCC problem at our club involving short two-digit locomotive addresses.
The North Coast Engineering PowerHouse Pro with ProCab Radio throttles that we use automatically assigns an internal consist address as each one is created, beginning at 128 and counting down.
We ran into an instance where a new Athearn Genesis locomotive had only the two-digit address of 32, and when that was entered into the controller another set of locomotives to which the NCE system had assigned its internal consist address of 32 began to also move.
As soon as we realized what was happening, we established a new rule that all decoder addresses must be a number above 128. For a loco that has only a two digit road number, we pad it out to make it four numbers, such as 3232 in the above example.
I recently began having problems with my large, DCC layout. I have a Lenz system and a fairly large fleet of locos, steam and diesel, from a variety of makers. One problem was that all of my BLI locos began hesitating badly while running. At first, I thought it was dirty wheels and or track. After extensive cleaning of both, the problem persisted.
The other problem was with my Lenz system. I found I could not assign either of my throttles to any new 4 digit address. I could assign new 4 digit addresses to my locos, and could switch a thottle to an existing 4 digit adress, but not to a new one. I discovered I could access new 2 digit addresses, but since I like to give locos the same address as their road number, this was a hassle.
I contacted Lenz's customer support line and was refered to a technician who knew immediately what the problem was. There is an internal stack in the Lenz system which stores each new address assigned, including any MU consists I put together. Since I did quite a bit of this, apparently I had filled the stack. He told me how to go about clearing that stack and instantly that problem was solved. What I quickly discovered was this also cleared up the problem with the hesitating locos. They all began running like a fine watch.
I'm not sure exactly why fixing the stack problem cleared up the hesitations with the BLI locos. I'm making an educated guess based on my days programming mainframe computers. The operating system would not load an entire program into working memory but would bring in a portion (page) into memory and work with that part of the program and then move pages in and out as required. All of this would happen in a few nanoseconds so it was hardly noticed. In my earlier days with slower machines, you would sometimes see noticeable performance degradation with multiple programs running at a time. What I'm wondering is whether the overfilled stack was eating up working memory in the system forcing it to swap commands in and out and the high end decoders, the BLIs, would hesitate while waiting for instructions from the system.
As I said, this is just a guess. I know just enough about DCC electronics to be dangerous. I'm curious if anyone else has experienced similar problems or if they would have a more knowledgeable opinion as to why this was happening and why it cleared up.