Slowing down turnout servo motors for quieter and more realistic moving speeds

[@WirenwoodModelRailway]

Since I made this video I've done a little more work on the code, just to align the speed when moving multiple servos to when moving a single one, using a millisecond delay too. It's all in the code that's linked from the description.

[@chrissharp6845]

A very interesting video. I've noticed a similar slow down in servo speed when CMRI is polling the Arduino. On my layout I have two identical boards, with identical Arduino CMRI nodes, with identical code (apart form the node number) and the servos move a noticeably different speeds. One is slowed a lot by CMRI polling, the other hardly at all. It's odd. I may look more into it. I like your idea of having a second Arduino just to control the servos. An I2C link between the CMRI Arduino and the servo Arduino would work. I have this on one of my baseboards. It has some fairground rides on it. They have their own Arduino to control them. They are usually started by push buttons. An I2C link does allow me to start the rides spinning from JMRI. The I2C link is only one way. JMRI doesn't need to know when the rides are moving. But it could be two way to feedback when the servo has completed its throw.

[@WirenwoodModelRailway]

Thanks Chris - yeah there seem to be so many variables - including different servos moving at different speeds with different levels of responsiveness too. I'm pretty certain that the servo motors move really quite smoorhly when there are no CMRI polls - certainly the test setup in my office indicated that - it was still communicating over RS485 with 8 turnouts connected, so was a pretty solid indication. Fairground sounds very interesting, I hope it's rich in flashing LEDs when the rides are moving! Chris

[@aleopardstail]

Hi, I'm using the same sort of PWM control board and the same servos, with the same "problem". Your approach is interesting and I'll spend a bit more time with it. However the way I went is slightly different, I created an object class for a servo, and then create an array of instances of this class - one for each servo (it also stores the various settings for each in the EEPROM - I have a second sketch to configure them and save those settings, and a main one that runs normally talking to CMRI) this class has a function ".loop(uint32_t EllapsedTime)", the arduino loop works out the time that has passed in milliseconds since the last loop iteration and then calls each servos .loop() function in turn. each servo also has a ".setPosition()" function, and a .throw() and .clear() function which simply goes to the two extremes. the servo also has a parameter which tells it how long I wish the movement to take, typically 1,000ms. when a new position is set this is stored as a target and then the .loop function works out how far it needs to move _this loop iteration_, and sends that instruction to the controller - it also returns "true" if the servo needs to move. then at the end of the loop if any servo returned true the PWM board is told to update. the same code also manages the feedback as a "two sensor" system with one reporting for each extreme end and when its moving the result is JMRI sees "inconclusive" was written for the PiPico initially but ported the code back to an arduino and it handles 16 nicely, would need some optimisation for more or an external EEPROM adding. gave it the ability to have "just do it" mode, a "constant time period" mode and a third mode for "constant angular velocity", which to be honest this project doesn't use (the code was written to drive a laser point to entertain cats initially) it does work, there is a bug so far in the EEPROM code so its set for full speed not slow speed currently (its not reading back the correct time constant) however its well worth it for the sake of silence and sanity. the *only* issue I have found so far is related to the rubbish turnouts I have where one or two need a full speed whack to get them to make good electrical contact, but most work. this is one of the little touches that really makes a layout nice though, its not so much the slow movement, its the *quiet* movement that appeals. :)

[@WirenwoodModelRailway]

Thanks Dale, that's really interesting! On the subject of the stubborn turnouts, if they're similar to the Peco ones I use, could you not just remove the spring that holds the blade at either extreme? When you're using servos, the motor arm will hold the blade at either extreme anyway, so the spring isn't needed. When it's removed it just makes the blade loose and floppy. Although if it's electrical contact maybe solder on a couple of extra cables? I was particularly interested in you taking the time to write some code to entertain cats!! Thanks for the message! Chris

[@aleopardstail]

@@WirenwoodModelRailway Have removed the springs, what I forgot, because I iz Muppet, was to add extra power feeds so its only the strength of the servo making the contact. the N gauge turnouts I have sadly are not quite as good as the OO ones (all are PECO) in that these lack the space below for the wires and lack the split in the rails to isolate and allow the switch rails to be always live. can see pulling some up to torture them with a soldering iron :)

[@anfieldroadlayoutintheloft5204]

Good video thanks lee

[@BriansModelTrains]

My HO and N scale layouts both use NCE Switch-kats (enbles DCC, push buttons and lighting) as I use Kato track (at least for the turnouts) so I don't use slow motion switches or servos but I like what you have done, Would a small resistor and capacitor in series help to keep all servos the same speed? In JMRI there are some bounce or buffering settings that may help. I have no idea; I am just guessing. It is a joy to watch what you are doing. Thank you for sharing.

[@WirenwoodModelRailway]

Hi Brian - ah that's where my lack of electronics knowledge and experience let me down - I could just about tell you what a resistor and a capacitor do, but would struggle to come up with a plan to put them together to change the servo behaviour. I'd put them together on my breadboard to test but I need a new one as it appears I left a short circuit on it somewhere and it melted!! Thanks for the kind words, Chris.