Looking to make a big jump into automated running of multiple trains. After a lot of looking around trying to do that using a Digitrax based layout would not work how I wanted, so I moved to the ESU ECos system and I think it can. The question is what other manufacturers have products in this space. Most of my decoders using TCS decoders are set to use RailSync as are all my ESU and Zimo decoders support this. At this time I have dropped Digitrax decoders and moved to TCS, Zimo and ESU to give me all Railsync. The issue is detection and signalling components. Having been in clubs that used Digitrax only, well that works in that application, and I have figured out Digitrax about as much as there is to know. And I know it can not be coerced to do what I want it to do. I am hoping the most of the wiring I have can remain in place, I can just cut the tacks into isolated segments and use the current track busses as is. Any advice is welcome!
Well I guess since no one has left any advice or comment, I guess I will document my efforts here. Step 1 - Determine the System, Complete ESU ECos Step 2 - Determine the number of decoders that will be needed, in progress Here we have a few things to consider First, how many decoders already support RailSync, that is about 40% of my locomotives. The rest are Digitrax and Lenz Silver Mini's. Also the earlier release of TCS decoders so I have a lot of decisions here. But with full automation/detection, we need to know where the end of the train is. The solution I came to was to replace as few mobile decoders as I can, mostly all the early Lenz and TCS decoders. These are units that do not support Forward and Reverse TRIM. Second was to look at the extremely large number of Digitrax Decoders in speed matched consists like ABBA F-Units etc. I can do this by adding a function only decoder like the ESU RailCom decoder. This is multipurpose because if can be used as a paired decoder in the locomotive as well as an end of train indicator. As a bonus for the passenger cars, the lighting units from ESU have the RailCom decoder onboard already. So while there will still be a fair number of replacement decoders , I will keep what is existing running and just use the RailCom transmitters as needed. Since I have lashups already speed matched, I will need only a few dozen RailCom units to take care of my locomotives consists using the Digitrax decoders. Third, look at the EOT cars, whether they are cabooses or some other type of freight car, I will need one to the RailCom transmitters here as well. That also means whatever the changes to car need like power pickup etc. So lots of metal wheels and axle wipers. The plan of attack now is to just get a handful of the RailCom transmitters and start on a few locomotives and EOT cars. Definitely the passenger lighting decoders too. These changes would be like building FastTracks turnouts, first few may be perplexing, but after that it gets easier and takes a lot less time. Next up is DCC on the rails and LCC on the layout...........
It seems to me maybe a little background is also in order so there is better understanding. I started with Digitrax and was pretty happy until I started running up against it limitations to much. Granted I saw the most issues with the dreaded Slots_MAX message we came up against all the time at shows with my Ntrak club. There were other issues that better bookkeeping could solve when running. But there was always something not quite right. About me, I am an Electrical Engineer, so when I see the words Command and Control, it means a little different to me. A true Control System does two things, it sends a command and waits for a response if the command was successful or not. It also has the capability to be queried at any time. What is missing in the Digitrax system is this command acknowledgement and feedback. In Digitrax, The decoder does not acknowledge the command, and to get the address you are actually sampling the datastream going to the decoder, the decoder is not "Broadcasting" its DCC Address. And since you are sampling that off the command, you do not have any idea if the command was accepted. Granted, this was splitting hairs a bit. And there is nothing wrong with how Digitrax did it. It works fine until you reach the Slots Max. They tried to solve this issue with the migration of the slots to be in the throttles, stored in the memory in the throttles. Again, this also has drawbacks. One of them is this only works with certain throttles and certain command stations. The weakness is because Digitrax is a fire and forget control protocol. This perfectly acceptable until you want to get into full automation, where you have both operator controlled trains as well as automated trains. If I was going to have to reinvest in new equipment, well it made sense to look at the market and evaluate the different systems again. RailCom is a true control system in that if you query the decoder it will actively answer your query. All communications between the command station and the device is a true conversation, not a fire and forget. I first started seeing RailCom on the Zimo decoders I was using on my Fox Valley Models locomotives with the 651- 6 pin interface. I will not go off on the tangent about how cool the Zimo decoders are, but Momentum Trim is pretty cool. Anyway about that time the first ESU Ecos system was released. Well a few more issues with Digitrax at shows convinced me there must be a better way to run trains and have full control at all times. The architecture of the ESU product was completely different. It did not have a slot architecture were you could come up against the dreaded Slot Max issue. But it was also new, and I was not ready to jump when it first came out. I will also admit it was about that time I started dropping Soundtraxx and going to ESU sound decoders. After a few years with ESU and Zimo decoders, I started to see the benefits I could have using one of their command stations. For a new system Zimo is awesome in every way, so is ESU. For me the price boils down to determining factor. ESU is a great deal more affordable than Zimo. They are similar in how they operate, they both offer a complete command and control system. I know I said DCC on the rails and LCC on the layout was next, but for that to make sense a bit of this discussion needed to take place.
DCC on the Rails - This focuses completely on the decoder and the locomotive LCC on the layout - this handles everything else essnetially. Occupancy detection, signaling, switching, lighting and whatever animation you might want. This shifts most of the burden of operations into the Layout control. This does two things, first it removes a lot of command protocols from the DCC signal so it has less to deal with and can be more attentive to the trains that are running. LCC is a bit of a difficult thing to really quantify because it is so wide open. It can turn on streetlights, work traffic lights etc. But it can also control train traffic. It can execute routes, signal moves and execute them to park a train in a siding. Slot the passenger train into the correct terminal track. Well here is the fun part, all of this can be controlled by using JMRI. JMRI supports both DCC and LCC and they work within the constructs (theoretically) of the operations elements in JMRI. So the master control brain is freeware. How is that for a change! Of course you supply the computer. I would recommend investing in a larger monitor, I use a 32 inch monitor and that really could be a little easier with a little larger monitor. But reality has to restrict somethings. So now you have the general idea, I am waiting on parts and as I get them, I will post more information and possibly a few photos and videos. I am not fully proficient at this but I aim to be very soon.
David, Even though I would probably never use RailCom, I always gain great knowledge from your posts. I will follow this thread with interest as I can always learn something, no matter how long I have been actively engaged in this "life long" hobby. Brian
Made a bit of a change, decided I did not need the ECos system because it was a bit of a waste since JMRI was going to do most of the heavy lifting. So I am opting for the CabControl unit instead. It is a smaller footprint and looks more like a booster that a controller. It has comparable specifications as the other unit and can be mounted under the layout and out of sight. As you can see it also includes a throttle with a TFT display. It has its own internal WiFi network but it is unclear if it will work with current smartphone throttle applications.
And now for the sad news I learned today, the manufacturers of RailCom devices for LCC are unable to get parts to design and build
David: Train automation is a fairly broad topic. Can you elaborate on your environment? Unattended display running for a museum or club? Trolley section separate from the rest of the layout? Home layout with CTC? And so on. Also, what is being automated? All trains? Michael Pennie
David, If you haven't bought your ESU Command Control System yet, may I suggest you rethink it? I was convinced this was the right system for me. They were in short supply and I finally found one at a show. I got to talking with the gentleman who runs Wildwood Station and he suggested that I try both it and the full system before I bought. He was kind enough to let me use both of his demo units. It didn't take long for me to realise that the full system had too many advantages for me to settle on the smaller on I've since added a Mobile II and a loconet converter. This is more for my friends who stop by, they can bring their Digitrax throttles that they are familiar with. I can use the odd loconet item, if I don't have ready availability to a Railcom equivalent. I'm still bouncing back and forth deciding if I'm going to use LLC or Loconet for control with JMRI. The factors I'm looking at are availability - at 72, I'm no longer convinced of my ability to roll my own. Will be following your adventures. Don
MRP - this is for a private layout to add animation that is auto controlled. There were just too many issues using Digitrax that I just had to move on to a better system. I have used remote loconet configurations before but they also had shortcomings. What is being automated are passenger trains or a long unit train. Freight and freight switching is what the operators, my friends and I, will be running. Or we may take a break and just watch the trains roll by....... This layout is modular for testing RailCOm and LCC before I make the big jump on my big layout. Don, I have already decided on the the Cab Control because in part this will be a demonstration layout of sorts as well. At 61, and as an Electrical Engineer I really want to have true Command and Control. Digitrax was a good starting point, but it is essentially a fire and forget system. It is not a true command and control system because there is no bidirectional communications. When looking to have some level of automation, you need to be in constant communications because an Occupancy Detection of a specific train on a section of track before a triple crossover needs to have the turnouts thrown for the proper route and when the end of the train is through the crossovers, they all need to reset to the straight through settings. There is not an event model in Digitax that will automatically do this based on the engine number in the locomotive and that same number in the end car of the train. I like the LCC approach because it can handle all the detection, routes and other animations and reports the progress back to the panels in JMRI to display on a large monitor. Availability of parts in the age of COVID is the big challenge. It just may derail my plans and I sell all my trains go sailing or something. As I have been told, that automobile manufactures are hoarding the needed chipsets, not sure how increased auto sales are a byproduct of the pandemic, but they seem to cram all sorts of computers in cars these days and I am not sure that is such a good thing. Give me a V8 with a Holley 4 Barrel Carburetor and a simple distributor for ignition, how I miss my 67 Cougar XR7 with the 427 CU Cobra Jet engine! No computers just power and fun. But it is what it is, and until the chip makers can fully recover, if they can fully recover, what will be available for RailCom LCC. ESU does may Railcom detectors, but they are not LCC, they are similar to all the other manufactures devices that are not LCC.
David I may have done what you are trying to do. Hard to say for sure. So, what follows may not work for you. My layout is CTC, so I had detection, signals and a live dispatcher to work with. The general idea is that when an automated train comes up in the schedule, the dispatcher activates it. After that, the train runs via computer control, and reacts to signals the same way a human controlled does. At any given point in time, there may be a mix of automated trains and human controlled trains on the layout. The automated trains are all of the run through type, running from one end of the layout to the other (staging to staging). The underlying hardware for detection and signal drivers is C/MRI, with the DCC system being NCE. The software is a programming language called Visual Basic 6. I didn’t find two way communication via some kind of transponding to be necessary, so no need to swap out decoders. You can find a fairly detailed write up at https://groups.io/g/CMRI-Users/topi...,0,0::recentpostdate/sticky,,,20,2,0,78742996 Some of it is necessarily C/MRI specific, but mostly generic Michael Pennie
I am looking at having JMRI/PanelPro be the engine that drives the automation. The layout is a bit tricky that this will go to in the future. But the reason I need to know the actual train number because the turnouts will throw based on the train number not necessarily the route. So I need to know when the first locomotive and the last car are through a specific detection zone, for example having a train coming into the staging tracks only throwing the one turnout in the yard ladder that it is supposed to park at, and the stop when the last car is clear of the turnout. This demonstration is setup for an N-Trak layout that 3 people will operate, where 6 or more trains will be running at the same time, with only two being controlled with a handheld throttle. The end result of this demonstration will show me if what I want is possible how I want it to run, before I tear out all the wiring on my master layout and convert it to be more automated than it currently is. And on that layout where I have several trains with 100 or more cars per train, this becomes very important to know more exactly what is going on.
