one approach for remote (processor) control of Tortoise switch machines uses a latching relay and relay driver (ULN2803) (relay coil requires ~200 ma). A latching relay avoids the need to constantly drive the relay, minimizing relay coil current. The relay and driver boards may be separate commercial boards.
i think a more economical and spacewise alternative is to use an H-bridge (L293).
an H-bridge can be driven with lower current digital outputs and with two outputs, reverse the polarity allowing a single 12V supply to be used to drive the tortoise (two outputs are required for a latching relay as well).
an L293 is a dual H-bridge that can support two Tortoise machines. If an MPC23017 16-Bit I/O expander were used along with four L293s, eight Tortoise machines could be supported. Of course an H-bridge could be used in other applications requiring higher current or polarity reversal, as well as simply on/off.
greg - Philadelphia & Reading / Reading
I don;t think you even need to go as complex as a H bridge driver - the SMC12 stall motor driver that's part of the CMRI system uses an LM324 quad omp amp, each LM324 drives 2 tortoises. It's only possible because the Tortoise current draw is so low. They're just used as inverters - an LM339 would probably work as well, but me and LM339s don;t get along for some reason (I think the school lab had a batch of bad ones, had to go through dozens to get my senior project to work)
https://cdn.shopify.com/s/files/1/0947/9088/files/SMC12_Parts_List.pdf?10562711970168125787
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
I have to wonder if adding so much extra complexity to save a few milliamps is worth it. What will this do BETTER than normal Tortoise wiring?
It takes an iron man to play with a toy iron horse.
what is normal (remote) wiring?
how is polarity controlled with op-amps? now i see. why aren't they wired as inverting drivers?
is complexity measured by the circuit in the chip or the number of chips, relays?
nothings seems simpler for non-remote operation of Tortoise machines than a dpdt switch wired as a reversing swtich.
remote operation of dual coil machines would need higher current and the ability to turn off which could be done w/ an h-bridge.
I don't really have any thing to offer here except a question.
Remote operation? What kind of processor and why is it needed?
Every CTC turnout on my layout is controlled both on the CTC panel and at a local tower panel....without any processors, just simple ice cube relays.
Position is reported, and position status is used for signal logic.
Even if one is going to use a processor for signaling, just as much wiring is required with or without processor to control the switch machine.
The processor must control some second level circuit to handle the current - why not just switch that current directly?
A simple motor starter push button circuit allows unlimited sets of push button stations with status lights.
Why are we concerned about current useage? It's a model railroad, not the space shuttle?
Sheldon
RR_MelI’m surprised that Atlas or other major manufacture hasn’t come out with a servo type switch machine
would it be integrated into the switch plastic or have to be mounted separately under the layout.
would Atlas marker something similar to TAM Valley driver?
could you drive a servo to either extreme simply by having two pulse generators: 1ms and 2 ms, and use a switch to route on the other to a servo to push from one position to the other?
ATLANTIC CENTRALRemote operation? What kind of processor and why is it needed?
much of the Pacific Southern Railway (PSR) is controled by a dispatcher using custom software on a PC to control turnouts and signals and read occupancy detectors and turnout position using C/MRI-like nodes and the above mentioned latching relays.
the New Haven RR uses an Arduino to control Tortoise machines to establish a route thru an interlock using momentary switch at either end of a route to select the route (i.e. diode matrix-ish).
ATLANTIC CENTRALEven if one is going to use a processor for signaling, just as much wiring is required with or without processor to control the switch machine.
the PSR is 90x45'. It is impractical to route wire from all turnouts controlled by the dispatcher to the dispatcher hut, not to mention use panels to mount them.
the PSR has separate graphic displays (above) for monitoring and controlling different sections of the layout.
the C/MRI-like nodes on the PSR provide as much as 24 inputs and outputs. Nodes are connected using a duplex 3-wire RS-422 bus requiring a single serial interface to the PC in the dispatch hut.
ATLANTIC CENTRALThe processor must control some second level circuit to handle the current - why not just switch that current directly?
the PSR is 50+ year old and uses dual coil machines in the older sections of the layout which are driven using capacitive discharge units (CDU). The CDU inputs are remotely pulsed from C/MRI nodes.
It also uses relay boards (mentioned in the OP) to control tortoise machines. Yes, the latching relay coils require ~200ma to control 20ma thru the Tortoise, are pulsed using drive transistors from the nodes. The I/O node as designed are unable to change the polarity required by the Tortoise machines.
multichannel signal driver boards which minimize I/O by translating 3 I/O per signal aspect to individual LEDs outputs on multiple signal heads.
multi-channel (6) block occupancy detectors outputs connected to I/O nodes
ATLANTIC CENTRALWhy are we concerned about current useage? It's a model railroad, not the space shuttle?
you always need to meet the current restrictions of the tech being used. One reason for using latching relays to drive the Tortoise machines is so that they can be pulsed (200ma), rather than have to maintain that current.
Ok, makes more sense now. If you are dispatching and signaling with a PC, then driving the switch machines that way makes perfect sense.
I can see the reasoning on a layout that size, but I personally don't want any computer screens on my layout.
Thanks,
ATLANTIC CENTRALI can see the reasoning on a layout that size, but I personally don't want any computer screens on my layout.
the interlock doesn't use a screen. It's a foamboard panel with momentary switches and LEDs indicating turnout position.
I got involved because it wasn't doing what was expected. After we sorted out the issues, i was able to plug a 15' USB cable into the Arduino under the layout and reprogram it. No rewiring or soldering.
Later they wanted some special cases where just one button press would do something. Changed the code and reprogrammed the Arduino.
I don;t really want a computer screen either - it doesn;t fit witht he 50's era. But the realities of building a layout get in the way, so having a USS CTC panel represented on the computer screen is a reasooonable compromise until the layout is fully fleshed out, at which point a physical CTC machine can be built - it's MUCH easier to modify a few items on a screen when you realize that for proper operataion, another crossover is neeeded at a spot. If it were a physical CTC panel, yoou'd have to shoehorn in another column with signal and switch levers and a code start button.
On any sort of layout of reasonable size, it becomes impractical to run wires back from every turnout to the dispatcher panel. The real railroads didn;t do this, neither have many model railroaders at least since the late 70's when Bruce Chubb first started talking about the CMRI system. Surely there may have been others also on the bleeding edge as well, althought he original CMRI was highly centralized as well, with the IO motherboard connected usually via prallel IO to the host computer, and then packed full of cards with wires running all over the layout to block detectors, signals, and switch motors. Very messy, even with neat wiring practices. It was the later distributed multidrop serial nodea that made it more like the prototype systems, and even then, the nodes all required talking back to the main computer for logic, even for local function. That's sort of the point of the Arduino based nodes from MRCS - in fact they actually call it the cp-node, and there are some demos on their site of it handling the local logic internally, and only using remote inputs to line routes and for DS override.
As for commercial servo controls - there are several, Tam Valley isn't the only one, there are a few other vendors offering servo control systems ready to use, and now Walthers has gotten into the act as well. Even with the cost of an 8 bit microcontroller (depending oon how many pins you need, generally under $2 and sometimes under $1, and how inexpensive servos are, it's a very economical alternative to the classic Tortoise. And WAY less costly than adaptations of the Tortoise that allow you to just plug the parts together like servos do - there's no soldering with most any of the servo control systems, just plug the cables together. Once you start adding the cost of edge connectors for the Tortooise so the wires just plug in, and few of them actually properly fit (I always wondered what they were thinking with the Tortoise, they could have EASILY use a completely standard spacing AND drilled the holes through in a nice parallel row so the user could fit something like a Molex header but instead, all the holes are staggered), you really start getting up there in price. And still have to solder the wires to the edge connectors, though at least you don't have to do that under the layout.
Yes, for local control only, say turnout controls in the fascia for operation by users walking around following their train, a simple toggle switch is absolutely the easiest way to run a Tortoise. But if you need remote control, or computer control, or want to use momentary buttons - you need some sort of driver.
Another source for circuit ideas is on Rob Paisley's page, he has some Tortoise drivers using 555/556 timers. He also has some circuits to operate solenoid machines with a non-momentary toggle and also have position indicator lights. Tortoises are extremely easy to drive electronically, because the 20ma maximum current is well within the range of the output drive of all but the lowest power logic chips. Another reasoon to avoid those knockoff types that have been appearing lately, nearly all of then are 5-10x the current draw, and so can't be driven with the same sort of electronics.
RR_Mel Sheldon I’m in the process of cutting over to servos to operate my turnouts because my 30 plus year old Atlas #65 under the layout switch machines are failing, I’ve had three in the last year quit. By quit I mean they won’t cut the mustard anymore. They get to the point that they won’t hold the point rails to the outside rails, mainly because of plastic throw arm fatigue. I’ve been replacing the Atlas #65s with Peco PL-10s but the cost of the PL-10s has increased and using servos is overall cheaper in quantity than the PL-10s. The SG90 servo is $1.50 and a good price for a PL-10 is $10. An $8 Arduino Mega will easily control the 21 turnouts on my layout. The wiring to the switch machines for the servo is also 3 conductor. The MEGA will control my turnout indicator LEDs as well as the servo. The servo speed is also controllable by the MEGA. The servos do not take a lot of current to control, less than 2ma per servo. The control current isn’t a concern when using servos. The operating current of a servo can go quite high but it isn’t switched, the servo power remains a constant 5 volts. The Arduino (processor) will except any type of input (switched high or switched low) to operate the servo, push button, toggle switch or from a DCC controller. Greg For the cost of an Arduino to operate the servos I wouldn’t attempt making a controlled servo driver. The ability to control the speed of the moving rails and movement with a $8 processor is much easier. Mel My Model Railroad http://melvineperry.blogspot.com/ Bakersfield, California I'm beginning to realize that aging is not for wimps.
Mel,
I understand, but I have not used a twin coil machine in 25 years or more, and I have plenty of tortoise machines.
But mostly, I have no interest in using anything that requires learning/writing code/software.
Did that kind of stuff years ago for work, not interested now.
Since the hobby should be fun, I like working with relays, and they are cheap these days. So is the CAT5 wire to connect my various relay boards and control panels.
Most of my CTC turnouts are controls as whole routes, so for example, it only takes 4 lighted pushbuttons, and 3 conductors (plus the control power feed/common to the whole panel) to control the remote location of a double crossover or a pair of crossovers.
Back at the local panel, another set of push buttons, and those same three conductors, tie into a relay panel that uses three relays, one for each possible route.
The relays are located near the interlocking to minimize wire runs to/from the local panel and the switch machines. The relays drive the Tortoise machines with a single form C contact set and a common ground +/- power supply.
The relays also direct track power, eliminating intermediate blocks, power frogs, and provide signal logic for the interlocking signals.
Signal logic is also simple. I use only interlocking signals and their approach signals.
A detector for each block, and the above mentioned turnout route logic provides the whole signal system.
All hard wired logic, most on bench build relay boards, with no more under layout field connections than solid state would require.
Randy, the trick is to de-centralize the relay logic.
ATLANTIC CENTRAL Randy, the trick is to de-centralize the relay logic. Sheldon
Now there might be something - replicate the protype in all respects. Though with modern subminiature relays, no need for those big slow moving types used by the railroads, and since lives aren't at risk, the spring in the relay should be fine, no need to rely on gravity to drop out the signal. With dead rail, you could even use a prototypical track circuit for detection, though doing so would render your dead rail locos incompatible with anone else's layout.
Still - it is just SO much easier to adjust logic by editing a line or two of code than it is to rewire a chain or relays. There's a reason all-relay l;ogic has pretty much disappeared, and that's just one of them. Even if you get the relays for under $1 each, it will cost a lot more than using one of the $2 microcontrollers, given that hundreds of relays can be replaced by one - and OK, so it's $5 once you add the required supporting components to make it usable.
It's all a tradeoff of course, modern components make it almost silly to distribute things too much, but I am not a fan of many of them. Having one board detect 16 blocks may be economical in terms of component cost, but on a decent size laoyout, how close are any 16 blocks? You end up with lots of heavy lines running all over the place. At least the transformer type detectors allow you to just run thin low power signal lines from the detection area back to the control board. Same with signal drivers, the cost difference between one that can drive 4 signal heads and one that can drive 32 heads is nearly negligible. So you can sell a $50 product that runs 4, or a $100 product that runs 32. The only problem is - how often is there an area on a decent size layout that would have 32 signal heads close together? More bundles of wires running all over so you can get 8x the outputs for just 2x the cost.
I thought about making my servo controller run more than 2. But 2 is a good number - both ends oof a passing siding, or a single direction crossover. I have considered an alternative version for yards or other areas where there will never be remote control, only local buttons, but at best, I can control 3. It dooes use a relay for frog power - that's STILL the easiest way to have a low current device switch a high current.
Randy,
I only paid a $1 or $2 for all my relays.
I use one relay for each turnout roughly, they provide route selection, interlocking signal logic, and power routing.
I use Dallee inductive detectors which have an output relay onboard.
I use about 13 relays per block for DC cab selection and route verification. Without the route verification cab selection only takes 8 relays.
Those 8 relays are on a circuit board I had made.
Interlockings are actually automated X sections of all the converging blocks, so the number of actual assigned blocks is about half what you would normally think necessary.
There are no drivers for the signals, the actual signal power goes thru a simple logic chain - permission, detection, route - like the prototype they are red unless all three condtions are met. They are all interlocking signals, there are no intermediate blocks between interlockings. There are approach signals before each interlocking.
Relay boards, for turnouts or cab selection, are near the track work they serve, and a few cat5 cables daisy chain them, and connect them to the local towers and CTC panel.
Non CTC areas are even simpler, turnouts are manual but relays are still used for power routing and cab selection.
And remember, nearly 20 years ago when I developed this, much of what you are using did not exist.....
So the one button per route turnout controls with unlimited remote locations, frog power and interlocking logic only require one relay per turnout and the push buttons. That and the signals are fully DCC compatible.
A few more technical facts:
The relays have 5amp contacts, they switch track power, signal power, turnout motor power or control power with no additional circuits.
In the cab selection circuits, no more than 25% of the relays are energized at any one time.
In the turnout control circuits no more than 40% of the relays are energized at any one time.
RR_MelI’ve used momentary toggles to control my Atlas turnout switch machines since the early 60s so when I got my first Tortoise I went with a matching DPDT toggle. Everything matches and the operation is the same with the Tortoise toggle staying in the position as the turnout. Pretty simple.
Actually, it is not pretty simple...
Switches or levers in the DOWN positon indicate that the switch or signal is in its normal position. Moving the lever to the up position reverses the turnout or signal.
Normal interlocking signals are RED untill cleared by the tower.
Signals for westbound trains are on the left side of the lever row.Signals for eastbound trains are on the right side of the leverr row.
Switches are numbered from left to right.
The tower operator will align the switches, and then clear the signal for the next train to pass through the plant. Once the train has cleared, all levers are returned to their normal position.
It is very difficult for an operator to look at a board with levers both up and down and to know what is in the normal position and what is not.
That was one of the problems at Chernobl... some lights were blue (closed) and other lights were white (open) but there was no way to tell what was normal, and what was not normal.
ROAR
The Route of the Broadway Lion The Largest Subway Layout in North Dakota.
Here there be cats. LIONS with CAMERAS
rrinker I don;t think you even need to go as complex as a H bridge driver - the SMC12 stall motor driver that's part of the CMRI system uses an LM324 quad omp amp
shouldn't the circuit below work?
the resistors provide a reference level of ~2.5V. In either state, a digital output drives one op-amp hi (12V) and the other low.
4 LM324s and 8 connectors should easily fit on an arduino, controlling 8 switch machines.
looks like the LM324 can source 40 ma, but the LM339 only 20.
That IS the SMC12 circuit, just with a data pin connection and "Arduino" added. Should be able to get 4 plus connectors in the footprint of an Uno size shield. If exclusively for turnout control, I might go with a Nano plugged in to a board holding more than 4 of the 324's, since you have more than 8 outputs to use. The Nano gives you the extra analog pins from the surface mount ATMega328, too, so you could use those for your inputs to select routes, with logic in the Arduino code to line the required turnouts.
rrinkerThat IS the SMC12 circuit, just with a data pin connection and "Arduino" added
the schematic shown in fig 2 of the link you posted is not as simple. That circuit
i believe the differential voltage between the inputs can be 32V (datasheet).
i'm looking at controlling an interlock w/ ~30 turnouts using a few MCP23017. I'd like to pack as many 324s on a board with as few other components as possible.
The simple way should work - the difference is that in the SMC12, it's designed to be either left open circuit or have the input pulled low. The regular diodes are to set the control pins a diode drop above the reference so the comparators flip one way when there is nothing on the input. Pick the reference voltage properly and it should work with a standard Arduino pin. Looks like the max differential is 32V, so it should be fine swinging betwene 0 and 5, plenty of margin.
Looks liek they improved the part, or at least TI's production has improved, they were originally rated at 20ma source per output, mentioned in the CMRI document, but the datasheet you linked says 40ma. Either is fine for a Tortoise, but 20ma is running a bit close to the peak of a Tortoise.
If you really want to pack them in, you could always go surface mount and use the TSSOP ones
designed and built boards using an MPC23017 I/O expander and LM324s to drive up to 8 pairs of Tortise machines and have 8 programmable I/O pins.
three of these boards will be needed to support an interlock using panel buttons to select routes
Nice, those would work with my nodes, if I used Tortoises. All of my IO will be through the MCP23017, actually I am using the MCS23S17, the SPI version, so I can have the inputs on a differnet chanin than the outputs, by using two different pins off the micro as chip selects. Looks like you build in room for that, you have a third terminal at the I2C connector and plenty of room between thew two traces to run one over from the CS pin, which is an NC pin on the I2C version.
I have instead pushed by turnout drivers off board, mostly because of all the extra features on my servo board, with local buttons and indicators, and the relay drive. The 4 digital inputs can be connected to any 4 digital outputs on the node boards.
A servo drive one should be possible, there are several multiple PWM output chips with I2C. Mostly meant for LED control, but the servo input for the position draws almost no current. Most of the ones I keep finding are available as SMD only though. Though I found JLCPCB also does SMD assembly for cheap - my servo board could be even smaller and neater if I repalced all the pullup and protection resistors and caps with SMD ones and had them assemble them. The micro, large capacitors, connectors, and relays I would leave as through hole and do myself
Just need to move a few labels - I did the same thing on my board the first time. Hard to catch because I didn't have 3D models of the components that blocked my labels.
rrinkerI am using the MCS23S17, the SPI version, so I can have the inputs on a differnet chanin than the outputs, by using two different pins off the micro as chip selects.
don't understand the benefit of additional chips and complexity (and see below)
i had originally thought I would need much more I/O for both buttons and LEDs and had actually designed a board with 2 expanders (4 ports) and using only 1 port to control LM324s. (yes these boards would be custom for this application)
seemed pretty obvious that since I had some outputs specifically for controlling the LM324s that they could be on one 8-bit port and the generic I/O on the other. The generic I/O can of course be used for either input or output.
rrinkerI have instead pushed by turnout drivers off board, mostly because of all the extra features on my servo board, with local buttons and indicators, and the relay drive.
this board replaces 3 boards in an interlock already built: expander card, darlington driver plug-in adn relay board.
Of course I2C boards w/ different capabilities (e.g. servo) could also be inserted into the chain to provide the appropriate mix of capabilites.
rrinkerThough I found JLCPCB also does SMD assembly for cheap - my servo board could be even smaller and neater if I repalced all the pullup and protection resistors and caps with SMD ones and had them assemble them.
does board size matter if mounted under the benchwork?
the economy price from jlcpcb is for 4"x4" boards. I realized, that was large enough to fit 2 of my boards.
the circuitry for the existing east interlock is somewhat large and mounted under the bench, requiring wiring both switch machine and button connections between it and the operators panel, I think an arduino nano and 3 of the LM324 boards could fit in the operator panel as a strip, minimizing wiring.
and in order to minimize clutter, i'm thinking any wiring between Tortoise connections and switches in the operator panel should be wired to the nearest LM324 board and let the firmware deal with their location on board, port and bit.
I believe that firmware is already written (simulated). It has tables using symbols to identify button pairs and list of turnout and positions for each route. The symbols refer to separate tables identifying the button and turnout board, port, bit and bit state for turnout positions.
thanks to Randy for making me aware of the MPC23017 and using an LM324 for driving Toirtoise switch machines.
Only reason I would want to make the board even smaller is to save on board cost, but I doubt I could shrink it enough to pay for the SMD assembly. And I don't really want to play around with making my own reflow oven and trying it all at home, pretty soon the electronics and assembly would be a full time hobby and not time left to build a layout. My servo boards are fairly large because of the RJ45 jacks to connect panels, the relays, and screw terminals for the frog wires. I still haven't decided on what type of terminals I will use on the node cards, so they may turn out significantly smaller, in which case I could panelize.
I'm not adding any extra components by using SPI vs I2C. By using SPI and two different CS lines, it simplifies the code - I can have one routine that writes the output bits to the output port expanders, and another that reads the input bits, without worrying about keeping array elements straight or anything. I don't plan on doing much if any multiplexing on the signals, one bit per LED, rather than say 3 bits to feed 7 aspects plus dark to a signal head that has logic in it. And each node will handle a crossover, with OS detection plus both mains to either side. Multiple dual head (maybe even 3 head) signals, drive the remote control and remote lock inputs to the turnot controller, and inputs for the status output of the turnout boards. A node in the helix will tack progress and drive indicators. A node in each staging yard will show track occupancy.
The other thing is that all my nodes will be identical, at least it terms of firmware. If I need fewer ports at a location, I'll leave off an MCSP20S17 or two, but the firmware will always expect the same number of expanders. Blank ones will just return all 1s since the pullups on the SPI bus should return 1. These means my nodea are not truly CMRI compatible, and won;t work (most likely) with JMRI, but my software will 'know' (because I will program it thusly) how many ports each node address has. Instead of having the config and setup packets to tell the node how many of each port type to assign. I will know that, say, node 5 only has a single expander on inputs, so just 2 input bytes, instead of 4, so when reading a packet from that node, only the first two bytes actually contain useful data. It also keeps the write and poll times consistent - I will always write the same number of bytes to each node, and the poll will always return the same number, so it will take the same amount of time to write each node and to poll each node, regardless of how many ports are actually present. But the whole idea is that my 'standard' size one will be the one for 90% of the locations, and only a few will save a dollar or two leaving off an expander chip, bypass cap, and connector.
The other option I suppose is make the whole thing up out of multiple smaller boards. Each board would certainly be smaller, but then I'd need to interconnect 3 or more boards to make up a standard node, vs just having one larger board and leaving off unused components when assembling it.