Arduino
Memory and the Arduino
06 June 2016 00:12 Filed in: Electronics
It's been a while since my last post, as I've been deep in a programming project and not working on anything else. It's model railroad-related, and I’ve written a lot of code, but as yet it doesn’t actually do anything and there's nothing really interesting to say about it. I’ll write about it when I actually have it doing something. Maybe next month.
But, as is usual for me, along the way I've tripped over a few of my own misconceptions, and learned a number of useful things. One of the latter is that I now know a heck of a lot more than I really wanted to about Arduino memory use, and in particular about how that changes in the Cortex ARM M0+. Since this version of the Arduino doesn't seem to be well-documented online yet, I thought I'd write up some notes about what I’d learned. This is fairly off-topic for a model railroading blog, but since a lot of what I'm doing these days relates to model railroad control and signaling systems using the Arduino and other microprocessors, it's not entirely off-topic.
And if you skip to the end, you'll find a useful function if you're programming one of these.
Read More...
But, as is usual for me, along the way I've tripped over a few of my own misconceptions, and learned a number of useful things. One of the latter is that I now know a heck of a lot more than I really wanted to about Arduino memory use, and in particular about how that changes in the Cortex ARM M0+. Since this version of the Arduino doesn't seem to be well-documented online yet, I thought I'd write up some notes about what I’d learned. This is fairly off-topic for a model railroading blog, but since a lot of what I'm doing these days relates to model railroad control and signaling systems using the Arduino and other microprocessors, it's not entirely off-topic.
And if you skip to the end, you'll find a useful function if you're programming one of these.
Read More...
Arduino Knobs
17 April 2016 01:01 Filed in: Electronics,Basics
This is one of those “interim posts” I mentioned at the beginning of the year, posts where I don’t have something yet in a state where I can really talk about it, so I focus in on one detail that’s been taking a lot of my time, as a form of update. But today’s topic, rotary controls for computer-based systems, is a generally useful one, so I don’t think you’ll count this post a waste of time. At least not if you are interested in this aspect of the hobby.
A rotary control, or knob, is a control that can select a continuous range of states arranged in a circle, such as the volume knob on a stereo. Any rotary control can also be laid out as a linear one, simply by straightening out the underlying mechanism (they have to be designed that way, but often are). In schematic diagrams, a linear symbol is typically used to describe either kind, since from an electrical perspective they are identical.
In model railroading the most common application for this kind of control is a throttle. My first power pack, an ultra-cheap kit pack from Tyco, had a linear control (actually it was rotary inside the box, but the lever sticking out the side looked linear to me). Later, my first good DC power pack (my MRC 501, which you can see on my Power Pack Testing page) used a knob, albeit a simple one.
But today, I need a continuously variable control for a digital system, an Arduino to be specific. And yes, it’s for a throttle, but I’m not going to talk about the actual project I’m working on, as it’s still in the early design stages and there’s nothing much to say yet. Instead, I’m going to talk about the various options for this one control, and then go into more detail about the one I’m using, seen in the photo above attached to an AdaFruit Feather M0 Proto (a type of Arduino) for testing.
Read More...
A rotary control, or knob, is a control that can select a continuous range of states arranged in a circle, such as the volume knob on a stereo. Any rotary control can also be laid out as a linear one, simply by straightening out the underlying mechanism (they have to be designed that way, but often are). In schematic diagrams, a linear symbol is typically used to describe either kind, since from an electrical perspective they are identical.
In model railroading the most common application for this kind of control is a throttle. My first power pack, an ultra-cheap kit pack from Tyco, had a linear control (actually it was rotary inside the box, but the lever sticking out the side looked linear to me). Later, my first good DC power pack (my MRC 501, which you can see on my Power Pack Testing page) used a knob, albeit a simple one.
But today, I need a continuously variable control for a digital system, an Arduino to be specific. And yes, it’s for a throttle, but I’m not going to talk about the actual project I’m working on, as it’s still in the early design stages and there’s nothing much to say yet. Instead, I’m going to talk about the various options for this one control, and then go into more detail about the one I’m using, seen in the photo above attached to an AdaFruit Feather M0 Proto (a type of Arduino) for testing.
Read More...
Investigating I2C
17 January 2016 23:21 Filed in: Electronics,Testing
Today’s post is going to be one of those interim ones I promised last time, where I report on progress made (or not), mostly about my work with testing the use of I2C as a short-range communications bus.
I decided to start with examining the code I’d written last spring, only to find that most of it was irrelevant as it was doing things the I2C hardware would do for me, or it had functional compromises I didn’t need to make now. About 90% of it got deleted, and I started working on something that would work with I2C, using a couple of my test programs to create a library that front-ends the internal Wire library used to directly control I2C. That’s working to the point that I can pass messages to/from the master, and detect damaged messages, but there’s a lot more to do.
Read More...
I decided to start with examining the code I’d written last spring, only to find that most of it was irrelevant as it was doing things the I2C hardware would do for me, or it had functional compromises I didn’t need to make now. About 90% of it got deleted, and I started working on something that would work with I2C, using a couple of my test programs to create a library that front-ends the internal Wire library used to directly control I2C. That’s working to the point that I can pass messages to/from the master, and detect damaged messages, but there’s a lot more to do.
Read More...
New Plans for a New Year
I'm going to usher in the new year with a new project, and try to get back to doing more frequent but smaller posts than I've done of late. I'm not quite back to railroading yet, although this is ultimately in support of that. But for the moment, I'm still playing with microelectronics. And today's post is just a summary of where I'm going and what I've done so far, which doesn't amount to much when you put it down in words.
I'm still thinking about and planning the next layout. Control systems are a big part of that, because I was never happy with the DCC-throttle control of turnouts I used on Sumida Crossing, and my attempt at a single big computer-driven system never got off the ground, and would have had some of the same issues if it did.
As you may have noticed, I've spent a lot of time looking at control bus systems over the last two years. I'm still on the fence about what to use, as I don't particularly like any of the current systems. LCC has promise, but so far that's all it has, and I'm not expecting much from it in the next couple of years; it's too new.
Read More...
I'm still thinking about and planning the next layout. Control systems are a big part of that, because I was never happy with the DCC-throttle control of turnouts I used on Sumida Crossing, and my attempt at a single big computer-driven system never got off the ground, and would have had some of the same issues if it did.
As you may have noticed, I've spent a lot of time looking at control bus systems over the last two years. I'm still on the fence about what to use, as I don't particularly like any of the current systems. LCC has promise, but so far that's all it has, and I'm not expecting much from it in the next couple of years; it's too new.
Read More...
Signals and Signaling with Arduino
I’m going to vary from my normal focus on modeling Japanese railroads today to talk about signals and modeling them in a more general sense. Heck, who am I kidding, there haven’t been many posts on modeling Japanese railroads of late. But I digress from my digression. Back to the subject: signals.
If you want to cut to the chase: I’ve written an Arduino library for controlling lineside LED-based signals. It’s only part of a complete signaling system that I’m working on, and at present you’d have to do more work to make practical use of it. But the code is public and can be used independently of anything else I’m eventually going to create; skip down to the end for details.
Read More...
If you want to cut to the chase: I’ve written an Arduino library for controlling lineside LED-based signals. It’s only part of a complete signaling system that I’m working on, and at present you’d have to do more work to make practical use of it. But the code is public and can be used independently of anything else I’m eventually going to create; skip down to the end for details.
Read More...
Occupancy Detection Yet Again
About fifteen months ago work on adding occupancy detection to Sumida Crossing stalled. That was in part because I’d planned to use the BDL168 detectors to also do transponding, and a few months earlier had abandoned that plan since I was unable to get that aspect to work reliably, even on a simple test track. The number of solder joints on the BDL was also a nuisance that caused me to put off further work.
Recently I’ve been rethinking my approach. The BDL168 is an amazingly cost-effective solution. Ignoring the transponding part, you get 16 detectors on a board that includes a LocoNet bus interface for US$120 (street price). That’s $7.50 per detector (if you can use all 16). That’s really hard to beat for a bus-connected detector. I’d originally planned to install one per table on the layout, and my cost would have worked out to around $10 to $15 per detector on average.
On the other hand, I’m thinking that I might want to move to either a OpenLCB/NMRAnet bus (if I want a feature-rich bus for the future) or a really dumb serial bus (like S88 or C/MRI). The latter is attractive since I can potentially interface to it with an Arduino, opening up some room for home-brew devices. Of course I could do that with NMRAnet, but today that requires a US$45 shield to add to the Arduino (or one with it built in), which kind of takes away from the appeal of using $10 Arduinos to do things like drive signal masts.
While thinking about this, I went off and started researching what was available commercially or as home-brew circuitry and software libraries for these busses and for doing occupancy detection with them, as the latter would be a good way to get my feet wet and solve my “don’t want to solder those #$@! BDL168s any more” problem.
But in the past week I’ve been sidetracked into looking at homebrew inductive-coil detection circuits.
Read More...
Recently I’ve been rethinking my approach. The BDL168 is an amazingly cost-effective solution. Ignoring the transponding part, you get 16 detectors on a board that includes a LocoNet bus interface for US$120 (street price). That’s $7.50 per detector (if you can use all 16). That’s really hard to beat for a bus-connected detector. I’d originally planned to install one per table on the layout, and my cost would have worked out to around $10 to $15 per detector on average.
On the other hand, I’m thinking that I might want to move to either a OpenLCB/NMRAnet bus (if I want a feature-rich bus for the future) or a really dumb serial bus (like S88 or C/MRI). The latter is attractive since I can potentially interface to it with an Arduino, opening up some room for home-brew devices. Of course I could do that with NMRAnet, but today that requires a US$45 shield to add to the Arduino (or one with it built in), which kind of takes away from the appeal of using $10 Arduinos to do things like drive signal masts.
While thinking about this, I went off and started researching what was available commercially or as home-brew circuitry and software libraries for these busses and for doing occupancy detection with them, as the latter would be a good way to get my feet wet and solve my “don’t want to solder those #$@! BDL168s any more” problem.
But in the past week I’ve been sidetracked into looking at homebrew inductive-coil detection circuits.
Read More...
September 2013 Monthly Status
September was an eventful month: work began in earnest on the “One Point Five Meter Line”, my short layout for displaying building models and showing off my Tram Controller. Additionally I made significant progress on the tram controller program, continuing the work I’d begun in August on driving multiplexed LEDs and, although I didn’t write about it, refining the sensor code to allow it to run faster.
The tram controller program itself is beginning to come together. It’s still a ways from actually running a train, but I’ve assembled the pieces and made a start on the actual logic that will know where the trains are and perform actions on them, based on the use of sensors and timers. After about six months of sporadic work, I can almost see the end in sight.
As usual I have more projects running through my head than I have time to do. There are a half-dozen buildings disassembled on my workbench (where they’ve been since May) waiting to be painted, lit, decorated, and reassembled. I’m hoping to make a start on those soon, with the completion of the benchwork for the One Point Five Meter line serving as a spur. Once I have a place I can put them, and wiring I can use to light them up and see how they look, I’ll be more interested in getting them done.
But despite the things not done, this month has a definite sense of accomplishment and progress, something I can’t say about the layout(s) every month. Read More...
The tram controller program itself is beginning to come together. It’s still a ways from actually running a train, but I’ve assembled the pieces and made a start on the actual logic that will know where the trains are and perform actions on them, based on the use of sensors and timers. After about six months of sporadic work, I can almost see the end in sight.
As usual I have more projects running through my head than I have time to do. There are a half-dozen buildings disassembled on my workbench (where they’ve been since May) waiting to be painted, lit, decorated, and reassembled. I’m hoping to make a start on those soon, with the completion of the benchwork for the One Point Five Meter line serving as a spur. Once I have a place I can put them, and wiring I can use to light them up and see how they look, I’ll be more interested in getting them done.
But despite the things not done, this month has a definite sense of accomplishment and progress, something I can’t say about the layout(s) every month. Read More...
Arduino Signals II - Video and Flickering
I’ve continued working on the code to drive LED signals with an Arduino. I’d previously discussed my approach, and provided the code I was using at that time. I’ve learned a bit since then, and cleaned up the code significantly. I’ll provide a link to the current example program at the end of this post.
Fundamentally nothing has changed. I’m still planning to use NJI common-anode SMD LED signals (in fact, I’ve ordered them). What I did do was change the code so that a “bank” of two signals would always have both lit (meaning two of the four LEDs would be on when the bank was active) so that I could get through the full set of signals more quickly. One reason for this has to do with video camera shutter speeds. I think it’s worth saying a bit about that issue.
I’ve also made some changes to make the time wasted in turning the pins on and off less, since at these speeds that is becoming a significant percentage of the total LED cycle, and I need that time for the eventual Tram Controller program to be doing other things. These changes consisted of adding a library that provides faster versions of writeDigital and pinMode, as well as keeping track of what state pins are on, and not trying to change them unless the new state differs (this got rid of a number of “change disabled pin X to disabled” changes).
In my test program, when cycling at 8 milliseconds, I’m now spending just a quarter millisecond changing those pins with three banks (6 signals) in use. My One Point Five Meter line will only use four signals, as it doesn’t have the extended double-track section of the full Tram Line, which needs six. And so it will run even more efficiently. Read More...
Fundamentally nothing has changed. I’m still planning to use NJI common-anode SMD LED signals (in fact, I’ve ordered them). What I did do was change the code so that a “bank” of two signals would always have both lit (meaning two of the four LEDs would be on when the bank was active) so that I could get through the full set of signals more quickly. One reason for this has to do with video camera shutter speeds. I think it’s worth saying a bit about that issue.
I’ve also made some changes to make the time wasted in turning the pins on and off less, since at these speeds that is becoming a significant percentage of the total LED cycle, and I need that time for the eventual Tram Controller program to be doing other things. These changes consisted of adding a library that provides faster versions of writeDigital and pinMode, as well as keeping track of what state pins are on, and not trying to change them unless the new state differs (this got rid of a number of “change disabled pin X to disabled” changes).
In my test program, when cycling at 8 milliseconds, I’m now spending just a quarter millisecond changing those pins with three banks (6 signals) in use. My One Point Five Meter line will only use four signals, as it doesn’t have the extended double-track section of the full Tram Line, which needs six. And so it will run even more efficiently. Read More...
August 2013 Status - a Retrospective
And not only another month, but another year has passed. Not much happened in August; as I mentioned last time I’ve mostly been working on the Arduino project. So this month’s post will focus on the past, but will also look forward to the future.
This month marks the fourth anniversary of Sumida Crossing, dating things from the start of construction. Planning actually started earlier, around June of 2009 in earnest although there had been a lot of thought prior to that. And the first real train didn’t run until early 2010 (unless you count a test on a loop of temporary track). And actually, although the first post in this blog dates from September 16, it wasn’t actually online until the end of November. Prior to that I’d been working on the initial version of the website offline, and hadn’t bought the domain name or space on a server until I judged it ready. I don’t think it even had a name before November; I’m pretty sure I made that up when I bought the domain name.
Read More...
This month marks the fourth anniversary of Sumida Crossing, dating things from the start of construction. Planning actually started earlier, around June of 2009 in earnest although there had been a lot of thought prior to that. And the first real train didn’t run until early 2010 (unless you count a test on a loop of temporary track). And actually, although the first post in this blog dates from September 16, it wasn’t actually online until the end of November. Prior to that I’d been working on the initial version of the website offline, and hadn’t bought the domain name or space on a server until I judged it ready. I don’t think it even had a name before November; I’m pretty sure I made that up when I bought the domain name.
Read More...
Tram Controller Status
I’m continuing to work on the Tram Controller project (main page, past musings), to the exclusion of all else layout-related, which doesn’t make for interesting posts here. But I’ve made a number of decisions in the past month, and it’s probably worth summarizing them and where that puts the project overall. Short answer: making good progress, but slower than anticipated (what else is new; all my projects run “slower than anticipated”).
I’ve also been thinking about the diorama-like layout I’m going to initially use this with. The current candidate plans for that are on the new One Point Five Meter Line page.
Read More...
I’ve also been thinking about the diorama-like layout I’m going to initially use this with. The current candidate plans for that are on the new One Point Five Meter Line page.
Read More...
Signaling with Arduino
t seems that I can never resist the impulse to make things more complicated. While working on my Arduino sketch (program) for the Tram Controller, the thought struck me that I could add signals at the stations to tell the fictive operators of the trams when it was safe to leave. These would be “starting signals” in typical Japanese practice, and only require two LEDs, red and green. Of course I’m all out of pins, and the only step up from the Uno, which has 20 pins (14 digital, 6 analog) is the Mega with a whopping 70 pins (54 digital, 16 analog).
Read More...
Read More...
One Point Five Meters
One point five meters, or about five feet. That’s how much space I’m giving myself for a short layout designed to display my buildings separate from the main layout. It’s also going to give me a short rail line that I can use with the controller I’m working on for the tram line on the Urban Station scene.
The germ of this idea was a conversation at a local hobby store that holds an annual show in the store to display the model-building skills of its customers. Last month, just before the show, I was asked about some of the pre-built buildings I’ve been detailing for my Village scene. At the time, I didn’t think the couple I’d mostly finished were really in a displayable state, but the idea of perhaps doing some kind of diorama crossed my mind as we discussed how to display something next year.
I also wanted some way to actually see the tram line in operation, as on the layout it’s going to be hidden away behind buildings, providing some background activity without really being visible (something I really need to fix on a future layout). And that led me to think: how small can I make a layout with the tram controller and my buildings?
Read More...
The germ of this idea was a conversation at a local hobby store that holds an annual show in the store to display the model-building skills of its customers. Last month, just before the show, I was asked about some of the pre-built buildings I’ve been detailing for my Village scene. At the time, I didn’t think the couple I’d mostly finished were really in a displayable state, but the idea of perhaps doing some kind of diorama crossed my mind as we discussed how to display something next year.
I also wanted some way to actually see the tram line in operation, as on the layout it’s going to be hidden away behind buildings, providing some background activity without really being visible (something I really need to fix on a future layout). And that led me to think: how small can I make a layout with the tram controller and my buildings?
Read More...
Arduino Controls and a Simple Throttle
Having covered the motor control and the sensors, my next step in creating the automated two tram controller was to deal with the very small number of controls I need to have. In my original design, the plan was to have just three pushbuttons:
- Run: when pressed, the trains would start to move.
- Park: when pressed, the trains would return to their starting locations so the system could be turned off.
- Emergency Stop: when pressed, the trains would come to an immediate stop until run was pressed again.
And all three were to be “on when pressed, off when released” pushbutton switches. I was already thinking this needed to be changed, and when I started playing with switches I became even more convinced.
There are two benefits to using toggles versus “on while held” button switches: first, I eliminate a switch, since I need two toggles rather than three pushbuttons. Second, I avoid using those pushbuttons, which have proven to be problematic in my testing. They tend to “bounce” for a long time, and they may remain “on” only for a fairly brief time, making it hard to avoid all bounces and still reliably tell that they were pressed in the first place.
The other control I wanted to add was a way to customize the top speed of a train (or trains, really), so the different models could be made to run at similar (and prototypical) speeds. I don’t want one train rocketing down the tracks while the other creeps along, even if they have very different motors and gear-trains. So I’m going to add a pair of potentiometers, used as “tram #1 max speed” and “tram #2 max speed” controls. And note that these are for the trains, not the motor shield A/B outputs. At various times each tram will be controlled by one or the other.
My first step was to create a simple throttle that used one pot, three switches, and one motor control to run a train on a simple test track. This gives me a proof-of-concept example that ensures I really understand what I think I understand (always a concern with me and electronics).
Read More...
- Run: when pressed, the trains would start to move.
- Park: when pressed, the trains would return to their starting locations so the system could be turned off.
- Emergency Stop: when pressed, the trains would come to an immediate stop until run was pressed again.
And all three were to be “on when pressed, off when released” pushbutton switches. I was already thinking this needed to be changed, and when I started playing with switches I became even more convinced.
There are two benefits to using toggles versus “on while held” button switches: first, I eliminate a switch, since I need two toggles rather than three pushbuttons. Second, I avoid using those pushbuttons, which have proven to be problematic in my testing. They tend to “bounce” for a long time, and they may remain “on” only for a fairly brief time, making it hard to avoid all bounces and still reliably tell that they were pressed in the first place.
The other control I wanted to add was a way to customize the top speed of a train (or trains, really), so the different models could be made to run at similar (and prototypical) speeds. I don’t want one train rocketing down the tracks while the other creeps along, even if they have very different motors and gear-trains. So I’m going to add a pair of potentiometers, used as “tram #1 max speed” and “tram #2 max speed” controls. And note that these are for the trains, not the motor shield A/B outputs. At various times each tram will be controlled by one or the other.
My first step was to create a simple throttle that used one pot, three switches, and one motor control to run a train on a simple test track. This gives me a proof-of-concept example that ensures I really understand what I think I understand (always a concern with me and electronics).
Read More...
Detecting Trains with IR Sensors, Part II
This is going to be a short post: it’s working! I have my IR LED phototransistor sensor program detecting things (not trains just yet), and I’ve posted the example code, see the bottom of the Tram Controller page for a links to that, and the earlier motor control code. Both example programs are public domain, feel free to use them however you see fit. I’ve benefited from a lot of public domain programs, and I think it’s only fair to give something back. When the tram controller program is a bit more polished, I plan to publish it in the same way, although it may be months before I get to that point.
Read More...
Read More...
Detecting Trains with IR Sensors, Part I
In my continuing work on the Arduino-based Tram Controller, I’m now playing around with the part I really wanted to work with, the Infra-red optical sensors themselves. This turned out to be rather more complex than I’d anticipated, but I’m most of the way there, even if I don’t quite have the system working yet. This is a post about what I’ve done so far, and what I’ve learned, with a bit about what remains to be done.
Read More...
Read More...
Arduino CPUs and Motor Shields
I’m still playing with Arduinos this week, but the little beasties are multiplying. That’s partly because I want to be able to test with the various CPU architectures, but also because each has unique strengths and weaknesses, and I’m still evaluating which of them is going to be the right choice for my tram controller. At the same time, it turns out that there are a number of options for motor shields, as I mentioned last time, and they too have strengths and weaknesses.
Read More...
Read More...
Revisiting Arduino
Two years ago I wrote about my plans to use an Arduino to control a pair of trams on a double-track line sharing single-track stations at each end, replicating the design of the Tōkyū Setagaya line. That’s briefly written up in that earlier post, and I also have a full page about the project that goes into more detail, with a sub-page about the current testing work.
Back then I bought an Arduino Mega 2560 and a bunch of other parts including a “shield” used to drive DC motors, loaded the basic test program that blinks a LED into it just to convince myself I could do it and the hardware worked, and then put it on a shelf for “later”. And forgot all about it while I worked on other things, only infrequently looking at the empty tram tracks and thinking “I really should figure out how to make that work.” It’s not like I dislike the work: I enjoy both programming and soldering simple circuits together. I just never could work myself up to starting what I expected to be a fairly major project. It was always: “I’ll work on that after I finish project ‘X’”, but there was always another “X” to occupy me.
Read More...
Back then I bought an Arduino Mega 2560 and a bunch of other parts including a “shield” used to drive DC motors, loaded the basic test program that blinks a LED into it just to convince myself I could do it and the hardware worked, and then put it on a shelf for “later”. And forgot all about it while I worked on other things, only infrequently looking at the empty tram tracks and thinking “I really should figure out how to make that work.” It’s not like I dislike the work: I enjoy both programming and soldering simple circuits together. I just never could work myself up to starting what I expected to be a fairly major project. It was always: “I’ll work on that after I finish project ‘X’”, but there was always another “X” to occupy me.
Read More...
NMRAnet - Why You Should Care
In August, the NMRA adopted standard S-9.7.1, NMRAnet Physical Layer, and a short article about it appears in the November issue of the member's magazine. What is this, and why should you care about it?
Well, if you care about Digital Command Control (DCC) for controlling a model railroad, it's an important addition to model railroading that will enhance that. And if you don't care about DCC, it's compatible with other control systems, and you may still want to use it. Read More...
Well, if you care about Digital Command Control (DCC) for controlling a model railroad, it's an important addition to model railroading that will enhance that. And if you don't care about DCC, it's compatible with other control systems, and you may still want to use it. Read More...
Plans for an Arduino-based Tram Controller
Today I want to mention one of my other projects: the control system for the Tram line of the Urban Station scene. Now this is a simple, short, out-and-back line, which exists mainly to give me an excuse to buy some of the Tōkyū Setagaya line light-rail vehicles (see the Tram section of my Roster) and to experiment with Tomix’s mini-rail Finetrack. So far I’ve run this manually, with a Kato powerpack. But I want to automate it, since the trams are just supposed to be background activity to make the station look busier, as I concentrate on running my commuter and express EMUs and freight trains.
The problem I had was that I wanted to replicate a two-track line with unidirectional running, and a single track station at each end that let the trains switch between the two tracks, and I wanted to do this with more than one tram running at a time. The track I’m using has slip switches, which allow a train to run through them even with the switch set against it. This lets me leave the switch in one position, and have a train enter the end station from one track and leave on the other, without any switch-control needed. Read More...
The problem I had was that I wanted to replicate a two-track line with unidirectional running, and a single track station at each end that let the trains switch between the two tracks, and I wanted to do this with more than one tram running at a time. The track I’m using has slip switches, which allow a train to run through them even with the switch set against it. This lets me leave the switch in one position, and have a train enter the end station from one track and leave on the other, without any switch-control needed. Read More...
