Arduino Uno Question

gunrunnerjohn posted:

Can we say stepper motor?

Now you've done it, John! I believe that the CRS (constant rotation servos) grew out of the R/C hobbyists who just wanted drive wheels for their robots. I'm not sure why? You would think that driving a robot around would require more positional feedback than ever. Maybe costs were lower or they just didn't want to mess with the stepper motor driver boards. But whatever the motivation, people have been "modifying" standard servos into CRS for a while.

I'm not experienced on stepper motors either but I do think it takes some additional hardware to drive them properly. Motor control and H-bridge controls are not generally done in software as far as I know.

Having watched a couple of videos on the Arduino running stepper motors, I take back what I said last time about not using software to control them. Although they do use additional hardware to drive the motor, the programs tell them when to take each step and how long to wait before taking another one. The delay determines the speed. These methods simply involve regular digital I/O pins to generate the pulses for the stepper motor.

A cursory look at my favorite auction site yields prices and varieties on a par with servo motors. Apparently they are often used with the mechanisms for 3D printers. Mounting brackets are generally more expensive than the stepper motors that they are meant to hold.

And so, stepper motors would seem to be a valid alternative to continuous rotation servos and may be more scalable (they can do some heavy lifting with the proper driving hardware). However, the driving hardware, though simple and available, adds to the overall cost.

Unless you're building a hundred of these, the cost of a few bucks between servos and steppers isn't exactly a killer I would imagine.  I just figured it's another option that's worth considering.

79 cents for this one. 

Oh my, you guys are already on stepper motors and I still have a few hundred thousand servos left to look at!  

gunrunnerjohn posted:

I just figured it's another option that's worth considering.

GRJ: Options are always a good thing. I admire it when people come up with different approaches to problem solving. Your experience in the aerospace field and flight instrumentation is not wasted on us. Folks on the Electrical Forum are always watching for your input to back up their pursuits. I personally give you high marks for much of your advice and direction. Keep it up.

rtr12 posted:

Oh my, you guys are already on stepper motors and I still have a few hundred thousand servos left to look at!

RTR12: Don't worry! You're abbreviation guide has given you a special exemption because of the number of forumites (including me) that it has helped. So if you have fallen behind on stepper motors, that's OK (okie-dokie). They're just motors that are used for more precise movements due to their design. You'll be fine.

This might be off topic, but related. I have been designing a model railroad layout and using a PLC to control it. I am mainly doing this as a learning tool to teach myself PLC programming. I have not posted about this mainly because its impractical and probably would not be of interest to most. I have never used the Adriano, but I would think programming it may have some similarities to ladder logic and I might be able to help.

Mike

mikeexplorer posted:

I would think programming it may have some similarities to ladder logic and I might be able to help.

Mike: Ladder logic is an old school method of industrial programming with relays; 2 in series for AND, 2 in parallel for OR. I realize that they still use ladder logic for modern PLC (programmable logic controllers) systems but that's because they didn't want to have to change things over when they had so much invested in the older technology. That and the fact that the transition most likely involved both older equipment along with the new. It's odd that ladder logic is still used in industrial control environments.

The Arduino (pronounced: ard - as in aardvark, ui - as in ween from Haloween, and no - as in no meaning negative) is much less restrictive. Of course it does involve logic but the mechanisms of the programming language are much more open.

The Arduino uses a version of the "C++" programming language that came from the older "C" language developed at Bell Labs. C++ is an object oriented language that allows for the creation of new entities that have common functionality. For example: you can create an LED object that can have methods to change its state like so:

#define LED_PIN 13

LED myLed(LED_PIN);
myLed.on();
delay(1000);
myLed.off();

These objects in the Arduino world are refered to as a "library". There are a number of libraries already available for the Arduino including a Servo library (as described here).

There's a lot more to it but I think you've got the idea. There are plenty of books, videos, etc about the Arduino platform as well as the C++ programming language. You might want to give them a try.

  -- Leo

It seems to me the take-away of this discussion is the use of the servo.write functions to easily get up and running with an Arduino and a servo.   The servo has 3-wires going to it.  2 are just the +5V power and ground that the Arduino has anyway.  The 3rd is a single digital output pin.  The single servo.write(0) command sends the servo to one end, the single servo.write (180) sends it to the other end.  And arguments in-between send the servo to some angle in-between.  Easy.

Then build or buy a modified servo which has come to be known as a Continuous Rotation Servo and now the same commands send the mechanism spinning in one direction or the other direction and coming to a halt by sending the single servo.write(90) or mid-value command.  Easy.

If you are going to mess with servos, I highly recommend the $1 servo-tester you can get on eBay.  Simply apply 5V DC.  Attach 1 (or up to 3) servo mechanisms via the standard 3-wire connector.  Then by turning the knob on the exerciser, you effectively generate servo.write(x) commands so you can verify operation of your servo mechanism before writing a single line of Arduino code.   This development tool is obviously handy when mating your servo to your animation.

Again, I think the idea here is to get up and running quickly with minimal fuss.  That's what is interesting about the CRS since it accepts and interprets Arduino servo.write commands.  As I've already confessed, I was not aware of this development until Leo pointed it out.  Anyway, to further the discussion about using servos for layout animations, here are a couple more ideas that might help Arduino enthusiasts willing to modify (or pay a couple bucks extra to modify) a standard servo as is done with a Continuous Rotation Servo.

Watch the 4 mechanisms in action (one being an un-modified standard servo).

In photo (and video), I modified the "guts" of a standard servo to make a CRS.  As mentioned in a previous post, I then replaced the DC motor within the CRS with a cheap DC gearmotor.  In fact, I show two DC gearmotors being driven together by a single CRS.  The point here was a standard servo has pretty amazing current drive capability since it can spin the integral motor at whiplash like speeds.  But if you want to go slower as you might with many layout animations, there is plenty of current capability to drive a wide variety of DC motors.

Additionally, on the top, I show a "linear" servo which is an incredibly useful mechanism for layout animations.  Sometimes you just want something to go left-to-right rather than around-and-around.

Again, it's just a modified standard servo removing the electronic guts and attaching it to a linear volume control mechanism from a remote-control audio amplifier - you've seen them...when you adjust volume from the remote, the manual volume control knob slides (or rotates) by itself.  Or you can just go up to the amp and manually slide the volume control.  It's essentially a motor-driven potentiometer.  So the potentiometer provides the feedback to the servo electronics.   I buy these surplus for a few bucks.  Again, you have the standard 3-wire connector (+5V, ground, 1-pin Arduino output) so from the Arduino perspective, the single command servo.write(0) sends the slider to one end, servo.write(180) sends the slider to the other end, and value in between send the slide to the mid-point.  Easy.

stan2004 posted:

It seems to me the take-away of this discussion is the use of the servo.write functions to easily get up and running with an Arduino and a servo.

 

Stan: Right, but more generally, that all kinds of automation are possible with a microprocessor. Add in cheap relay modules along with homemade train detection circuits and LEDs for trackside signals and now you can build some good stuff; a reactive layout. Not exactly a new idea but now with the costs at a level that makes it very practicable.

Think about how a conventional layout could be setup to use isolated blocks to control more than one train on the same track. You could follow each train around the layout through its own transformer. You could use large bridge rectifiers (diodes to reduce voltage) to slow down a train as it approaches a more restrictive signal; trains would maintain a safe stopping distance without any operator intervention. All made possible because of the simple but sophisticated microprocessor watching over the entire enterprise.

I imagine many Arduinos around the layout controlling turnouts, led signals, power districts, talking to each other, running switcher operations in the yard to build a consist; and that's just for conventional mode. TMCC, Legacy, DCS, DCC are all candidates for automated control as well.

Sounds like fun to me!

Stan: I also want to say that I am suitably impressed with your demonstration video. That little tester looks like it belongs on my workbench. You've created enough movement there to set an ocean hardened sailor out to look for the railing. Who needs animations when you can look at all that going on. Good job!

That was quite a demo Stan, lots of action!   I can see where the continuous loop servo might be useful, never really thought about it before.

What's amazing is you can now buy a standard servo on eBay for 99 cents free shipping.

And one with metal gears for not much more.  Point being I don't think the electronics inside cares whether the gears are plastic or metal - relevance of this later.

There is no shortage of resources, references, articles, etc. about servos and how they might be used in a train layout.  Though we still have no idea what kind of train animation the OP is attempting with an Arduino, the application of the modified-servo (CRS) is less well documented.  Hence, I've put together a few more thoughts on this.

To recap, a standard servo (shown on left) consists of 3 main components.  It's a (1) DC gearmotor (DC motor + gears), (2) angle sensor (typically a potentiometer), and (3) electronic guts which "knows" how to decode Arduino servo.write commands to set the angle of the output shaft between 0 and 180 degrees.  The CRS modifies this by making some minor electrical and mechanical mods; again, many online and youtube tutorials on how to do this...or most robotics/Arduino stores sell the modified servos.  The modification is really to remove the mechanical angle feedback to the electronics so that the electronics always thinks the output shaft is at the midpoint (90 degrees).  So when you command servo.write(0), the electronics drives the motor CCW but the sensor always says it's still at 90 so the motor spins in vain forever.  Likewise, command servo.write(180) and the electronics drives the motor CW but the sensor always says it's still at 90 so again it spins in vain forever in the opposite direction.

So I'm claiming the electronics to make a DIY CRS with your own DC gearmotor is as little as 99 cents!  Likewise, the electronics doesn't "know" it's driving the integral miniature DC motor that comes in a standard servo.  In other words, I'm suggesting for 99 cents, you can "throw away" the DC motor and gear mechanism - hence if doing this, I'd experiment with a plastic-gear servo.

So why do this?  First, as mentioned previously, most standard servos spin REALLY fast.   Most servos have the so-called 60 degree spec which, oddly enough, is the time it takes to spin 60 degrees.  A typical servo might spec 0.1 seconds.  So this would be 0.6 seconds to spin one revolution (not that a standard servo can make a full rotation) or 100 RPM.   I'm sure there are train layout animations that rotate 100 RPMs but I'd say this is a bit fast; the Newsstand dog running around the hydrant may even be faster than 100 RPM!   Yes, you can slow down the speed by changing the servo.write(x) command to something other than x=0, x=90, or x=180.  What actually happens when you do this and the fine-print is a subject for a separate discussion.

The point is you can get DC gearmotors in the, say, 10 RPM range for a couple bucks that might better suit train type animations.  I showed some examples in an earlier post.

The other consideration with most standard servos is the common ear mounting method may be awkward to mate to your specific animation.  Likewise the set of mounting arms that snap on the knurled output shaft may or may not play well.  To be sure, there is a whole after-market of plastic and metal arms, extensions, you-name-it that can make the job easier. 

In my experience making custom one-off model layout animations, much more time is spent designing, prototyping, fiddling, adjusting, and fussing with the moving parts or mechanism...as opposed to the electronics.  Obviously guys have been using DC gear motors since day 1 to make clever animations...simply adjusting the DC voltage to get the animation just right.  It's been more work to orchestrate animations where the motor runs in both directions in a complex timed sequence.  This is where the Arduino is going to shine. 

Stan: We have heard from the OP but he is too busy working on his programming skills to be bothered with our ramblings. Pretty good ramblings, though! It looks like we've got lots of options for servos, stepper motors, linear servo driven sliders (I've seen those with premier audio mixers for "faders"), and now you're telling us that regular DC motors that you can get with reduced gear ratios can be controlled from the electronics inside a tiny 99¢ servo. That's all good news.

So the control wire to the servo is driven by PWM either from the manual tester or from the Arduino servo library operations. And the electronics inside the servo use the PWM to drive a DC motor. Do you know if the power and ground can be used with say 12 volts to drive larger motors? Is the one in your video running at 5 volts? You'd have to use a common ground of course but that's easy. Do we know what the electronics in the servo consists of?

I have published over fifteen articles describing servo based track switch control and animation projects. I've used a number of control devices from a wide variety of sources. Some inexpensive servos can be a bit tricky, so watch out. These projects included manual and automatic sequencing triggered by magnetic detectors and both smart and regular IR detectors. Servos are amazing and can be used in an almost unlimited way to enhance action on a layout. I encourage forum members to keep experimenting and report their results which I will happily study.

Consolidated Leo posted:

mikeexplorer posted:

I would think programming it may have some similarities to ladder logic and I might be able to help.

Mike: Ladder logic is an old school method of industrial programming with relays; 2 in series for AND, 2 in parallel for OR. I realize that they still use ladder logic for modern PLC (programmable logic controllers) systems but that's because they didn't want to have to change things over when they had so much invested in the older technology. That and the fact that the transition most likely involved both older equipment along with the new. It's odd that ladder logic is still used in industrial control environments.

The Arduino (pronounced: ard - as in aardvark, ui - as in ween from Haloween, and no - as in no meaning negative) is much less restrictive. Of course it does involve logic but the mechanisms of the programming language are much more open.

The Arduino uses a version of the "C++" programming language that came from the older "C" language developed at Bell Labs. C++ is an object oriented language that allows for the creation of new entities that have common functionality. For example: you can create an LED object that can have methods to change its state like so:

#define LED_PIN 13

LED myLed(LED_PIN);
myLed.on();
delay(1000);
myLed.off();

These objects in the Arduino world are refered to as a "library". There are a number of libraries already available for the Arduino including a Servo library (as described here).

There's a lot more to it but I think you've got the idea. There are plenty of books, videos, etc about the Arduino platform as well as the C++ programming language. You might want to give them a try.

  -- Leo

Oh I agree, Ladder Logic is quite different from what you describe. I have not looked into Arduino, but from what I see, you can use modules with different functions for input & output. It reminds me of years back using an old TRS-80 Color Computer, plug in cards could expands its input-output ability and once I designed a control system for environment and wrote the software in a program similar to C+.  It supported both digital and analog input & output.

I have found so far with ladder logic, it does not allow loops. It trips a fault in the PLC due to the scan time. This is quite different then C+ or any similar programming language.

My purpose for doing this project is to learn ladder logic because in my job, we use PLC's for controls. The model railway gives me a real world example since the is variation on the layout as far as train speed, tripping block detects, and so forth. The parts I used to build this came from my previous job where they were scrapping old machines and I took these parts. Eventually I would like this to control my ceiling layout with an HMI panel.

For most other people, this type of project is impractical.

Mike

Mike: With your background, I'm sure that you will be most helpful with upcoming programming tasks. From what I know about industrial control systems, they're mighty cool looking; big buttons, lots of flashing lights, connections all over the place. Not exactly science fiction but you could do worse. I have a brother who works with PLC stuff in a steel mill. In his last job, he worked with the rail system at another steel mill. I was so jealous.

I hope your project works out for you. Keep in touch. I hang out around the Electrical Forum most of the time.

BOB WALKER posted:

These projects included manual and automatic sequencing triggered by magnetic detectors and both smart and regular IR detectors. Servos are amazing and can be used in an almost unlimited way to enhance action on a layout.

Bob: I've seen some of your stuff on YouTube; the car unloader and the station with the backup detection. Pretty cool! That's the kind of ingenuity that gets others to realize that they too might be able to put together their dream project. I'd say there's a lot of room for innovation that can be brought out in a model railroad. The kind of stuff that makes people wonder, "How'd they do that?"

Consolidated Leo posted:

... Do you know if the power and ground can be used with say 12 volts to drive larger motors?

---Is the one in your video running at 5 volts? You'd have to use a common ground of course but that's easy.

...Do we know what the electronics in the servo consists of?

1.  For years the standard operating voltage has been around 5V...or in practice 4 or 5 rechargeable batteries, 1.2V each, so, say, 4.8V to 6V DC.  From what I can tell, there's some hand-wringing going on about how to deal with Lithium/LiPo battery packs which run around 3.7V, 7.4V (for 2), etc.  I am not aware of any standard hobby servo that accepts 12V. 

2. Yes, the servo exerciser is powered by 5V DC coming in on the right side in my picture/video.  That same 5V DC (red and black wires) simply passes thru to 2 of the 3 wires going to each servo.  Same for an Arduino set-up.  The 5V DC for the Arduino itself is 2 of the 3 wires going to each servo.  Of course, that's just goes to the attraction - the 5V DC is already there to power the Arduino itself.  Connect 1 more wire and you're off to the races!

3. I'm sure someone who's been in the "game" for a while can dig out an early servo circuit which used all "analog" electronics, but I can't imagine any servo today that does not use a programmed digital IC.  It is this high-level of integration that makes me think there are no provisions to "tap in" to the tiny servo board to inject 12V or whatever to drive a bigger motor.

I have opened to modify a wide-variety of servos and there's always one "magic" chip surrounded by a dozen or so basic components.  The magic chip might look like the 2 shown in the right photo above.

So tying it back to the topic at hand.  If the objective is to leverage the standard servo.write library and drive a modified standard servo such as a CRS, I'm suggesting you don't have to constrain yourself to the DC-motor and gear reduction of the standard servo.  A standard servo DC motor might have a measurable DC resistance of, say, 10 Ohms.  At 5V DC, that's a maximum current of 0.5 Amps which is really quite a bit of power.  I specifically picked lower-voltage DC gear motors in my previous post.  You will typically find operating currents in the fine-print which might be 0.1 Amp (100 mA) range for tiny DC gear motor.  Or just measure the DC resistance of the motor and if it's around 10 Ohms (or more), then no problem to drive it with the guts of a standard hobby servo.

At the risk of inciting mob violence, there is no such thing as a 12V DC motor.  There are zillions of DC motors that are designed to operate at 12V.  Perhaps semantics, but most DC motors that say "12V" can be driven at 5V or 4V at reduced speed and perhaps far away from its sweet-spot of power efficiency (Horsepower per Watt).  But for layout train animations you might well find a 12V motor might work just fine.  For example, measure the DC resistance and if it's 10 Ohms or more, hook it up to a 5V DC supply and see what happens.  If it spins slow/fast enough and can move your animation mechanism then you can pass go and collect 200.

Here's a 12V gear motor mechanism you might be familiar with! 

The truck has a Mabuchi RS-365 typically thought of as a 12V DC motor.  The servo exerciser is being powered by 5V DC.

To be sure, the RS-365 motor is made by the gazillions and used in many consumer appliances like hair-dryers and what not.  So I don't know if the exact version used in an O-gauge diesel truck is the one above data table from the Mabuchi website.  Most datasheets will specify the stall-current (in Amps) at some nominal operating voltage.  The stall-current is essentially the worst-case (maximum) current that the motor draws.  Ohms Law then tells you the resistance of the motor winding or effectively the worst case load on the servo electronics.  This simple calculation is one way to confirm the electronic guts of a 5V DC powered CRS can "safely" drive a different DC motor.

Stan: Thanks again for the information! I'm trying to understand how the standard servos actually do what they do. This video goes through some stuff that I was unsure of before. It also identifies the magic chip on the circuit board but I'm sure there are others available and in use. Here's a diagram for the KC5188:

Quite a supporting cast. The datasheet I found was not in English.

The video quickly runs through some of what has to happen to turn the input signal into the proper operations for the motor. I believe he mentioned an H-bridge setup. That's a little over my head but I think it has to do with directional control for the motor.

I also spent some time poking around in the Servo library to see how they generate the PWM signals. It has to do with the on-board timers that generate interrupts continuously. And since there's no feedback to the Arduino, there's nothing to stop the PWM signal from being sent to the servo forever.

The Servo library also has a Servo.writeMicroseconds function that takes values that correspond to the length of the pulse width beween 1 and 2 milliseconds of the 20ms wavelength. You feed it 1000 for fully CCW, 2000 for fully CW, and 1500 for the midpoint. But I don't understand how the servo electronics can interpret those signals for a CRS to affect the speed of rotation; but clearly it does.

Consolidated Leo posted:

The video quickly runs through some of what has to happen to turn the input signal into the proper operations for the motor. I believe he mentioned an H-bridge setup. That's a little over my head but I think it has to do with directional control for the motor.

That's a pretty good video - including a description near the end of the CRS...though I don't think he actually uses the terminology "Continuous Rotation Servo".  I think this is a phrase that someone coined and it stuck.  There are limitless online tutorials and video on the "H-bridge" setup.  "H-bridge" is another one of those terms that someone probably made up and it just stuck.  4 transistors and a DC motor that when drawn out in schematic form looks like the letter "H".  From the video:

But to bring this back to OGR relevance, the video and the KC5188 diagram provide some insight into the practicality of modifying a standard hobby servo to use a larger DC motor for O-gauge animations.  If the 4 transistors of the H-bridge motor driver are integrated into the magic chip, it stands to reason they will operate at the same voltage as the chip itself.  So that would be about 5V or whatever is coming from the 2 (of 3) power wires from the Arduino connection.  To work at a higher voltage or to drive more motor current you'd need to use external transistors.

Note that your KC5188 diagram shows 2 external transistors. 

Then, in the video, the guy describes how some larger servos have the entire H-bridge external - in the example there are 2 transistors in each of those black packages.  The magic chip is on the other side of the board.  But the H-bridge is still being supplied by 5V since that's all that's available from the 3-wire Arduino connection.

I'm sure someone out there has modified a standard hobby servo to operate at 12V.  But I figure there's a tipping point where the effort to modify the electronics of a standard hobby servo would be better spent modifying the Arduino library to drive a generic DC motor with a 12V H-bridge shield (for CRS operation), and then for standard servo operation to read an analog input pin to sense the angle from a potentiometer on the output-shaft.

Consolidated Leo posted:

I also spent some time poking around in the Servo library to see how they generate the PWM signals. It has to do with the on-board timers that generate interrupts continuously. And since there's no feedback to the Arduino, there's nothing to stop the PWM signal from being sent to the servo forever.

The Servo library also has a Servo.writeMicroseconds function that takes values that correspond to the length of the pulse width beween 1 and 2 milliseconds of the 20ms wavelength. You feed it 1000 for fully CCW, 2000 for fully CW, and 1500 for the midpoint. But I don't understand how the servo electronics can interpret those signals for a CRS to affect the speed of rotation; but clearly it does.

Yeah, the video is a little vague on if/how the servo electronics affects the speed of rotation if you modify a standard servo to CRS operation.  The technical explanation gets fairly nerdy but it has to do with how feedback is implemented in the standard angle-control configuration.  These servos use so-called "proportional control" (Google it).  Simply stated, you look at how far you are from your target, and apply a correction (motor drive) that is proportional to the error.  So if you are far from the target, you drive the motor harder.  In a CRS the feedback is cut so that the electronics always thinks the output shaft is at the mid-point or servo.write(90).  Servo.write(180) is an error of -90, servo.write(170) is an error of -80, and so on.  Since the motor drive voltage is proportional to the error including the "sign" or polarity, that's how servo.write(0) to servo.write(180) can span the speed range in both directions (+ or - error).

The "problem" is this is not calibrated in RPM.  As to how to modify a standard servo to accept servo.write library commands and effect calibrated RPM is a separate can of worms.  That's another one of those tipping-point situations where if that's what you're interested in, it's best to go down a separate path.  I think most O-gauge animations do not need such capability - and the ability to move CW and CCW with some range of speed control using simple servo.write commands is good enough.

Stan: Thanks again! That all makes perfect sense!

I understand using a potentiometer as half of a voltage divider (the other side being a fixed resistance) to obtain a ratio that drives the gate of a transistor. So that enters into how the comparison is done with the target angle of a standard servo. That along with the magic chip and the H-bridge certainly covers what I was wondering about. Man, these little gadgets are awesome!

Now that I know approximately how they function, I think that I will look into hooking them up to some manual turnouts to make them into remotes. I won't be slamming them into position by just asking for the final angle. It will be incremental Servo.write calls with a well tuned delay in between.

Consolidated Leo posted:

stan2004 posted:

It seems to me the take-away of this discussion is the use of the servo.write functions to easily get up and running with an Arduino and a servo.

 

Stan: Right, but more generally, that all kinds of automation are possible with a microprocessor. Add in cheap relay modules along with homemade train detection circuits and LEDs for trackside signals and now you can build some good stuff; a reactive layout. Not exactly a new idea but now with the costs at a level that makes it very practicable.

Think about how a conventional layout could be setup to use isolated blocks to control more than one train on the same track. You could follow each train around the layout through its own transformer. You could use large bridge rectifiers (diodes to reduce voltage) to slow down a train as it approaches a more restrictive signal; trains would maintain a safe stopping distance without any operator intervention. All made possible because of the simple but sophisticated microprocessor watching over the entire enterprise.

I imagine many Arduinos around the layout controlling turnouts, led signals, power districts, talking to each other, running switcher operations in the yard to build a consist; and that's just for conventional mode. TMCC, Legacy, DCS, DCC are all candidates for automated control as well.

Sounds like fun to me!

My layout which I posted pictures here is a wall mount.

https://www.nepaview.com/the-w...t-counstruction.html

One problem I had is my house is not level, so trains would race on one side of the layout, and creep slow on the other side.

I uses a series of diodes, back to back and a rotary switch to select how many diodes are in the circuit. Each diode set drops the voltage by 0.7 volts so i use 4 per set for a 1.4 volt drop, up to 7 volts. I use this dropped voltage on the downgrades of the layout to even out the speed of the train. It has worked well for me.

Mike

Consolidated Leo posted:

Mike: With your background, I'm sure that you will be most helpful with upcoming programming tasks. From what I know about industrial control systems, they're mighty cool looking; big buttons, lots of flashing lights, connections all over the place. Not exactly science fiction but you could do worse. I have a brother who works with PLC stuff in a steel mill. In his last job, he worked with the rail system at another steel mill. I was so jealous.

I hope your project works out for you. Keep in touch. I hang out around the Electrical Forum most of the time.

If there is enough interest I can start a thread with my project so it does not hijack this thread.

Mike

mikeexplorer posted:

If there is enough interest I can start a thread with my project so it does not hijack this thread.

Mike: Interest is never guaranteed but I've seen a number of threads about project builds on this site that are very involved and lengthy. I'm just not sure which of the forums would be appropriate for that kind of topic. You'll have to decide that for yourself. You might want to look around for those other long (and I mean months) of build updates or ask the moderators in the Tech Support forum.

Sharing what you're up to is how we all learn and advance in the hobby. By all means start your own topic.

This is my connection diagram that sets block power according to the signal indications of the block. It uses groups of diodes (in the bridge rectifiers) to reduce the voltage to the track and slow down the trains (conventional mode only) depending upon the signals. I plan on using some form of ABS signaling on the layout. This is just in the planning stages.

Leo;

Like your relay idea. I did something similar a few years ago on my last layout. Only difference was I used power resistors instead of the diodes. Worked reasonably well as long as the motive power was similar current. Your diodes should negate that problem.

Jay

mikeexplorer posted:

If there is enough interest I can start a thread with my project so it does not hijack this thread.

Mike: Take a look at this thread on layout building progress. Note that he uses the Trains Forum and particularly the Hi-Rail, O27 and Traditional 3-Rail O Gauge grouping for his topic. That one has been going on for over a year now. Just an example in case you're wondering.

As far as hijacking this thread, I've got that covered.

Given the thread topic of using a servo with an Arduino, here's another idea for controlling conventional track voltage to smooth out speed variation going up/down grades and so on.  If an Arduino is involved to select the number of diode-drops in some kind of sequence, why not use a standard servo with an Arduino to turn the voltage control knob of an MTH Z-controller transformer?

This allows smooth ramping of the increasing/decreasing voltage rather than finite jumps based on the diode drops.  The voltage will be proportional to the servo.write(x) value.  If you power the entire loop with the output of the Z-controller, this eliminates having to create isolated power blocks fed by different taps of the diode-dropping string.

Then, since even the entry-level Arduino provides 2 servo control outputs, you can use the 2nd servo to trigger both the Whistle/horn and Bell buttons.  Since the two buttons happen to be adjacent on a Z-controller, a servo.write command of >90 will swing the arm toward the Bell button, a servo.write command of <90 will swing the arm toward the Horn/Whistle button, and servo.write(90) will be the idle position.

Note that an Arduino would be perfect for sequencing timed button presses such a short and long horn triggers to automatically generate grade-crossing warning blasts.  Or, if you operate MTH conventional engines, the Arduino could sequence the Bell and Horn/Whistle buttons to activate features such as firing the coupler or, as shown in the video, activate "PFA" Passenger-Announcement using the Bell-Horn-Horn sequence.

With servos available for 99 cents and entry-level Arduino controllers for $2-3...

Stan: There you go being clever again! Tell me that you didn't glue mounting brackets to your transformer! 

These are some interesting ideas. But I'm having a hard time trying to classify them in my brain. Is it electronics controlling a human interface, bridging the gap between man and machine. Or do we just stand back and ask "What's it doing now?" I don't know, it just seems kinda redundant while at the same time being marvelous and practical. I fear that at any moment things will degrade into a tight loop and trains will be flying off the corners. 

You won't get any argument from me. I like this kind of thinking. You show signs of potential. 

If your layout is at the point where you are looking for animated features control & automatic speed & voltage control using servos this is a great thread. I can see where using the Arduino platform to control your layout & things on your layout is here.

But if your layout is not that far along & you are in the track laying phase & looking for a better way, is there anyone here that has used servos instead of the traditional switch machines ( Atlas, Tortoise, DZ's) for throwing Turnouts thru out there layout? Using the Arduino platform to control Turnout servos as opposed to the others mentioned  would be very cost effective. Has anyone here done that or know if it has been done successfully?

I have published several articles showing the use of servos to operate track switches.

Bob; I know the one was in the 10/15 CTT, could you direct me to the others?  Do you know anyone who is using this method on there layout?  I would like to talk to them about a couple of different things pertaining to there use. ie: mounting, ease of overall wiring, reliability, satisfaction, things like that. 

Thanks

Boy, did I start something with my initial question! All kinds of information on using servos on layouts.

Still looking for a way to start one servo running, stop it, do something else, then go back to the first servo to finish it's cycle.

Anyone have an idea on that?

Thanks.

Jay

The classic embedded software application loop has no problem managing multiple tasks.  If you want to control the speed of the servo at other than it's native warp speed, you can have a timer interrupt that services the PWM to the servo at the desired periodic rate.  With that technique, you start the operation and define it's bounds in the main software loop, and then the timer ISR manages the steps until the servo reaches it's end point.  You can manage multiple simultaneous servo loops in the same manner.

For example, here's a Boeing 727 Mach Airspeed from 1980, I used the Texas Instruments TMS9980 microprocessor to manage four stepper motor loops.  The processor also had to handle all the other processing required for the various INOP flags, input data conversion, and output signals.  All the stepper motor servo loops had acceleration and deceleration at startup and end points.

The processor I used is much less powerful than the Arduino, of course it was 37 years ago as well!

Jerry D.  Will email you list of my articles and you can pick out what what you need.

Thanks Bob I got them.

trainman129 posted:

Still looking for a way to start one servo running, stop it, do something else, then go back to the first servo to finish it's cycle.

Jay: In terms of a CRS (continuous rotation servo), starting it running is easy. You can determine speed and direction by the value that you use with the Servo.write function. The midpoint will be near 90 degrees (you may have to tune that value) which means that its not moving in either direction. A higher value moves in one direction, a lower value in the other direction. The further from the midpoint value, the faster the speed of rotation. The value 0 is the fastest speed in one direction while the value 180 is the fastest speed in the other direction.

servo1.write(100);  // servo is running CW at slow speed

To stop the servo at any time, issue the write command with the midpoint value.

servo1.write(90);  // servo is stopped

To go the other way, the values are lower than 90 degrees.

servo1.write(80);  // servo is running CCW at slow speed

So that's how you can start it and stop it. The rest is just a matter of control and timing.

Perhaps this is a good time to get into the two timing methods available with the Arduino. There is the delay function that requires a parameter that indicates the number of milliseconds (thousandths of a second) to wait before continuing with the program. It is often used and seen in sample programs that do very simple things and nothing else. I say nothing else because delay is a blocking function. Nothing else in your program can happen until the delay time has completed. Interrupt Service Routines may be the exception but that's not the issue here.

In this article there is a pretty good explanation about why you should not use the delay function in more robust programs that are handling real time events. The solution is to use timing values like those available from the millis function. It gives the number of milliseconds since your program started running as a long unsigned value. To determine how long something has been running as you go through the Arduino "loop" multiple times, you can store the start time in milliseconds and then check it against the current time as illustrated in the following:

...
int phase = 0;  // control variable for loop
unsigned long startTime = 0;  // servo start time

void loop () {
  if (phase == 0) {  // initial phase
    if (startTime == 0) {  // servo not yet running
      servo1.write(100);  // start the servo running CW slow speed
      startTime = millis();  // get the start time in ms.
    } else {  // servo is running; stop it after 5 seconds
      unsigned long now = millis();  // get the current time
      if (now - startTime >= 5000) {  // 5 seconds has elapsed
        servo1.write(90);  // stop the servo
        phase++;  // next phase of program
      }
    }
  } else if (phase == 1) {  // do something else
...

Is there an advantage to defining 'now' in the program over defining it above as was done with 'starttime'? Just curious?? Or was this just an example of another way to define it?? I am still learning...