Just to make sure everyone is on the same page, remember slots are there to indicate the number of active locomotives tied to throttles. Depending upon the throttles in question and system being used, this can also be the limitation of the number throttles that can be plugged into the system at any given time. With that said…
The number of locomotives “running” on a layout has very little to do with the slot limit. As an example I’m currently using a Zephyr for two different layouts (a small N scale layout and my ever growing O scale layout), and I routinely have 20+ locomotives running at the same time, I just don’t have all 20 active in my throttles. In theory, the maximum number of locomotives (up to the 9999 address limit of course) that could be run on any DCC layout would be dependent solely on the amount of current you are supplying the layout with… [;)]
Yes, Randy’s info is informative and does point out the difference between peer versus polled.
At what point does a polled system get bogged down? Is it something to worry about if you are running maybe 10 addresses at once? Or does it take 100? Anybody got some experience with this?
I’d say it’s probably more than 10 in the case of the better systems - if it’s just throttles. Not sure what kind of additional load you get by putting sensors on the bus as well. NCE has the AUI and Lenz has similar devices. The systems with the polled throttle buses also have a completely different bus for command station to booster connection, which keeps the regular refre***raffic off the throttle bus.
From what rumors that I have been hearing is the Digitrax is working on a 512 or 1024 slot command station for the really large clubs as they are able to run out of the 120 slots that the DCS100/200 Super Chief system is able to put out currently.
Now with this many engine slots/keypads one would certainly wonder if the polled systems can keep up with this as the Digitrax system uses the peer to peer system.
I know that there is a limit to the amount of activity that a system can handle but if the 512 or 1024 is a possibility what is the limit? Although I would think that if you were running a thousand engines there would certainly have to be some slow down.
BUT on the other hand you have to remember that not every engine/train is going to be doing something (that requires any digital info) so at any one time only a third would not actually be in use.
I have watched on my home layout during my Ops sessions and I could see that about 1/3 of the trains are accelerating and another 1/3 are slowing down. The last 1/3 are setting still. So the amp draw is also only about 1/3 of the max available is actually being used.
And this would apply to the digital signal be generated also.
As for system amps available:
We have to get out of this idea that we have to figure for the max output of the command stations and boosters to match the max draw of ALL of the engines. When in actuality only 1/3 are accelerating and require anywhere their max current draw of the motor inside the engine. The other 1/3 are slowing down and the last 1/3 are not moving so they are using the minimum amount of an idle engine.
Now there is really no limit to the max amount of amps available to a layout as you can just keep on adding boosters and keep on breaking down the layout into different blocks.
So that thought, about max amperage, can be eliminated from any further discussion!
H4-Booster with 4.0 A permant power
NMRA DCC BiDirectional responder with integrated Cutout-Device
7" QVGA FSTN LCD Display with Touchscreen
32-Bit ARM 720T Controller, 64 MByte Flash ROM, 32 MByte RAM, Linux® Operating System
16 Bit Realtime Coprozessor
2 x Motorpowered Controller
2 x two way integrated -Analog-Joysticks ie whistle control
2 x 8 functionkeys as well as Stop- und Go-buttons
10/100 Mbit Ethernet-hub (RJ45)
1 ECoSlot-Modul for integrated remote control receiver
90VA
Software: DCC with 14, 28, 128 Speedsteps, LGB® support
Märklin® Motorola®old and new with 14 or 27 Speedsteps
up to 9999 Addresses in the DCC Format with up to 20 Funktionkeys per engine DCC support for up to:
16384 engiens, 2048 switches and1024 switchkombinations
32 Multiple lashups with up to 16 engines per lashup
and so on…
believe it and take a look at www.loksound.com… und the german flag… the stuff is so new they have not translated the details… but you see pictures and a graphicdisplay on how this is integrated with your current system…
From what rumors that I have been hearing is the Digitrax is working on a 512 or 1024 slot command station for the really large clubs as they are able to run out of the 120 slots that the DCS100/200 Super Chief system is able to put out currently.
Now with this many engine slots/keypads one would certainly wonder if the polled systems can keep up with this as the Digitrax system uses the peer to peer system.
I know that there is a limit to the amount of activity that a system can handle but if the 512 or 1024 is a possibility what is the limit? Although I would think that if you were running a thousand engines there would certainly have to be some slow down.
BUT on the other hand you have to remember that not every engine/train is going to be doing something (that requires any digital info) so at any one time only a third would not actually be in use.
I have watched on my home layout during my Ops sessions and I could see that about 1/3 of the trains are accelerating and another 1/3 are slowing down. The last 1/3 are setting still. So the amp draw is also only about 1/3 of the max available is actually being used.
And this would apply to the digital signal be generated also.
As for system amps available:
We have to get out of this idea that we have to figure for the max output of the command stations and boosters to match the max draw of ALL of the engines. When in actuality only 1/3 are accelerating and require anywhere their max current draw of the motor inside the engine. The other 1/3 are slowing down and the last 1/3 are not moving so they are using the minimum amount of an idle engine.
Now there is really no limit to the max amount of amps available to a layout as you can just keep on adding boosters and keep on breaking down the layout into different blocks.
So that thought, about max amperage, can be eliminated from any
If no action is taken then the system will send out commands on a scheduled basis. But when the operator sends out a command the message is then sent out on the Loconet and the appropriate decoder responds. At least this is the way I understand the system. I may be in error on the exact way it sends out the commands BUT!
Now I have had problems when I have had to do an OPS 39 reset to my system during an operating session. I had forgotten to reset the command station before the session began and we ran out of slots (had not reset the command station for 120 slots). As soon as I finished up the OPS 39 reset I informed all of the operators that they would have to reacquire their units. Also reminded them that they would have to re MU all engine sets.
So everyone was trying to reacquire their engines at the same time. The command station got confused real quick and some operators were acquiring some one else’s engines with their controller. Even though the controller had their engine number on the display they had another engine.
Now how did this happen? I really do not know but it happened on more than one occasion, so it was not a one time fluke!
All they had to do was Dispatch the engine and reacquire the unit by pressing the buttons on the Keypad again and everything was OK! The only thing I could figure out was that everyone was pressing the buttons at the exact same time and it would take place. Now considering the speed (frequency) that the Loconet is working at it seems funny that the system would get that confused but it did. Now this was way, way back in our early days of using DCC. So it could have just been a learning experience, I really do not know. And I have not had this happen in the last 2 years so maybe it had something to do with the early DT100 keypads. Also note that these were all Radio keypads so it is possible that it was the radio frequencies that got mixed up and sent the wrong command to the command station, even though th
yep the new system from ecos can run 32 times 16 engines at the same time… with as many throttles as you want… reason… they are using the ethernet as the new bus system… so the maximum length between throttles is now 100 yards…
it also has the new 1006 bidirectional nmra standard already in place… so feedback from the engines to the controller are now possible… something that maerklin introduced in oktober… you place an engine on the tracks and the engine sends it data to the controller which recognizes the engine and displays the functions, the name and all the rest on the touchscreen… each decoder has a unique MAC Address so even if you buy 6 identical engines from lets say athearn… the controller recognizes each engine individually… even if you move the engine to a new setup the engine send its data to that new controller and the new controller displays the same data… all without you touching a button… this is called MFX technology and the DCC world is talking about adopting this now too…
OK so now you’re gonna make me dig up a typical DCC packet length and then figure worst case to update X number of runnign locomotives…
Eventually there will be so many DCC packets being sent on the track that there will be a noticeable lag in response. And probably long before you’d have 9000 locos running. Even if it takes only 1ms to send a complete DCC packet, with 1000 locos that’s 1 second to send allt he messages. The only solution to this problem would be an entirely different transmission spec - faster data rate, mostly, since it would be hard to reduce the bit count of the packets - in fact to support LARGER addresses and more functions you will need LONGER packets.
This is why running a DC loco on address 00 results in delays when many other locos are running - the 0 bits get stretched out to produce the DC bias on the signal, and that means EVERY 0 bit in EVERY packet being transmitted - it takes longer to transmit the data packet. That’s a way to simulate a heavy load, if you have a DCC system that does 0 stretching - select address 00 and crank it up to full throttle, even if there is no analog loco.
Remember that while the slot limit of the command station certainly protects the command stations from dealing with too many decoders, all the command stations use the same method for transmitting and receiving packets (otherwise they wouldn’t be compatible with one anothers decoders). The peer to peer vs. polled architecture has a lot more to do with the way the systems network (buss) devices like throttles and stationary decoders communicate with one another than the process of dealing with the actual DCC packet being created and then parsed for feedback. I could be wrong about this, but I don’t think I am.
my club was at a show when we started getting slot max indications on our digitrax empire builder and couldn’t add any more locos to run. it turns out that one member in particular wasn’t dispatching or was improperly releasing his locos when he removed a loco from the layout and filled up the slots with loco’s that weren’t running on the layout. the empire builder has capacity for 22 addresses and throttles at the same time. there is an option in the db150 that will allow the erasure of the memory in the base that will remove all the loco’s that are stored there running or not. that solved out problem. we have never maxed out the power though. clearing the memory also erases the loco’s that are mu’ed. this doesn’t affect the decoders in the loco’s.
No need to do that [:D][:D] I am just curious if anyone has experienced a “maxed out” condition on their layout. My curiousity in this subject is not a theoretical one, but rather a practicle one. Does anyone have a Zephyer, Lenz 100, MRC PA, etc. and reached a point where the thing either was overwhelmed by their layout (lack of amperage excepted) either too many things running at once, or lack of expandability etc. Knowing this information would be, in my mind, a very useful set of data to know when one is deciding on a system and one that really isn’t addressed.
How things are seen by us, to me is very useful. As an example - you have made excellent points on the advantage of a computer interface. You use it and can make a good first person observation on the advantages of having it and the disadvantages of not having it. Many have commented on the different ways to make up and control a consit. This also is very useful.
I do not find comments such as “its more expandable” “you’ll outgrow it” etc as very helpful without having specifics.
I too am following this thread because Im looking to replace my Bachmann easy DCC. I am very concerned about expandibility. My layout is not that big right now, but as I expand I dont want to replace the DCC again. To expensive to do it again. I am looking at the Digitrax because of the signal and block detection options. I also have a very large train collection that Im adding decoders to and when my empire is finished I will need to run alot of them at the same time, so keep the info comming. Joe A.
The Digitrax platform lends itself well to expansion due it’s robust and fast system buss and probably has more ancilliary products devoted to this than any other DCC manufacturer right now. I can say that I use the block detection and signaling products, and both work very well. There are also a lot of good side effects once you implement many of these products as well.
Just do as much research as you can, and make sure you check out all the cool third party manufacturers, as there are some very cool and affordable products being produced from these guys.
i received today an answer from the technical support for the new DCC Commander called ECOS. pictures please visit the www.loksound.com website.
the answer is that the number of engines is not anymore limited and that the new commander uses a new intelligent system of communicationg with the engines.
engines that are addressed right now get the signal faster than any other engine. engines with a higher speed get addressed more often than slower engines. engines that run continously only get once in a awhile a refresh signal. according to them the number of engines that the commander can control simultanously is 16384 (!)… and the commander central station can communicate with as many handheld controllers as you want. no limit…
here the original answer from the tech support from ESU.
Die Anzahl der gleichzeitig steuerbaren Loks ist bei der ECoS - im Gegensatz
zu allen anderen derzeitigen Systemen - nicht beschränkt. Sie könnten also
theoretisch bis zu 16384 Loks gleichzeitig fahren, und diese würden aus der
internen Refresh-Queue auch stets Daten erhalten, also: Regelmässig
angesprochen werden.
Zur Verbesserung des Ansprechverhaltens und besseren Auslastung der
Bandbreite verfolgt ECoS allerdings gewisse Strategien, nach der Loks
angesprochen werden:
Loks, deren Eigenschaften sich gerade verändern, werden bevorzugt
angesprochen
schnelle Loks werden öfter angesprochen
langsame Loks werden seltener angesprochen
Loks, die Fahren, werden seltenen angesprochen bzw. nach einer gewissen
Zeit temporär aus der Refresh-Liste entfernt.
Die Anzahl der Handregler hat auf dieses Verhalten keinen Einfluss, allein
die Zentrale entscheidet über die Zusammensetzung der Gleissignale