Skip to main content

I'm not sure if this is normal or not, but I noticed that when I ran my 38707 WP F3 A-unit on my test stand, with Legacy and Odyssey turned on, that the rear truck wheels did not start turning right away.  When I apply resistance to the wheels once they are turning, they can be stopped pretty easily -- very little torque.  This is opposed to the front truck wheels which have so much torque you can barely slow them down.  I took the shell off and noticed that it's very easy to stop the rear flywheel, but if I try to slow down the front flywheel (very powerful!) then the rear flywheel goes much faster.

I'm wondering if this might be normal behavior to prevent the two trucks from "fighting" each other if they are turning at slightly different speeds?  Or does my unit need to be serviced?  It's hardly had any use at all.

Thanks!

Original Post

Replies sorted oldest to newest

I would say you hit the nail on the head. When you have two motors trying to do the same thing you need to pick one to be the primary feedback source. Or else they can end up fighting as you said. I you will notice only one motor has an encoder aside from the flywheel on top. The encoder on the front motor sees you trying to stop it so it just applies more power to maintain the speed. It will also apply that same power boost to the rear motor.

 

If you want to compare raw torque try stopping either wheel at full throttle. (Warning it won't work and is a bad idea to try). You should find that both front and rear have the same high torque. If you really had a bad motor you could stop it at full throttle. As for the delay in the wheels turning that's just what can happen when the front motor has no load to fight against. Without Odyssey neither wheel would have started moving at that very low end of the throttle.

A more practical comparison of torque at a given throttle would be to turn off Odyssey for a real apples to apples comparison.

You already figured all this out though, Just letting you know your assumptions were correct.

 

Last edited by Ryaninspiron

While I’m not 100% sure without looking to see witch motor has the encoder ring but on the LionMaster big boy I have it does the same thing. Of course I don’t know if everything is the same. Mine is the old modular boards but I alway figured the motor with speed control kept the speed and the other just somehow the only got enough to keep up. The front engine of the big boy if you pick it up while running will just take off but once back in the track is right in sync with the rear. I don’t know if that made since if not I’m sure someone else will chime in too

Thanks for your thoughts, guys. I wouldn’t have noticed, but I’ve got it on a test stand and was measuring RPM and had an optical sensor looking at a wheel on the rear truck. That wheel at times wasn’t moving at all, because it wasn’t on real track where it would have otherwise been dragged along for the ride ;-)  

I moved my sensor to the front truck and collected the data I needed (I’m controlling my trains autonomously, and need to estimate speed and stopping distances so trains come to a smooth stop at just the right places, without any Gomez Addams fiery collisions!)

I guess that second motor only comes into play when the front motor is under extreme load, and/or possibly slipping.  

100% normal.  The front motor obviously has the speed sensor. When the locomotive is running on the rollers, it takes very little current to spin the wheels, so there's very little voltage being supplied to the motors. 

If you stop the rear motor, it doesn't take much, and since the speed controlled motor is still seeing the correct speed, it keeps running at the set speed.

If you try to stop the front motor, the speed control takes over and starts pouring on the coals, that increases the current to the motor as you observe.  Since you're forcing more voltage across the motors, the rear motor suddenly goes much faster as there is no speed control on it to limit it.

Note that when you put it on the rails, all of this gets balanced out, and every Lionel and MTH locomotive with positive flywheel sensing speed control will do the same thing.

@Randy P. even if they are turning at slightly different speeds, it won't hurt anything.  Lionel went to a lot of trouble to install "back-drivable" gears in your F3.  This means not only does the motor turn the wheels, but the wheels can also turn the motor (with some difficulty.)   So a stronger motor will "help" a weaker one without noticeable bucking or lurching. 

When the loco is on the track and bearing its own weight, whichever motor is more reactive will start to turn its wheels first.  They, in turn, will "push" the loco down the track which will turn the other set of wheels, which will help the other motor start turning.  It's a beautiful thing!  Unless your train lurches noticeably, suddenly becomes very sluggish., or loses half it's pulling power,  you've got nothing to worry about!

@Randy P. posted:

Thanks for your thoughts, guys. I wouldn’t have noticed, but I’ve got it on a test stand and was measuring RPM and had an optical sensor looking at a wheel on the rear truck. That wheel at times wasn’t moving at all, because it wasn’t on real track where it would have otherwise been dragged along for the ride ;-)  

I moved my sensor to the front truck and collected the data I needed (I’m controlling my trains autonomously, and need to estimate speed and stopping distances so trains come to a smooth stop at just the right places, without any Gomez Addams fiery collisions!)

I guess that second motor only comes into play when the front motor is under extreme load, and/or possibly slipping.  

It's interesting to see you tackle this from a local RPM measurement perspective. I actually did the same thing but by using an infrared distance detector instead.

Video of that here: https://www.youtube.com/watch?v=KdnQQEDew34

 

But recently I have been spending more time to tackle things through the legacy base now instead. I am also I haven't made a video on it but I am almost done decoding/recreating the IR data sent by the locomotive.

Demo of my Legacy base - LionChief control project here: https://www.youtube.com/watch?v=4Ujb8xEGKEk

I always love to see people doing "extra" things with with their trains.

It's interesting to see you tackle this from a local RPM measurement perspective. I actually did the same thing but by using an infrared distance detector instead.

Video of that here: https://www.youtube.com/watch?v=KdnQQEDew34

 

But recently I have been spending more time to tackle things through the legacy base now instead. I am also I haven't made a video on it but I am almost done decoding/recreating the IR data sent by the locomotive.

Demo of my Legacy base - LionChief control project here: https://www.youtube.com/watch?v=4Ujb8xEGKEk

I always love to see people doing "extra" things with with their trains.

Hey Ryan, I watched both of your videos - great stuff!  I'm counting revolutions on my test stand because it's an easy way to determine a loco's true speed (mm/sec and smph) and correlate that to the Legacy speed settings.  I know that the bearing the wheel is turning has a 40.2mm circumference, so distance (and actual speed) becomes a trivial calculation.  I have black and white markers on the bearing, and an infrared detector watching it.  My Arduino sees the digital signal toggle between high and low every 1/4 turn of the bearing.  With such a big project, it's a lot simpler than doing physical tests on my layout with a measuring tape and stopwatch ;-)  And once I have the data, it's done.  In fact, I plug a few results into Excel and it gives me a quadratic equation that will give actual speed in mm/sec for any Legacy speed setting -- for a given loco.

I need this because my autonomous layout will be bringing trains into a station siding at speed, and I want the train to slow gradually and stop at exactly the right point in the station -- simulating Legacy momentum.  I use copper tape on top of my rail for block entry and exit sensors (similar to isolated rail sections) so the idea is that the loco reaches "crawl" speed just as it trips the appropriate sensor, at which time my Arduino sends an "absolute speed zero" command via the Legacy serial interface.

My system does a lot more than that -- it schedules routes, starts and stops trains realistically with station announcements, bell, whistle, etc., all controlled by seven Arduino Megas.  Feel free to reach out if you'd like more information, and I'll look forward to more progress on your projects!

Attachments

Images (3)
  • Loco test stand: You can see that one of the bearings has black-and-white markers, and an IR board that watches and counts as the bearing rotates.
  • Project board: The left half are time-delay relays that close when occupancy sensors are tripped.  The right half controls turnouts, accessories, and sends commands from an Arduino to the Legacy control system.
  • Inside control panel: Several more Arduinos on the right, and misc hardward including Centipede shift registers are on the left.

That sounds amazing!!  I've never programmed an Arduino or anything, but I would love to build a fully, or partially automated layout.  I had been looking at both Lionel's Layout Control System (LCS) and C-MRI / JMRI.  I've come up with some wild track plans, that with a dose of randomness would make for an amazing display or demonstration layout.  If one train were automated the other(s) could be controlled by live operators.  Imagine trying to stay clear of an express passenger train while trying to complete the switch list for a local freight!

Probably you realize that even with rubber tires on the wheels to grip the track, there will be significant random error.  So the further your loco gets from a sensor, the more it's likely to be out of position.  (A smooth-tired loco would have to be strictly governed by the sensors, because wheelspin is likely.) 

Can't wait to see some videos of your system in action!

Last edited by Ted S

Add Reply

Post
×
×
×
×
Link copied to your clipboard.
×
×