computer controlled

Legacy is better, more sounds in my experience. Smoke is great though on both.

I wonder if this is a job for JMRI?

I immediately figured DCS or Legacy would suffice but I don't know that they can limit speed and check for clear tracks ahead. Legacy does have accessories that can record a sequence and play it back I think.

But it sounds like you're looking for logic paths and stuff and I think that's the domain of JMRI. Maybe somebody else can comment on that?

You might want to check out the new forum sponsor, Scaled Automation.

One problem I see is that some of his trains are conventional...they would have to have some type of controller installed.  Legacy does have some great abilities to record sequences.  My concern is that the recorded sequences for each consist may not mesh well, so John may need to limit the number of trains being run at the same time.  A lot of what John has mentioned is on my "this is what I want to do" list.  However, my model railroading time is becoming increasingly limited.

I've gotten some flack for my on screen controller (see attached), but it can be resized and it's fairly obvious in its usage.  The resize feature is definitely helpful to the eyes as well as control.  I think some of those concepts are needed for those with disabilities.  Even I have trouble with the MTH controller.

I'd be eager to see what solution, if any, John is able to implement.

Anthony

I want to thank everyone for the input. I am going to look it to , Scaled Automation.

Thank you

john

Keep us posted!

I contacted Scaled Automation and there replied "John:

I am still looking and will keep you all posted. If we can fly to the moon and back someone should be able to help with this.

John

John,

I admire your aspirations.

In the real world (1:1 scale) what you're asking takes a great deal of what is generically called "infrastructure", a significant amount of software for user interface and control, and a great deal of detailed testing to make sure it works correctly before making it operational.  It's important that it function correctly to be safe to the trains being controlled, the people on them, and those on the ground that the trains will encounter.

You would think that doing it on a small scale would be much simpler than in 1:1, but it's actually no different, especially for the user interface and control software, and only slightly simpler for your small-world infrastructure.  The thing about making a small-scale world that mimics reality is that the control you seek is just as complex as in the real world -- in fact the software and user interfaces needed for your layout could easily be transported up to 1:1 scale afterward.  This is often done in developing complex solutions to real-world problems.

One consequence of so many kids having and playing with toy trains back in the day is that a large number of them became technical professionals who in their careers aspired to solve these kinds of challenges, starting with what they learned with those trains -- myself included.

My feeling is that what your asking is still too much for present-day model railroad enthusiasts and suppliers to handle, at least currently.  Yet, we're all  are on track (no pun intended) to make it happen, sooner or later.  Continue to ask questions and contribute.  One day, relatively soon I think, you will be pleasantly surprised to see it actually occur.

Flying people to the moon and back was, and remains to this day, the most complex control task ever accomplished.  Unlike many situations where the general public cites its success as proof that we should be able solve whatever problem they have, your request in this context is more appropriate than you may realize.

Stay tuned.  This forum is the perfect place to be.

Mike

As has been mentioned, one main stumbling block is your inventory of old and new locomotives and command systems. There just aren't any off-the-shelf computer automation systems I can think of for three-rail O gauge.

However, the level of automation you seek is regularly done with Marklin command systems and trains, for example. The ESU ECos system supports automation as well. JMRI has been mentioned and there's also iTrain, RocRail and TrainController. These are all software packages that can provide a high level of automation, but they work with DCC (Digital Command Control) and engines with decoders inside, not post-war Lionel. Also, in order to get what you want, you might have to invest a significant amount of time programming and configuring the software. And you'd need new locomotives, the command systems, the software, detection hardware and so on. But this would be less expensive than custom software to automate your current inventory. Maybe start small with two ovals, three trains and a passing siding, or something like that.

If you want to set something up fairly quickly so the children (even if adult-sized) can watch the trains run, then take a look at another system. There are support forums on groups.io and marklin-users.net for all of this stuff. There are a number of automation examples on YouTube as well.

Thank you and I will look in to this

John

@J M W posted:

I have a new layout with 7 tracks with Radis from 036 to 084. I am looking for the best system to run my whole set at one time. Lights, 25 022 switches, accessories, and trains from post war to present day. I have about 50 different engines, half are post war, and the other are lion chief, and legacy.

How exactly are you 7 tracks arranged?  Perhaps you could meet in the middle by having postwar only loops and command only loops. That might solve the mixing problem between the two types of locomotives. Then you can start looking at your options for logic controls or take advantage of Legacys ability to record actions.

What I mean to ask is, do you have a track diagram that we can see?

I had two other thoughts:

- The most popular scale for DCC trains is HO. You might find this scale too small. The engines and cars are wonderfully detailed, but best viewed at eye level. I find the figures and people to be tiny. However, the large scale (G gauge) trains also run on DCC and are very entertaining and robust. They are as expensive as new O gauge locomotives, which is to say, pretty expensive. Many folks run these trains outside because they're big, but I run mine inside in a 10 x 16 room. Lots of impact, lots of noise!

- With Lionel Legacy locomotives, you can use the Sensor Tracks to program stopping and starting at stations, blowing the whistle, etc. You could use signals tripped by infrared sensors. They wouldn't actually do anything, but the lights would flash and change as the trains rolled by. With this option, you could do away with most (maybe all) computer control yet still have a high degree of automation and still use some of your current rolling stock and track. Check out Lionel LCS (http://www.lionel.com/lcs/).

@trrentschler posted:

- With Lionel Legacy locomotives, you can use the Sensor Tracks to program stopping and starting at stations, blowing the whistle, etc. You could use signals tripped by infrared sensors. They wouldn't actually do anything, but the lights would flash and change as the trains rolled by. With this option, you could do away with most (maybe all) computer control yet still have a high degree of automation and still use some of your current rolling stock and track. Check out Lionel LCS (http://www.lionel.com/lcs/).

I didn't think of it till I read this but you could look into the use of infrared sensors with an Arduino to flip blocks on and off for your postwar trains. It would be a pretty big undertaking but I've seen IR sensors used for this kind of logic in scratch built coal tipple operations. They sense the car passing through and won't let the tipping begin unless it sees the right sequence of spaces.

Yes, it could be done! There are a couple of Kindle books on model railroad automation with Arduino. Not exactly "plug and play" but not that hard either if you know a little programming. I think you could find the electronics in Arduino books and magazines. I subscribe to the "arduini" group on groups.io which is all about using Arduino on model railroads.

You can get Arduino info everywhere! It's great. The library, Youtube, the internet in general. You got a good shot at getting it figured out.

Thank You

I am looking into Lionel LCS and a company called Train Brain (TB by CTI) to complement it. TB has a lot of different sensors to tell speed, location, and control of the train and the track loop. The TB system would take a lot of sensors to do the things I require. You have to write code to work this system and this is something I have not done. Challenges or adventure - yet to be seen.

John

What would be nice is to have an Open Source Solution that anyone can contribute too.

I'm working on something similar to this, that will eventually be open source.  But like has been said earlier, this is a tall, tall order that needs a lot of "infrastructure".  I'd like to eventually get to fully automated layout control, but I'm starting with the building blocks.

I started by replacing all the electronics inside one of my engines.  On an early-2000s conventional loco, stripped out the e-unit, sound board, and lighting.  I'm replacing them with my own microcontrollers, lighting, soundboard, adding a smoke unit, etc.  I'm a professional software engineer and an amateur electrical engineer, but it is a LOT of work.

You can see a video of an early prototype running here:  

I've miniaturized most of the components since then.  For example, here's the current best prototype of the sound unit:

It's based on an ESP8266 chip, which is basically like an Arduino with Wifi capability added.

Fun projects!

@jwetzel1492 - Those look like the same breadboards I'm using and, like you, I have connector wires everywhere.  I'm starting with a bare bones Williams Rock Island GP-7.  While I'm using RF for switches, etc..., I'm trying to stick with PLC for engine communication.  It is an incredible amount of work with most time being devoted to the software side.  I'm still in  the process of developing and testing my SMB communications module.  (I'm also at a stand-still with my reflow oven.)  It feels like a never ending battle some days, which does take the fun out of it.  On a good note, however, I've nearly finished designing my layout interface controller.

Anthony

@jwetzel1492 - Are you using any type of feedback from the motor to determine actual speed?  And, if so, are you attempting to use a PID (or similar) algorithm to update the power to the motor accordingly? A

JMW:  I too am a software developer (business applications) and amateur EE.  I have a 30x50 layout and i have already built the infrastructure to support block occupancy in support of the Customs Signals devices (photo).  I have also used some Arduino software on dog bone loops to register which direction the train is traveling so I can properly switch the turnout at the entrance/exit of the loop and its connected custom signals.   My dream is to run multiple trains on my layout with intelligent stopping and starting.  Any way I can help just let me know.

@Flyboy62 - Wowsers! That is a lot of signal device controllers!  I suspect I'd have a heart attack if I had to wire and manage all of those.

Not as tough as it looks.  it is all very repetitive and most of the wiring was done flat on the bench.   Plus I had one of my techs come and help me with the wiring under the table.  we ran cat5 cabling to every Atlas switch which included an isolated piece of track on each side of the turnouts.  All of the cat5 terminated in the telephone style 66 blocks on the boards.  That and the 150 silver satin home runs to the signals were the only thing that had to be done off the work bench.  Its just like developing a big application; one small step at a time.

AWells:  Yes, I made my own "tachometer" with a hall-effect sensor and 4 tiny magnets attached to an axle.  From there, I implemented a PID controller to try to match "measured wheel rpms" up to "desired wheel rpms".  Speed control, basically.

@Flyboy62: how do you detect block occupancy?  That's a nut I haven't cracked yet.

Here's my first prototype of the tachometer:

@jwetzel1492 posted:

AWells:  Yes, I made my own "tachometer" with a hall-effect sensor and 4 tiny magnets attached to an axle.  From there, I implemented a PID controller to try to match "measured wheel rpms" up to "desired wheel rpms".  Speed control, basically.

I like the TI series of hall-effect sensors.  However, for the motors, I was going to use a homemade optical rotary encoder (60 "detents") and slip it over the fly wheel. A

@jwetzel1492 posted:

@Flyboy62: how do you detect block occupancy?  That's a nut I haven't cracked yet.

I have one of my outside tracks isolated from signal (18 VAC) ground at all times.  Each track block, as long or short, is tied back to my 66 block as what Custom Signals calls a detect line.  when a train occupies the block the detect line goes to ground and we know we have occupancy.  In some cases I have multiple blocks (4)  spread around a dog bone.  I use all 4 as inputs to an Arduino and by keeping track of the time that each block goes low and then high again I can determine train direction within the loop.  this too can be done a straight section with just two isolated tracks.  when both are low you make a decision about which one went low first and you know direction.

@Flyboy62 - I have one...just one...Atlas custom light controller.  Those instructions were enough to make me dizzy.  You'll note it's still in the box.  I'm eager to see how you detection block occupancy as well.  I have a planned method for that but it's gotten moved far down the todo list.

Anthony

as you might see from my pictures I use the Atlas 6924 switch controller on every switch (45).  Because it sends a short controlled pulse to the switch, I have never burned up a switch motor even though I run the voltage high to get a quick positive snap to the switch changing.  Also the Atlas board talks to the Custom Signals boards via 1 wire.  This makes the interface very easy and as I mentioned it was all assembled on the bench before installation which also made it easy to work on.

@jwetzel1492 - What (IC) are you using to drive the motor? A

I have been doing a lot of reading before I start on my system. The wiring dose not bother me at all. It is the programing. I been reading everybody's post and trying to look it all up and expand my knowledge.

A lot of this stuff is over my mechanical engineering head but dang! You guys are up to some cool stuff!

@A. Wells: In that video, I was using an L298N motor driver.  However, it's large, inefficient, and generates a lot of heat.  (It is inexpensive though!)  I have since switched to using an Adafruit DRV8871.  It's more expensive, but it's tiny and doesn't generate excess heat.

@Flyboy62 - For block detection, I had originally intended to use RFID, and I will probably still go that route for automated means.  However, a simpler method for block detection without the programming overhead that came out of the RFID efforts is that of capactive inductance.  A

@jwetzel1492 posted:

@A. Wells: In that video, I was using an L298N motor driver.  However, it's large, inefficient, and generates a lot of heat.  (It is inexpensive though!)  I have since switched to using an Adafruit DRV8871.  It's more expensive, but it's tiny and doesn't generate excess heat.

I standardized on the L6205 long ago.  It's rated for more current than is needed for model trains and there is a lower power version available, but like I indicated, I decided to stick with one Dual Full Bridge IC for projects.  The Power-SSOP version is designed to dissipate heat via a large thermal pad on the bottom of the IC and it does just that.  Given what it does, I find it worth the price.

@A. Wells: can you tell me more about using capacitive inductance for block detection?

@jwetzel1492 - Instead of drolling on endlessly, I thought it would be best if you start with the documentation for the X-NUCLEO-NFC06A1 and branch out from there.  The evaluation kit has a built in inductive and capacitive detection area on the board.  Another good piece of documentation from ti is at https://www.ti.com/lit/an/slya048a/slya048a.pdf

@jwetzel1492 - How many motors are in your cc engine?  I see the one.

Originally that engine (an early 2000s rs-3) only had a single powered truck. But I’ve collected a lot of spare parts, so it now has two powered trucks.

Now, with some conventional locos I’ve modified to have dual powered trucks, I’ve been able to get better low speed performance and torque by running the 2 can motors in series. But I haven’t been able to get that to work when they’re hooked up to one of these PWM motor controllers. If they’re in series, only one of them will turn. So I have to run them in parallel.

@jwetzel1492 - For your speed control, did you add any acceleration limit?  That is to say, if you chose 45 mph right off the bat, did you target "45 mph" on the motors immediately (via PID)?  I know MTH has a constant acceleration limit but I was thinking of something more meaningful that would simulate less acceleration at low speeds. (ds/dt = f(s)) instead of (ds/dt = c) or even (ds/dt = f(t));  Unfortunately, my desired customizable f(s) doesn't have a closed form integral solution unless I can come up with something along the lines of (ds/dt = 1/f(s)) so that (f(s)ds = dt).

Anthony

@A. Wells - In my code, there are 2 systems before we get to actually controlling the motor speed:

1. Control Model
2. PID Controller

Control Model Inputs:
- Throttle
- Reverser
- Brake

Control Model Outputs:
- Engine RPMs (which is used by my sound algorithm)
- Desired Wheel RPMs
- Smoke percentage

PID Inputs:
- Desired Wheel RPMs
- Measured Wheel RPMs

PID Outputs:
- Speed value that is sent to the motor driver

I've implemented a couple different "Control Models".  The simplest is the ToyControlModel.  It only uses the Throttle and Reverser, and the Engine RPMs and DesiredWheelRPMs are just linear with respect to Throttle.  It's just like using a conventional transformer.  (Except that it goes through the PID controller too, so there's speed control, and the PID takes care of the non-linearity of the motor driver and can motors.)  The PID does smooth out the acceleration, but it can still make pretty quick changes in speed.

But I've also implemented a SimulatorControlModel.  While I've never driven a real locomotive, I have some experience with Train Simulator, and a background in physics.  So the SimulatorControlModel tries to model some of the hardware inside a real locomotive, as well as some of the physics.  So it's modeling:
- Rate for the prime mover to spin up
- reverser and how much power the traction motors can deliver
- braking
- rolling resistance
- air resistance
- how much smoke should be generated for a given engine rpm

I'm learning as I go and I'm sure some of my equations aren't perfect, but I'm trying to get it to generally behave like a real train.

@jwetzel1492

That's way outside of my league! I'm approaching the movement from an aesthetics point of view...not whether it models the physical motion aspects of a real train.  My patience would be gone in a matter of a few minutes if I was to take on that task.

I have previous motion control work where I just use a time based S curve for motor control (start point, stop point) which worked surprisingly well even with an 8 bit microcontroller.  As mentioned earlier, I introduced feedback based on the current speed of the locomotive.  I've since modified the concept and introduced time into the feedback: (ds/dt = f(s,t) or ds/dt = f(s)g(t)).  In my case, g(t) is a constant c which is the number of times per second I update the motor speed.  So, once again, I'm off the hook on any elaborate separation of variable or partial integration.  I may not have mentioned f(s) is a cubic bezier curve (aka polynomials).  This allows me to update the curve to my hearts content based only on four points.  Quick changes in speed only happen at higher speeds in my logic and the maximum speed change is also limited.  (This may have to be adjusted for negative speed changes.)

I have three speeds that I track: actual speed, current target speed, final target speed.  On paper, I have made notes to use any difference between the actual speed and the target speed to induce labor/drift sound and, like you, to use the actual speed for rpm.  (I have no plans to introduce sound into the system any time soon.)

The one thing that concerned me with your set-up is that you only have 4 detents/indexes per axial revolution.  Doesn't this result in jerking at low speed?

Anthony

@A. Wells The 4 detents per rev hasn't been a big issue.  At it's slowest, my engine axles are doing about 90 rpms.  So a magnet goes past my Hall detector about every 160ms.  And I run a low-pass filter over the measured rpms before using them.  If the train is on straight track, the measured rpms stay pretty close to constant.

My biggest issue right now is I'm stretching the limits of the gearing/traction of these particular powered trucks.  I'd love to run even slower, but then bends in the track or other random friction can cause the can motors to come to a halt.  (And faster than even a PID can compensate for.)

One of my next projects is to put my boards in an RMT Beep.  The low-speed gearing on those is spectacular.  (But I'll have to do some miniaturization on my protoboard.  Very limited space inside a Beep.  I might not be able to fit a tachometer inside a Beep either.  But again, their low gearing might make a PID controller unnecessary.)

Update:  I finished miniaturizing my circuits.  Had some custom PCBs made (by jlcpcb.com) and got everything tucked into the body shell nicely.

Here's a video of my first run with everything 100% functional.  My son was cracking me up with his reactions to it.  

Major features:

- Controllable over WiFi
- Tachometer and speed control
- Smoke system
- LED directional lights
- Digital sounds

The speed control does a really good job of keeping constant speed on curves and up the hills. It speeds up a bit going down my 4% grade hill though. The controller/motor are getting set down to the minimum possible power that won't stop the engine, but even at that amount, gravity takes over and causes some acceleration. If I let the PID controller go any lower, it would jerk to a stop though. The only real solution would be lower gears in the trucks.

I'm releasing the firmware open-source: https://github.com/joelwetzel/MQTT-Locomotive I don't expect anyone else to ever build one - it's quite a project - but if anyone is curious... have fun! I'll probably post the PCB and wiring diagrams at some point too.

Search Professor Chaos and Arduino on this Forum.  He has a completely automated layout using Arduino with full documentation.

thank you

I will look at it now