As I construct my layout (N scale, Digitrax everything, Kato Unitrack, JMRI), I would like to introduce some automation later. For now, I am being generous in gaping the rails and track feeders so I can rewire later as needed to create blocks to support some automation. However, as I look closely at what it takes for equipment, the cost quickly goes up to the point that it will cost more than I am willing to invest.
My main desire is to allow one or two trains on the mainline to operate unattended in a continuous loop while I do switching off the mainline. However, some of my switching situations would require the switcher and some cars to enter the mainline to complete the switching maneuver. This is in a single operator (me) environment. To do that, I want all the mainline trains to automatically stop when one of them approachs a block occupied by the switching action and stay stopped until I clear them to resume. This will allow me to do all the switching that I want while the mainline trains operate in the background.
I can see how to do simple occupancy detectors at a reasonable cost but to be able to USE that info, I need to add transponding and other stuff such that the cost goes up quickly. Without the whole package ($$$$$), I cannot get all the info I need to tell mainline trains to stop before entering a specific block.
Am I missing something? Is there a budget approach to stopping all mainline trains when a switcher enters a mainline block?
Paul D
N scale Washita and Santa Fe RailroadSouthern Oklahoma circa late 70's
transponding is useful, but not necessary. You just simply cut power the a small section of track before the right light block.You can wire up your own IR or current detection blocks on the cheap. And if you are using something like a PSX-1, PSX-2, PSX-3, or PSX-4 you can use the occupancy information pin to throw a power relay. That way you get a breaker with occupancy.There are cheaper ways. There are websites dedicated to showing you how to build your own electrical circuits for train detection.
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
Don
I considered that but it only impacts the next train into the closed block. Since I expect to run two trains at same speed on same track (properly spaced), any train following it would run into the rear of the stopped train. My current plan is to manually issue a "all stop" command whenever I throw a switch to let a switcher on the main. Then when the switching work is done, I would resume mainline movement.
I'm pretty sure that JMRI's DispatcherPro will do what you want with just some basic block detection (no Transponding required). Everything else (signals, etc) can be defined in JMRI itself without any hardware needed on the layout:
http://jmri.org/help/en/package/jmri/jmrit/dispatcher/Dispatcher.shtml
For the block detection, there are several options that might be economical - C/MRI, RR-CirKits, etc.
For automation, you need 2 things: block detection and turnout control. Signals are nice but not necessary if your goal is just to have trains run around automatically.
At a minimum, the lead loco and the last car in each train need to be detectable - this will keep a following train from running intot he back of the one ahead, een if the one ahead overhangs 2 or 3 blocks. Resistors in the wheels are the usual way, but lighted ars and powered locos are generally all set with no additional modifications.
One final piece, a computer interface, either the PR3 or the Locobuffer-USB, and JMRI.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinker For automation, you need 2 things: block detection and turnout control. Signals are nice but not necessary if your goal is just to have trains run around automatically. At a minimum, the lead loco and the last car in each train need to be detectable - this will keep a following train from running intot he back of the one ahead, een if the one ahead overhangs 2 or 3 blocks. Resistors in the wheels are the usual way, but lighted ars and powered locos are generally all set with no additional modifications. One final piece, a computer interface, either the PR3 or the Locobuffer-USB, and JMRI. --Randy
When my old club was DC, they had working aspect ratio Pennsy heads that cut power to the track if you passed a red lightWith DCC you can tell the decoder to stop or slow down once it hits DC power. So you could technically have it slow down in a yellow block by throwing a relay and going DC on that section, and cut power entirely if in a red. This is a bit more complicated and you have to plan your block sections and sensors carefully.
Since I expect to run two trains at same speed on same track (properly spaced), any train following it would run into the rear of the stopped train.
Still needs to interface to the controlling computer someway, and the beam brak detectors are not nearly as foolproof for trains occupying a block when stopped - you need enough sensors so that a train, no matter how long or how short, blocks at least one sensor per block to the block is marked occupied. The check in.check out type (as soon as one sensor is blocked, block is mark occupied until second sensor is unblocked ends up needing a whole lot of logic to handle short trains, where one sensor is uncovered before the second one is blocked, or for reverse movement, where the train enters the block, then reverses direction back out the way it came without ever hitting the second sensor. It's doable, but is rather complex - detecting current flow is SO much easier and automatially covers the entire block. Point sensors liek the IR ones are great for things liek crossing gates but not so good for block detection.
With JMRI and others, the automation script can send DCC speed commands to the decoder and slow down, no need to mess with brake on DCC or asymmetrical DCC with the associated relays to switch the signal between regular for the train to move and the dc or half waveform to stop. ANd no need to worry about setting momentum on the decoders so that the train doesn;t slam to a stop and/or take off like a jackrabbit. Plus actually sending DCC speed signals means multiple units will all stop - power cutoff is like running a DC gap, the lead unit crosses the gap and gets the stop signal while the trailing units still have power and sit there spinning.
I will add, RR&Co seems more reliable for this sort of thing. Friend of mine si doing pretty much this to run a series of trolleys around a loop on his layout. The loop is divided into 16 sections being fed by a BDL-168, and 4 trolleys are set at various points and then run by themselves, stopping with at least a 1 block gap between the one ahead. I tried to build it with JMRO automation but I kept getting random false occupancy detections which totally messed up the script. Next time around, he had downloaded a copy of RR&Co for trial and had it working perfectly - and I'm the computer and electronic guy, he's a lawyer.
Looks like I need to do more study on use of JMRI for my situation. So far I know how to use it to control switches and create blocks but I have not jumped deeper into it such that I understand how to use block occupancy info to control stuff. I knew it could control signals but I did not plan to do anything along those lines for a long time so I have not spent much time looking at it for effective use of blocks for other actions. My layout (under construction) will already have all the gaps and feeders to support all the blocks I will need. I already have everything I need (PR3, dedicated computer, etc) but I need to get the widgets to support occupancy sensors for the blocks.
My layout is essentially a 45' dogbone (folded into a 8'x23' space inside a 26' travel trailer) so I can operate two mainline trains with at least 15' of separation. I will go for current sensing sensors as I am aware of the issues for optical or IR types.
Thanks for the info. Your info confirms that I can finish my current construction yet still be able to add block detection later without major track surgery or breaking the bank to add the additional capability I want.
As long as you have at least one rail gapped for detection, and all feeders for each section between the gaps canbe grouped together into one sub bus before connecting to the main bus, cutting in block detection will be easy. The transformer type detectors (look at RR-CirKits, for example) do not cause voltage drop like the diode detectors (eg BDL-168) and allow distributed connection - the BDL-168 is designed to have all the wiring to each sub bus (detection section) be home runs to the BDL-168. To add a detector like the RR-CirKits BOD-8 after the fact couldn;t be simpler - that jumper wire that links the main bus to the sub bus for the detection section - you put that through the donut hole and you're good to go. Each donut hole (which is a transfomer) hooks back to the main circuit board with cheap twisted pair wiring - 2 wires for each donut hole, or one pait out of the cable, cheap spool of Cat 5 or better Ethernet cable yields 4 pair per length.
The BOD-8 needs something to connect it to Loconet, it's designed to work with the Tower Controller but that has room for a LOT of connections and may be overkill, hence the price. The WatchMan is clightly more than the BOD-8 but it only needs an $18 adapter to connect to Loconet and detects 8 blocks PLUS has 8 more I/O's you can use - per the manual you could connect the BOD-8 here and then get 16 detection lines in one device.
I'm actually rolling my own controllers for detection, signals, and turnout control. More work but I am enjoying the electronics design. Like a track plan, repeated iterations until I get it right. I have a fairly good idea of what I want to do, I just have to make it all work. I plan on having pc boards made, as I will have too many to hand wire them all, and once I have it all working to my satisfaction I am more than willing to share the schematics and board layouts - I'm not going to go commercial and sell this stuff, but anyoen who wants to play around is welcome to use my Gerber files and have boards made for themselves. This is working for me because I have a few months yet before I can start the actual demolition of my basement in order to finish it the RIGHT way (with proper insulation and so forth, previous owner's efforts were, well, subpar is being nice) so that I can finally begine building my layout - assuming I finally decide on a track plan. I have what I think gets the most mileage in the space without narrow aisles and without looking like a bowl of spaghetti, after several iterations, but I'm not yet convinced it's the absolute best it can be. Plus all I have drawn out so far is the lower level main line, I've not yet fitted in industries, or even started the second level other than the staging which is just the identical arrangement as lower level, stacked on top.
My control system isn;t really meant for automation, it's to drive signals and support CTC operation, and it's not totally compatible with JMRI (unless I make changes to JMRI - but I seriously hate the Java language and instead I am building my own control software for it loosely based on CMRI). That's why it's not totally compatible with JMRI (which DOES support CMRI) - I've taken some liberties with the CMRI protocol which take out some of the auto-configuring capabilities but server to make the software a whole lot simpler. And since I know what I/O is used on each node - I don;t need any capability for it to report back to the control computer just what is installed.
rrinker As long as you have at least one rail gapped for detection, and all feeders for each section between the gaps canbe grouped together into one sub bus before connecting to the main bus, cutting in block detection will be easy. .......... --Randy
As long as you have at least one rail gapped for detection, and all feeders for each section between the gaps canbe grouped together into one sub bus before connecting to the main bus, cutting in block detection will be easy. ..........
Randy,
That is exactly how I am wiring it up "for now" so I can add the sensors later. I initially looked at the BDL168 (16 detectors and transponding capability) but was spooked at the cost to implement especially since I did not need transponding. A similar device (detection only) is the Digitrax BD4 (4 detectors) which links to Loconet via a DS64. The BD4 is much less expensive per detector if you already have DS64's to connect to (I have 14 in my layout) so that is the right way for me if I went 100% Digitrax. However, as you noted, the sensors are located on the boards thus it needs longer track feeder wires plus it more difficult and messy to add later.
I looked that the BOD-8 (plus 8 coils) and I like that concept much better with the coils on the rail feeders and some Cat5 wire to tie the coils back into something (aka Towerman) that will interface with Loconet. However, when I look at cost, it is more expensive for me than the Digitrax BD4 approach. Similar cost results for the Watchman. However, the CirKits approach is superior as a post construction add-on if you did the wiring right during construction.
If I understood your comments on use of the Watchmand and BOD-8 together, I think you are saying the I could use a Watchman (8 detections) connected to Loconet via a a"SSB-Adapter" and then plug a BOD-8 (8 detections) into the input connector of a Watchman to get a total of 16 detections for the combo. If correct, that did not appear to be a major cost savings over using all one or the other. I think it would also introduce some challanges for me in trouble shooting problems so I would shy away from that approach.
As I looked at the design of the BOD-8 or Watchman vs the DB4, I was hoping to see if I could use the BOD-8 or Watchman in lieu of the BD4 and hook them to the DS64 instead of the CirKits approach. First problem I encountered is that the CirKits signal went low during occupancy while the DS64 is expecting a high signal during occupancy. As a result, I did not see an obvious way but if someone else has already broke the code on this combo, I would like to hear it.
rrinkerWith JMRI and others, the automation script can send DCC speed commands to the decoder and slow down
Send speed commands to which decoder? You don't just need to know what blocks have trains in them. You need a way of knowing which train is in which block so you know who to tell to slow down.
Assuming I could count on the operator to input initial positions, I'm pretty confident I could come up with the script logic to follow trains through the blocks and keep track of who is where. The problem is going to be predicting and handling all the exceptions. I was taught that 10% of code is the base function of the application and the other 90% is exception handling. How many trains end up on the floor as we learn what exceptions we have to deal with?
Murphy was an optimist.
I have the right to remain silent. By posting here I have given up that right and accept that anything I say can and will be used as evidence to critique me.
JMRI has train tracking - as long as all blocks are detected, it just needs to know the starting potition. After that it tracks each loco as it enters and leaves various blocks, no Transponding or Railcom. As long as you don't 0-5-0 and not update the script accordingly, it's perfectly accurate, too. It does make the assumption that said script is what is controlling the movement of the trains, or at least there is some feedback of turnout position (automatic with Loconet, unless we're talking manual ground throws - but how are you going to truly automate a layout with manual turnouts?) so when faced with a choice it knows which one the train entered. It's also pretty failsafe, if a turnout from block 1 leads to block 2 and block 3, and the script things the switch is set for the train to go 1-2 and instead it goes 1-3, it stops rather than have a rogue train running around. This is why I had problems trying to do the trolley thing on my friend's layout, I kept getting false detections from his BDL-168 (and yes, it was wired correctly, the various feeds were NOT grouped together or run parallel, etc - JMRI just watching the monitor showed false detectsions, same hardware with RR&CO, no false detections - go figure) and since the script was expecting (per the design of the layout) the occupancy to go in order, block 1-16, if the train was in block 6 and suddenly block 13 went active, it halted since that meant something wasn't right.
PED rrinker As long as you have at least one rail gapped for detection, and all feeders for each section between the gaps canbe grouped together into one sub bus before connecting to the main bus, cutting in block detection will be easy. .......... --Randy Randy, That is exactly how I am wiring it up "for now" so I can add the sensors later. I initially looked at the BDL168 (16 detectors and transponding capability) but was spooked at the cost to implement especially since I did not need transponding. A similar device (detection only) is the Digitrax BD4 (4 detectors) which links to Loconet via a DS64. The BD4 is much less expensive per detector if you already have DS64's to connect to (I have 14 in my layout) so that is the right way for me if I went 100% Digitrax. However, as you noted, the sensors are located on the boards thus it needs longer track feeder wires plus it more difficult and messy to add later. I looked that the BOD-8 (plus 8 coils) and I like that concept much better with the coils on the rail feeders and some Cat5 wire to tie the coils back into something (aka Towerman) that will interface with Loconet. However, when I look at cost, it is more expensive for me than the Digitrax BD4 approach. Similar cost results for the Watchman. However, the CirKits approach is superior as a post construction add-on if you did the wiring right during construction. If I understood your comments on use of the Watchmand and BOD-8 together, I think you are saying the I could use a Watchman (8 detections) connected to Loconet via a a"SSB-Adapter" and then plug a BOD-8 (8 detections) into the input connector of a Watchman to get a total of 16 detections for the combo. If correct, that did not appear to be a major cost savings over using all one or the other. I think it would also introduce some challanges for me in trouble shooting problems so I would shy away from that approach. As I looked at the design of the BOD-8 or Watchman vs the DB4, I was hoping to see if I could use the BOD-8 or Watchman in lieu of the BD4 and hook them to the DS64 instead of the CirKits approach. First problem I encountered is that the CirKits signal went low during occupancy while the DS64 is expecting a high signal during occupancy. As a result, I did not see an obvious way but if someone else has already broke the code on this combo, I would like to hear it.
Yes, Digitrax remains stubbornly active high on their devices when most of the world has shifted to active low pulldowns - even decoders work this way, the common blue wire is the + side and each of the function outputs switches to ground when the function is on, not the other way around.
As such, you'd need some sort of interface to use the BOD-8 with a DS64. Azatrax has a solid state relay module that can accomplish this, but that just further adds to the cost.
The BD4 is ok, if you have your DS64's spread out near the turnouts they control, at least all the wiring wouldn;t be home runs back to the booster. There is one caveat with the BD4, they don't recommend it for use with 'supersonic' decoders which is, well, everything except the cheapest garbage Bachmann motor only decoders, or REALLY old early DCC days decoders. Disabling it is not really an option, unless you want locos to buzz to various degrees, depending on the motor - or actually destroying the motor in the case of a coreless type like in a couple of those new Kato locos. The reason is false sensor indications. That's not because it's a diode drop detector, it's probably caused by the design of the coupling circuit that drives the microcontroller input on the board. I'd get just one and hook up all 4 blocks and see how reliable it is. False detections will blow any chance of reliable automation.
The Watchman can connect to Loconet with the SSB adapter, the BOD-8 cannot. One of each is less expensive than 2 of the Watchman devices, plus with 2 Watchmans there's be a total of 16 additional I/Os not being used. Hooking the BOD-8 to the Watchman is no more complex than using 2 Watchmans, and it's a stock setting in the Watchman config that the 8 extra ports are used with detectors. The whole combo of all needed parts, including the transformers, comes to about $130 for 16 blocks od detection. That's less than the BDL168, and only slightly more than buying 4x BD4s, for a superior detection system (no voltage drop, locate sensors where needed not in one central mass). A little over $8 a block - that IS budget unless you build it all yourself. Rob Paisley has a circuit that has an active high output that would workw ith the DS64, and uses only a couple dollars worth of parts per detector, but the transfomer the circuit was designed for is long out of production. He recommends some alternatives, but I don't know how well they work - one is vastly different in specs from the original so I can't imagine it works, but the others are close. It may take a little tinkering to get it to work but that's the tradeoff, It certainly would be cheap, probably $2-3 per block, not counting the DS64 since you already have those.
rrinker I kept getting false detections from his BDL-168 (and yes, it was wired correctly, the various feeds were NOT grouped together or run parallel, etc - JMRI just watching the monitor showed false detectsions, same hardware with RR&CO, no false detections - go figure)
Clearly, you need an interlocking tower and a relay room.
Automation of LION is 100% Analog, no digits were damaged in the operation of this layout. Count the relays, THAT is the number of blocks on the Route of the Broadway LION. (Him has 14 miles of tracks.)
Is Subway Layout, ten trains at a time run on the layout. The can only operate in on direction, mostly because another train will be a few seconds behind its leader. (about 180 seconds to be exact). Trains do leave and enter the railroad at the demands of rush hour service.
Needless to say, this was done on the cheap. The detectors are magnetic reed switches, there are magnets under the train to activate them. Do not put magnets under the locomotives (power cars) as that will interfere with the operation of the motors.
There are five conductors between the relay board and the layout:
1. Track Detection (Pulls The Relay)
2. Red Indication behind the train.
3. Yellow Indication in the second block behind the train.
4. Green Indication in the third block behind the train.
5. Start Timer to release the train from the station IF AND ONLY IF the block ahead of the train is NOT red.
These cables come from a 1920s vintage pipe organ that was removed from our church. I was given to people who will restore the organ, but they just cut the cables between the console and the organ. There is no plastic or rubber on these wires/cables. All just string wax and paper. Six bundles of 11 conductors in each cable leaves one rope for each station (since each station has an uptown and a downtown track. When I ran out of this stuff I bought a couple hundred feed of new 25 pair cat-3 cable.
Mostly the entire layout is made from found materials. Many of the relays were donated to me by a fellow model railroader on this forum. (Watch out for the LIONS, they look pretty hungry to me.)
Besides, LIONS do not understand DCC. If him had DCC him would still need ten operators, which him has not. Little Plastic motorpeople follow the commands present by the signals, the LION stays up in the interlocking tower at 242,d Street. LION uses a real time clock. Trains arrive/depart 242nd Street every 3-5 minutes.
ROAR
The Route of the Broadway Lion The Largest Subway Layout in North Dakota.
Here there be cats. LIONS with CAMERAS
rrinkerJMRI has train tracking
Cool. I didn't know that.
rrinkerbut I seriously hate the Java language
I take it that the JMRI implementation of Python doesn't overcome this issue?
Once I got in the groove, I found it kind of therapeutic to make resistor wheels - I already use only metals wheels in all my rolling stock so it was mostly a matter of sticking on resistors and connecting the ends with conductive paint. Given that a reel of enough resistors to do hundreds of cars was like $5, I wasn;t about to by pre-made resistor wheels. And I went overboard and put two resistor axles on each car - most of the other club members did 1 axle per car. Loco and caboose are ok if you model the caboose era AND you ae only concerned about properly tracking through trains. A local might not necessarily have the caboose at the end of the train.
Now, it might not be quite as easy with N scale, but then there is a reason, despite most anything I'd need to replica my era as far as locos and rolling stock now being available, that I am not switching to N scale at my age and with my vision issues.
IR can work, and work fine, it just needs more complex logic and stuff to handle all the possibilities. ANd I'd say at least 3 beams per block. There are commercial products, but the price adds up quickly. It's a handy job for an Arduino, if you are of the DIY type. Properly modulated, the IR beams will fairly immune to ambient light and you can adjust the logic to fit all the possibilities. And it would be cheap.
BroadwayLionBesides, LIONS do not understand DCC.
Then why do you post the same pictures we've all seen a thousand times in response to a DCC question?
Because the OP was asking about AUTOMATION. LION has Automation.
Besides LION *likes* showing off the pictures of him, esp to thers who may not have seen them yet.
See, here is a picture that you have not seen yet. This is a magnetic detector that fits inside of the guage. LION puts a length of tape over it to hide it and to prevent shorts.