Servos and lights

[aleopardstail]

Working on driving some servos and lights, the layout is DCC however none of this is controlled that way so this could be useful generally.

Servo Controller - PCA9685
reasonably cheap boards, can plug in 16 servos and drive via a cheap Arduino or similar, either over a network or via push buttons or whatever.

the boards have a problem when it comes to model railway, they have a nasty habit of when first switched on ordering servos to go full scale to one end stop. this can damage points, can utterly destroy model signals etc.

the problem is the chip on the board is setting up the outputs to a default, before its told what they should be. it has an "Output Enable" control, and these boards have that "helpfully" set to be active by default. this can be fixed by removing a resistor from the board:

you now need to add a 10k resistor yourself between the "OE" pin and +Vcc on your controller. this means the outputs are off until you tell them otherwise - e.g. after you have configured them.

made this change here and it 100% solved the problem, no unwanted servo movement - and note if you are using something other than point blades for electrical contact (i.e. the switch rails only need to just be in contact and not slam over hard) you can even power the servos down until one needs to move

LED controller TLC5947
same as the above, but less critical, also has the output enable line active by default, again removing a 10k resistor from the board and replacing with one to +Vcc yourself means the outputs are OFF initially until told otherwise

reasonably simple to remove the surface mount resistor (easier than adding one!) and in both cases leads to much more predictable operation

[Suzie]

Are you sure that you need to remove the resistor and and a new one?

It is normal to just add a link to VCC and leave the pull down resistor in place. Much easier.

[aleopardstail]

Are you sure that you need to remove the resistor and and a new one?

It is normal to just add a link to VCC and leave the pull down resistor in place. Much easier.

this is what I did initially, the trouble is it needs to be controlled, so they can be enabled, which means a pin on the MCU is needed and it cannot be a pure link to +Vcc.

what was happening is when the board was powered up while the MCU was booting this chip powered up first and sent a signal to move the servo. sometimes the MCU caught it fast enough with the correct settings, sometimes not

what this modification does is stick a 10k to Vcc instead of ground so its off by default until the MCU wants them on, so for example initial positions can be programmed then "go" such that the servos never move outside the desired range.

can't just remove it as then the input floats and you get unpredictable results, you can with a decent MCU unloaded, have the thing very early on set the pin to logic high then as an output and catch the issue before it occurs but its a lot easier to avoid the issue entirely in hardware

basically swaps a pull down for "default on" to a pull up for "default off", I see why they make the boards this way as it makes them a bit easier to use, would be better if it was connected via a jumper pin on the board though

with the LEDs its a lot less important as worst case you get a few lights on while the controller powers up, but with the servos I had one snap its mounting bracket when testing on power up and another get quite warm

[Screwdriver]

It does seem strange it was set up as 'enable' by default. Much more sensible to have the outputs set to off. Perhaps they had another reason for setting it that way at the time. Thanks for the information.

[aleopardstail]

It does seem strange it was set up as 'enable' by default. Much more sensible to have the outputs set to off. Perhaps they had another reason for setting it that way at the time. Thanks for the information.

think its done by Adafruit to make using the boards easy, makes the output enable pin in effect optional, they have done this on several products

[Suzie]

I see why you did it now.

[aleopardstail]

I see why you did it now.

its a weird effect, have found often its a non-issue, sometimes if the MCU doesn't boot fast enough, or the servo controller fires up that little bit faster can be an issue

took me a while to track it down, one of those bits that obvious when you think about it, trying to work out why a servo jerked one way fast before returning to the assigned angle

[Suzie]

What servos are you using? Analogue servos like the SG90 can be a lot more prone to twitching since they react to every pulse, whereas digital servos like the SG92R tend to offer better rejection of twitching since they apply filtering to the incoming pulses, but if they do twitch they will do it at full power.

I find that using cam type servo bases is the way to go because they convert a full rotation of the servo in to a few millimetres of travel preventing any chance of damage to signals and points, even if the servo does a full 360 degrees (seen this happen on a servo with carbon-fibre gears which broke the end stop and just kept rotating!)

[aleopardstail]

What servos are you using? Analogue servos like the SG90 can be a lot more prone to twitching since they react to every pulse, whereas digital servos like the SG92R tend to offer better rejection of twitching since they apply filtering to the incoming pulses, but if they do twitch they will do it at full power.

I find that using cam type servo bases is the way to go because they convert a full rotation of the servo in to a few millimetres of travel preventing any chance of damage to signals and points, even if the servo does a full 360 degrees (seen this happen on a servo with carbon-fibre gears which broke the end stop and just kept rotating!)

SG90 here, I have seen circuits that can be installed at the servo end of the wire to reduce the twitchiness and chattering which I may investigate.

hadn't thought of using it with a cam & follower arrangement, thats potentially very useful, may look further into that as that could well remove virtually all the "calibration" stuff needed

[aleopardstail]

Addendum to this, if you modify a board like this, and then replace it with an unmodified board look forward to an afternoon of fault finding before you realise the "enable" line now has 10k to both power and ground and thus is wonderfully unpredictable...

*kicks cat*

[Mountain]

Hope cat is ok...

[fourtytwo]

Thanks for the info Leopard, some other notes for the SG90 :-
They draw over 1 Amp peak so thick wiring (especially 0V) is a must if you use lot's and plenty of supply decoupling.
Some misbehavior can be avoided by shutting off the PWM signal a second or so after movement, one thing this avoids is burning when coming up against a mechanical stop but also hunting and some servo signal related noise issues,
A big problem is making the servo leads longer as this exacerbates the already dodgy noise resistance, some ways around this include schmitt or optical buffers but the best solution is probably more controllers so the leads don't need extension.

Of course you have probably encountered some or all of these, your cat probably needs to take cover
Have fun
fourtytwo

[aleopardstail]

Thanks for the info Leopard, some other notes for the SG90 :-
They draw over 1 Amp peak so thick wiring (especially 0V) is a must if you use lot's and plenty of supply decoupling.
Some misbehavior can be avoided by shutting off the PWM signal a second or so after movement, one thing this avoids is burning when coming up against a mechanical stop but also hunting and some servo signal related noise issues,
A big problem is making the servo leads longer as this exacerbates the already dodgy noise resistance, some ways around this include schmitt or optical buffers but the best solution is probably more controllers so the leads don't need extension.

Of course you have probably encountered some or all of these, your cat probably needs to take cover
Have fun
fourtytwo

its weird really, my N gauge layout has 16 of the things, driven from a 5V 5A supply, alongside all of the logic and sensors and worked fine. I have seen circuits designed to isolate them for noise rejection - hopefully won't need them here as runs are contained within each board as each gets a controller. comes down to what causes the most issues - the servo leads being long or the SPI wires to the control board being long. here the longest run is going to be about 3'6" which should be ok.

problem is largely related to the power dip when switching everything on, may use a few relays and a timer circuit to cut in the 5V line on each board with different time delays

[fourtytwo]

comes down to what causes the most issues - the servo leads being long or the SPI wires to the control board being long.

My thoughts exactly though I was driving mine directly from a 16F377 (40 pins) BUT if I were using SPI the same would apply. The one I was having trouble with on the last layout was about 8ft but many closer ones buzzed sometimes hence turning off the servo signal. I reckon with the new layout I will divide and conquer with two MCU's with nice noise resistant serial comms between them. I didn't suffer the power up problem but then every servo had it's own RC decoupler as did the MCU, probably overkill but it was my first encounter with servo's.

[aleopardstail]

if my table top gaming experience has taught me anything its that there is no such thing as overkill, did get a bit of chattering on Dingleberry in N, however I suspect the RF that put out was verging on starting a war somewhere what with I2C and SPI all over