On the same trail...

Dear Charlie,

I've both been-on, and am-currently-on a similar path. Here's what I've learned.

Where I've been

- Early Wathers/Helijan non-DCC HO turntable, converted to dual-gauge On2/On42

- Drive/Indexing circuitry by our own Pelsea's "Arduino Driven Turntable"
https://model-railroad-hobbyist.com/node/28501
/> https://model-railroad-hobbyist.com/node/28501/?page=3/#comment-272281

- Original drive system was a common Arduino  28BYJ-48 stepper motor + ULN2003 driver
https://www.jaycar.com.au/arduino-compatible-5v-stepper-motor-with-controller/p/XC4458
/> https://www.jaycar.com.au/medias/sys_master/images/images/9594847035422/XC4458-dataSheetMain.pdf

fed thru a repurposed Ath Bluebox diesel truck
(RH gearbox with worm drive, 14:1 ratio, and easily tuned for minimum backlash)

The initial testing looked very promising, even under an actual 1 kilo (2.2pounds) of brass loco,...

...but then, for "reasons lost in the sands of time", (something about "layout built with no clear leadership"?)
the proposed Ath-truck gearbox solution was replaced with a scratchbuilt 90-deg 1:1 ratio spurgear gearbox
(milled styrene gearbox frame, brass hardware and shafts, 3d print gears)

The result was that the gearbox failed to provide either the required torque, step-ratio accuracy,
(as you've already worked out yourself),
and essentially failed to hold together in any meaningful way,
rendering the turntable "non-functional" for the layout's debut show... :-(
("...mistakes were made, lessons were learned, we moved on swiftly and don't generally talk about it...")

Where I'm at right now

- A 40" long, 5-track "train staging turntable" in On2
(think about that, fully loaded, that's almost 10 kilos of train, + the turntable itself)

- Sitting on a metal roller-bearing "lazy susan" bearing pivot unit

- Again, controlled/indexed by the self-same Arduino stepper motor unit C/O Pelsea's excellent threads above

- With an upgraded Stepper motor driver array (more on this later)

- driving a NEMA17 100:1 gearhead Stepper motor
https://www.omc-stepperonline.com/precision-planetary-gearbox/nema-17-stepper-motor-l39mm-gear-raio-1001-high-precision-planetary-gearbox-17hs15-1684s-hg100.html

- This motor is mounted vertically, and coupled directly to the turntable, with a horn/slot coupling.
(No intermediate gearbox, no 90-deg gearbox or worm, 100% rigid-lock rotation-transmission while tolerating any slight out-of-perpendicular alignment in mounting between the motor and the turntable deck).

The resulting rig has a step-angle of 0.018deg, which gives an arc-length per step on a 40" turntable-end of 0.006".

FYI, given a piece of PECO Code 83 rail has a railhead width of 0.030",
0.006" (5-steps across the width of a railhead) is well-enough "step granularity" to achieve required alignment...

 It also delivers around 60kilos of torque (15nm), so more-than-enough to handle the proposed Turntable+Load from a standing start, and a standing-stop!

The Gotcha is the Volt/Amp behaviour. While the specs say the motor draws 1.68Amps (per coil, x2),
reading further that's at 2.7 volts.

I'll admit I missed this detail,
tried to drive it using ONE L298P stepper motor driver (2A per H-bridge) at 12Volts,
which means I tried to drag 2x 7.5Amps out of the poor hapless L298P driver circuit,
and somehow managed to NOT let the smoke out!?!?!?!?
(some DCC++ fans have said that the L298P H-bridge doesn't have adequate "over-current protection",
but I took a pair of L2998P driver units well over 4x their MAX rated current, and they somehow survived to fight another day!!!)

After powering the entire smelly (but NOT smoky!), obviously unhappy rig down,
taking a good long night's sleep,
and re-assessing the whole situation in the cold hard light of day,
I realised:

- If I use a 2-channel L298P driver unit
- in "Bridged Mode" (both channels of the unit wired in parallel, and working as a 4Amp-capable team)
- multiplied by 2x L298P units (One of the Bridged L298P per coil, the motor having 2x coils)
- each L298P powered by it's own 5Amp 5Volt PSU
(That's 2x 5Amp 5V PSUs for the "driver circuits", + a lower-current 5VDC PSU for the Arduino "brains")

the resulting rig:
- achieves the stated 0.018deg/0.006"-per-step accuracy (20000 steps/rotation)
- while staying well within "operating temp" specs
- easily handling over 2x the expected operating load, inc "inertia loading" (stopping and starting consistently/accurately)
- and achieving a full-speed rotation in 60 seconds

In terms of "the seeking of speed", I would suggest:

- Remember that, unlike a regular Permanent magnet motor (loco motor),
Voltage is not directly relevant to speed of a stepper. Rather, it's all down to the switching speed/code speed of the drive circuitry. Increasing the Operating Voltage of the "driver" part of the circuit will only increase the Strength/Torque and Current-Draw of the system, NOT the Speed!

- Make sure your Arduino code is optimised, ANY excess-lines in the sketch inc comments only serve to Slow-Down the speed the Arduino can run-the-code-loop and do a "stepper output state update"

- If you have "Serial Print" statements in your sketch, IE so the Arduino IDE can give you are readout of "Current step position", etc, remove them once you're comfy the Arduino code works.
I found that my unit would actually change speed of Stepper-motor steps as the # of characters in the "current position" serial readback changed.

EG given an acceptable speed when the Serial Monitor was showing "Current step = xx" (tens of steps),
the motor moved Slower when it jumped-up to "Current step = xxx" (hundreds of steps)
and slowed again when the Serial Monitor jumped-up to "Current step = xxxx" (thousands of steps),
and slower-still when we stepped up to "xxxxx" (10,000s of steps).

By eliminating the "Serial write 'current steps' " lines in the sketch, the motor sustained a constant speed,
(set by the potentiometer in Pelsea's Arduino Turntable circuit),
all the way from "Step 1" to "Step 20000", and even when it "wrapped around" from 20000 -> 1...

I'm not sure if these experiences and musings help, but assuming a decent-spec NEMA motor and mating gearbox (remember, Overkill is Under-rated, esp in "I don't care what gets thrown at the system,
I want it to Just Work" situations, it's called "Ensuring Adequate Headroom"),
you should be able to achieve a "low single-digit minutes per rotation" performance from your turntable...

If you'd like any pics of the example parts and circuitry mentioned above, just holler...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

add encoder for position verification

see  Adding Encoder to Older Walthers Turntable to Support Indexing with PID Control

Another approach

Although it's not quite the solution to your immediate problem, Charlie, some details of a turntable stepper drive and Arduino controller I designed recently for my brother's N-scale layout might be of help to you. The pictures below show my prototype version with a hand-cut indexing disc, built on some scrap 3D-printed components my brother Derek had produced for an earlier project (he has subsequently produced a tidier "production" version of the turntable mechanics but, unfortunately, I don't have any pictures of that) -

The turntable is driven directly from a geared stepper motor. This is a NEMA-11 with a 5.18:1 ratio gearbox (StepperOnline 11HS20-0674S-PG5) which gives 1036 steps per revolution. The Arduino Nano interfaces to a TMC2208 stepper driver module which is set for 16 microsteps/step (internally interpolated to 256 microsteps) giving an effective 16576 steps/revolution, or 0.02 degrees/step.

Indexing is controlled using the 130mm diameter slotted disc shown above, with an optical sensor to detect when one of the 24 slots passes under the sensor. Use of the disc eliminates any problems with backlash in the gearbox. Each slot is 0.5mm wide, corresponding to about 20 microsteps. The sensor detects the edge of the slot, then the Arduino moves 10 microsteps further to leave the assembly positioned in the centre of the slot. Since power to the stepper motor is removed when it is stationary, the position of the indexing disc is maintained by using a couple of roller microswitches which "click" into the ends of diametrically-opposite slots as you can see in the first picture (the microswitches are not connected electrically to anything).

There is also a second optical sensor mounted below the indexing disc to sense a tag attached to the underside of the disc and hence report when the turntable is at the "home" position - see the third picture above.

Rotation of the turntable is very smooth and silent, and can be controlled either via the small 4-button keypad you can see in the pictures, or via a Visual Basic program running on a PC connected to the Arduino Nano USB interface. The PC software provides a visual indication of the current turntable position and allows the overall speed of rotation to be set from 8 steps/sec (130 seconds for a complete revolution) up to 32 steps/sec (32 seconds/revolution). All of the motor control resides in the Arduino code, including smooth acceleration and deceleration. Although intended for an N-scale layout, there is more than enough torque for the motor to drive larger scales. Further details can be supplied if you (or anyone else) is interested.

What? Prof,

Have you evidence of this?

My experience with compilers tells me comment lines don't contribute anything to executing code.  What machine code would result from a comment?

And,

That shouldn't surprise you, as it takes time to transmit per character.  A 4-character numeric thus would obviously take more time to transmit than a 3-character numeric.   Why would it not?  In the wild world of multithreaded OS with multi-core CPUs, be it PC, Mac, Linux, or what have you, handing off a string to a transmit engine won't necessarily impact the execution of the thread you're running in, but the Arduino is a one-lung machine.  It can't buffer-and-transmit while allowing your thread to run concurrently.

Blair

low-tech optical alignment

don't understand why the image in the link doesn't show in the post

http://www.pacificsouthern.org/Images/IMG_0565a.JPG

it shows a disk on a turntable under the bench with brass flag used to locate the turntable stops as they pass thru an optical sensor.  yes, movement should be from one direction.   alignment is easily correct by giving a flag a nudge

a  dc motor with a rubber head attached to its shaft is mounted  to press on the plywood disk the flags are mounted  to. it's driven until alignment is reached

Comments?

I expect the Prof through a slip of the tongue (or keyboard) used "comments" to refer to print statements that are commenting on the state of operation of the Arduino software.

Serial.print() statements definitely make things run more slowly. 

When measuring RPM I used no Serial.print() statements inside the inner loop. Only when a move of the bridge completed did I use Serial.print() to print out the statistics on the move.

As ACR_Forever points out softwarecomments ie.

   // this is a comment 

   /* this is another comment */

do not generate any code and have no effect of program execution or speed of execution

Charlie

Bridge positioning precesion

According to the Diamond Scale instruction sheet, the bridge of an HO scale turntable should be positioned with an accuracy of 1/64th inch or roughly 0.016".

I used MicroEngineering flex track. I measured railhead width of 0.032" for code 83 and 0.031" for code 70 rail. I'd like better than 1/2 railhead width accuracy.

For the Nema-08 solution I'm investigating I need 0.7 rpm at the bridge

0.7 rpm x 50:1 gear ratio = 35 rpm on the worm-gear shaft

35 rpm / 60 = 0.583 revs / second

The Nema-08 stepper has 200 steps / rev so 0.583 revs/second x 200 steps/rev = 116.7 steps/second or 8.57ms per step. That number seems very doable given that I'm able to clock my current stepper with a step interval of 1.6ms/step. In fact it's a 5x slower step interval. That opens up the possibility of 4x micro-stepping to improve smoothness and decrease noise.

However 200 motor-steps/rev * 50:1 ratio = 10,000 steps per bridge revolution

360 deg/rev / 10,000 steps/rev = 0.036 degrees/step

The bridge is 18" so turntable pit circumference is 3.14 * 18 = 56.5" 

Dividing by 10,000 steps yields 0.0056 inches/step which is better than the 0.007" accuracy I wanted.

I'm hopeful that once the Nema-08 stepper arrives (on Friday if all goes well) things will come together and I can start thinking about determining the absolute bridge position.

JerryC, I thought your disk idea seemed interesting. Instead of mechanical micro switches which require deglitching/debouncing, perhaps a tiny hole bored through the disk with a bright LED on one side and photo-transistors on the other?

I would use one hole and a number of photo-transistors. One or the transistors would be designated "base position" and the distance (in steps) to the others would be measured and saved in the Arduino non-volatile memory during a "calibration" cycle.

In normal operation as the hole passes the LED/transistor stations the current bridge position would be updated to correct for missed steps.

Instead of LED/phototransistors, Geoff Bunza suggested multiple Hall effect sensors and a tiny magnet.

Time for a bunch of experimentation!

Charlie

I wonder if...

...Horace has any suggestions?!

Glad to hear progress, albeit slow, is being made!

Ken L. 

cost of comments.

Long ago, like for very early BASIC interpreters, I believe interpreted languages read and parsed each line executed, one at a time, and so a comment, particularly in a loop, would be parsed (and discarded) each time through the loop. These old interpreters would run a program containing a syntax error up to the point of the error and then stop.

One of the very first optimizations they made was to hack together something that would make all that faster for loops and keep them from being reparsed per iteration. So I would say comments haven't had an execution time cost since the 1980's. Of course antique systems may remain in use, a bit like the model T.

But ever since Java, interpreters became more like compilers and I venture to say just about all compile the source code to a byte code before execution starts, then interpret the byte code stream.  Which will have had the comments removed by the parse step.

And of course real compilers have never had an execution time penalty for comments, or code inside inactive C conditional compilation directives (#ifdefs). Which are the way to go if you have liberally sprinkled in print statements throughout the code. You create a macro PRINTDBG() that takes your print arguments and expands to a print statement, or not, depending on the value of another symbol which you define (or not) on the command line. 

I don't know how the arduino compiler works for sure, I thought it was a pretty standard C front end married to a custom back end compiler.

Print statements do run through a lot of code, so they certainly slow things down in a real time system.

Some clarification

Charlie,

The microswitches on either side of the slotted disc do nothing regarding the control of the turntable (as I said previously, they are not connected electrically at all) - their rollers are simply used for mechanical indexing, to hold the disc in position when the stepper motor is unpowered. You could use any other form of lightly-sprung roller for this purpose.

The single optical sensor mounted to the left of the disc provides all of the position feedback required to control turntable movement - there is no need to have a multitude of phototransistors or magnetic sensors to do this job, with all the problems of interfacing them to the controller. Here, when the turntable is commanded to move to a new position, the Arduino Nano drives the stepper in the required direction until the edge of the current slot under the optical sensor is detected - this eliminates the effect of any backlash in the stepper gearbox (can be up to 1 degree) if the motor was previously moving in the opposite direction.

Once the edge of the slot is reached, the stepper is accelerated smoothly to the set speed of rotation. If it is to move only one track position, deceleration starts when it reaches the half-way point between slots (determined by counting steps) and movement continues until the edge of the next slot is detected. The turntable is then moved a further 10 microsteps (each slot is 20 microsteps wide - 0.5mm) to place it in the centre of the slot, and power is removed from the stepper motor. The microswitch rollers should then have settled into the ends of the appropriate slots, and will hold the disc in place mechanically until the next movement is required.

If the turntable is required to move several track positions, it will accelerate to the full set speed over one slot distance, continue moving at this speed until it is one slot position from the destination, and then decelerate to a stop in the destination slot.

To determine the turntable "home" position, there is a tab fitted underneath the disc at the appropriate point, and a second optical sensor has its infrared beam interrupted by this tab when the turntable reaches "home". The position of this tab is not at all critical, as accurate positioning is still controlled by the slot optical sensor. The "home" tab is really only required if the turntable has been moved by hand when the controller and stepper are unpowered. Otherwise, the Nano is fully aware of the current turntable position, and remembers it in non-volatile (EEPROM) memory when switched off. The only exception is when an emergency stop is activated - once things have been sorted out, the turntable is rotated by the Nano until the "home" position is detected, and the correct position of the turntable can be restored to the controller's memory. 

I hope this makes things clearer - if you want any further information, just ask.

resolution

    DiaFt    DiaIn     Circ     Rail      Deg    Steps

       72      9.9     31.2    0.030    0.346     1039

       83     11.5     36.0    0.030    0.300     1200

       90     12.4     39.0    0.030    0.277     1299

      130     17.9     56.3    0.030    0.192     1877

the table summarizes the resolution needed simply to get within on rail width (0.030").   a practical resolution may be 4 or more times greater.   micro-stepping the final position may be sufficient

That is some pretty brilliant Engineering Terry

Very elegant.  I love the 3D printed disc solution.

And all the comments re comments and compilers - it’s amazing to see so many gear heads and propeller heads in one place!  (I am both, plus a fair bit of a Marine Biologist) so feeling right at home in this discussion.   

Oops.....

The big problem that led me to post here was that the poor little stepper motor I had wasn't spinning fast enough to move the turntable bridge at a reasonable (0.5 to 0.8 rpm).  The Aruduino code was counting steps and measuring the time to make those steps. A little math and voila the program printed out the # of steps and the rpm at the motor shaft and at the turntable bridge.

The problem as it turns out wasn't in the stepper motor (well the 32 step with a 64:1 gear reduction still wasn't fast enough but not by a huge margin). The problem was between the ears.

starttime_of_move = millis();

for (do the requisite number of steps) {

    wait for the correct time interval then issue the next step

}

endtime _of_move = millis();

timeelapsed = (endtime_of_move - startime_of_move) / 1000.0;

RPM = (steps_moved / full_revolution_steps) / timeelapsed;

Can you see the problem? I sure didn't for quite a while...

RPM is revs per minute. But the computation is computing revs per second.

The divide by 1000.0 converts milliseconds to seconds not minutes.

The reported RPM numbers were actual 1/60th of the actual RPM numbers.

Now I feel much more confident the the stepper motors arriving tomorrow (if the USPS website can be trusted - lol) will spin the bridge at either 5 rpm or 3 rpm while stepping at the same steps per second that I can get the current motor up to. I'm suspicious the bipolar Nema-08 with 200 steps per rotation (and thus the steps could be smaller) may be able to spin faster.

Positioning accuracy without micro stepping should be 1/6th of a Micro Engineering railhead width or better.

Now I can't wait for tomorrow's mail.

Charlie

Ah, the old "order-of-magnitude error" trick...

Dear Charlie,

Good to hear the Light came On, and the trailing Zeroes started lining-up...

Looking forward to hearing how the NEMA8 motor goes, have you checked/confirmed the Volts/Amps/Coil-resistance specs again the Driver chip and PSU specs?

Happy Modelling, 

Aim to Improve, 

Prof Klyzlr 

Adafruit 16:1 geared 32 step 12V stepper

I ordered and received a couple of new stepper motors from Adafruit.

One of them is like the ones I have now except it's 16:1 gear ratio instead of 64;1 and it runs on 12V.

The other is the Nema-08 stepper motor (200 steps per circle). This one is bi-polar and I'm going to need some more breadboards to hook up power, calibrate the driver board to not feed it too much current, and try it out. The breadboards will be here Thursday.

The 16:1 geared stepper seems to work. At least I'm able to make it spin round and round and I came up with a means to handle acceleration/deceleration. However, it appears that it's not geared with a precisely 16:1 gear ratio. Would anyone happen to know what the ratios of the Adafruit 28BYJ-48 16 step, 12 volt stepper motor's gears actually are?

I've also got some hall effect sensors and once the new bread boards arrive I'll start experimenting with them.

And the fridge has be cleared out of turkey remnants (except for the pieces that escaped to the freezer). 

Charlie

12V 16:1 Arduino Stepper - gear ratio Oof...

Dear Charlie,

Per  https://circuit.rocks/28byj-48-high-quality-stepper-motor-12v

 Now, 513 steps / rev = 0.7 deg per step,

which I fear, without additional gear reduction, isn't really going to give the 0.010"\step @ ?? radii you need?
(Hint: a quick bit of maths with 

https://www.omnicalculator.com/math/arc-length
/>
says that if you drive your HO scale 130' turntable directly with this motor, each step will move the end of the turntable bridge by 0.109", over Three Times More than the 0.030" width of a HO railhead... :-(  )

Happy Modelling,
Aim to Improve,
Prof Klyzlr

PS just re-read the link above, and the "Feature List" points say:

Soooo, we might not even be able to trust this site as being "internally consistent" within itself! :-(
Still wouldn't give you the required turntable-end step-movement granularity though...

Breadboard Interfacing Arduino --> Drivers --> NEMA motor

Dear Charlie,

I hope you've got a load of jumper wires available...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

The way it might look

Here's the system I set up for our club. It uses a DC motor, not a stepper, and an optical alignment system which seems similar to the one in the picture from the Pacific Southern that Greg linked to. The drive is from the motor via a friction wheel to a horizontal disk under the table, so you can push the turntable out of alignment any time you want to, and it'll drive itself back. There is no mechanical locking.

Progress!

Last week while my friend Paul was over we discovered that the 3/16" steel shaft to which the worm gear (supplied by Diamond Scale) is mounted was slightly bent.

Tonight we replaced it with a new shaft. We also drilled and tapped set screw holes to properly mount the worm and pinion gears securely to their shafts.

The result was the gear train ran a LOT smoother. However there was still a problem. I had loaded my step counting test program into the Arduino Mega 2560 controlling the stepper motor (28BYJ-48 12V with 16:1 gearing and 32 native steps - an Adafruit special). It would run for a while, then something would bind and it would need a slight nudge to get it moving again.

We thought the set screw (actually a 2-56 round head screw) locking the worm gear to it's shaft might be the problem - as in too long and it might be hitting the pinion gear. It was shortened and reinstalled and that seemed to work a bit better.

At the same time I noticed the pinion gear needed to be raised about 1/8" to be at the correct height to mate perfectly with the worm gear. This also helped. A bit of LaBelle 106 grease didn't hurt either.

But the bridge was periodically stalling and not in the same place. The stall seemed to be random.

Then Paul noticed something was drawing a circle on the floor of the pit. We lifted the bridge a bit and the wire coming from the bridge vertical shaft has a blobbly solder joint left by the guy who had done most of the assembly of the Diamond Scale kit. This was apparently getting wedged between the drive block and the floor of the pit and causing the stop.

We lifted the bridge and set it on top of the drive block to test this. With the blob no longer dragging the strange lock ups disappeared.

The program being executed made 20 random turntable moves, then it computed the number of steps that had been made in each direction and calculated how many steps were needed to return the bridge to its starting position.

We put a bit of blue painters tape on the rim of the pit lined up with a bridge end and let the program run.

After 20 random moves plus the return trip the bridge was darn close to perfectly back where it had started!!!! I can't be sure of the accuracy of the return as the tape wasn't right next to the track on the bridge end, but it sure looked good.

I rejiggered the test to run 40 much larger random moves and stop. The results were the same. It sill appeared to be returning the bridge to where it started from.

One more good thing. When previously I had put a locomotive on the bridge, the stepper had been completely unable to move the bridge. At all.  We set a loco (precariously) on the bridge which was perched atop the bridge control block and the stepper easily moved it and the random moves then return to start position test still worked.

Tomorrow I'm getting an absolute rotary encoder with accuracy to 1/1024ths of a revolution. That in itself isn't enough accuracy to position the bridge exactly enough. But I'm hoping I can specify track locations by the absolute encoded position + some number of stepper motor steps. Of course this may not be necessary if counting steps proves to be accurate once the bridge gets reassembled. There will be at least one, and possibly 3 hall effect sensors to detect bridge position and make it possible to dynamically recalibrate the positioning system. So maybe the rotary encoder is a waste of money. But it cost about the same a one Kadee freight car so the expense wasn't too bad and maybe I can use it on the other turntable (a CMR 15") at South Jackson...

Anyway, major progress tonight!

Yay team.

Charlie

User interface

I've been thinking a bit about what the user interface for operating the turntable should look like.

I've built my own staging yard ladder turnout controllers that drive up to 10 tortoise switch machines. The interface is very clean. There's a knob and a 7-segment display. The display shows the track number.

To set the turnouts for a track one turns the knob which is attached to a rotary encoder. The track number display (7-segment LED) starts blinking. As the knob is turned the track number increments or decrements. When the correct track is reached, the use presses the knob (it's also a switch) and that lines up the turnouts to the desired track in the staging area. The track that's selected is saved in non-volatile storage in the Arduino Pro-Mini which drives the electronics/interface to the Tortoises.

For the turntable I'm thinking to use an encoder. Instead of 7-segment displays the panel would have a schematic diagram of the turntable and it's radial tracks. Each radial track will have a LED. As the encoder is rotated the targeted track's LED will start to blink (the current track's LED will be on solid - no blinking).

Once the desired track is reached pressing the encoder causes tells the Arduino running the show to figure out the shortest direction of rotation and the bridge moves to the target track.

Also, for manual types, there will be buttons for clockwise and counterclockwise manual operation. Press the button, the bridge moves one stepper step in that direction. Hold the button down for 1/2 second and the bridge will move until the button is released.

This control mode will be needed to program radial track addresses into the Arduino. That is accomplished iin a programming mode (as opposed to run mode). Flip the mode switch from RUN mode to PROGRAM mode, then use manual mode to move the bridge to line up with a track. Use the encoder to tell the Arduino which track is selected, then press the Program Track button.

It's a little more complex than that actually. I don't know for sure, but I won't be surprised if I need to program each track from both a clockwise and counterclockwise direction. And possibly for both the A end of the bridge (with the operators house) and the B end of the bridge.

To keep track of which tracks haven't been programmed yet, the LED's for the unprogrammed tracks will blink when its in program mode.

Then if while in program mode it's desired to recalibrate, pressing a Calibrate button (and also happening at power on) the bridge will rotate until the home position Hall effect sensor triggers, then it looks for the other sensors and marks their addresses. The addresses of the radial tracks shouldn't need reprogramming after a calibration (as long as programming is done after a calibration).

Why put LEDs on the tracks in the diagram instead of individual push buttons? Simple really, the pushbuttons need to be separated by around 1/2" The LEDs can be twice as close together letter the panel diagram be smaller.

So is this scheme usable or am I completely bug nuts? Or are y'all too confused to know what I'm proposing?

I did consider putting Hall sensors for every track, but there are 24 radial tracks for the Bear Creek engine service area and I don't relish the need to adjust 24 sensor's positions can only be adjusted by crawling under the benchwork, then come back up and test it. Not quite right, crawl back under... Etc.

What concerns me is how difficult will and engine hostler find it to related LEDs on a track schematic to actual tracks on the layout?

Charlie

control interface

i suggest using an arduino multi-function shied both to develop with as well as the final interface

of course, this isn't simple.    there needs to be a config mode to position the bridge and then save the step position for each track and a mode to simply select a track position.   

there may need to be a mode to edit (add, change, delete) an existing track position

the user interface needs to be able to switch between modes

in the config mode, buttons rotate the bridge clockwise or counter-clockwise unto appropriately aligned.   other buttons are needed to capture the setting after presumably selecting the track number being configured.

there needs to be a way to position the bridge so that either end is aligned with the track

an optical sensor in the pit can be used as a  calibration point so that the controller knows where the "zero step" is.   the controller would rotate to the calibration point at start up and would reset the zero point whenever it crosses the calibration point

if you're considering using hall sensors or optical flags, why not just use a DC motor?

Thoughts

Dear Charlie,

In order of appearance:

User Interface is directly related to Ease-of-Use, so definitely worth investing some time into...

Sounds like a good way to do it. Referencing Pelsea's Arduino Turntable unit from earlier,
my prior-posted example uses a "+" and "-" to increment thru a 10-step BCD counter. 
Once the track-number is selected, press the "Go" button and the Arduino does the Needful to get the turntable there...

(The BCD and black press "Go" button can be just seen to the Left of the temporary RED push button)

...I like your "graphical" solution more, in that it doesn't require the User to think
"...Hmm, which TT track was 'Track 6' again?..."

but then again, using a BCD with a simple fixed-graphic diagram probably saves Arduino pin-count and code....

In the above case, the silver Toggle switch to the RIGHT of the temp Red Push Button is oriented L<> R, and is a Mom/Off/Mom switch.
- Press LEFT = step Left
- Press + HOLD Left = Keeps moving left til released
- Press RIGHT = step Right
- Press + HOLD Right = Keeps moving right til released

Out of shot in the pic is a sawn-off potentiometer, mounted vertically on the Bottom face of the box. This acts as the "speed control". Full Clockwise = Max rotation speed, Full C-Clockwise = 1-step/sec, which is slow enough to easily "step, step, step" to dead-accurate single-step positioning.

FWIW, the Red puch button is temporary because it's the "save Current Position as Current-BCD-selected Track/Memory location" button. The theory is that, once installed and positions-set, the temp button can be unplugged from the Arduino, and the whole box "buttoned-up" for the foreseeable...

Logical, see above RE temp Red pushbutton

FWIW, Pelsea's unit/code does not need to be position-cal'd for both directions of rotation.

Depends on whether the "control paradigm" is based on:
- Nominated Consistent Turntable End goes --> specified position
OR
- Given Position "calls" for specified Turntable end to "come to it"

In my case, using Pelsea's code, the paradigm is
"focus on the 'A-end' of the turntable, and send-it to the required position",

although it occurs to me that I _could_ program the unit so:
- BCD numbers 0-4 are "Turntable A-end --> Track positions 1-5"
- BCD numbers 5-9 are "Turntable B-end --> Track positions 1-5"

...again, a Graphical solution such as you're proposing
(maybe with dual concentric rigs of LEDs,
Outer ring of RED LEDs indicating the currently-selected track,
Inner ring of dual-color LEDs indicate realtime position of Turntable "A" and "B" ends?)
feels like the more-User-intuitive interface...

Not confused at all, it does indeed sound like you've nutted-out a number of the electro-mechanical and User-Interface gotchas. However, as above, there may still be some "lurking" issues waiting in the darkness for you, and equally, I think there may be some issues you're _over_thinking...
(Calibration of position from both-rotation-directions,
the need for any more than 1x "Power-On Init" hall-effect sensor, etc)

You're using a Stepper motor for a reason. Any more than 1x Hall sensor is overkill...
...or, said another way, if you need More than 1x Hall sensor,
then your Stepper system has major issues and you may be Doing Steppers Wrong...

The graphical nature of the LEDs sounds like it should work fine, indeed likely better "at a glance" than a straight BCD "Track Number" interface. The Bigger issue is that you're not creating a "1--> Many system",
you're creating a "2--> Many" system, (2x ends of the turntable --> X qty landward-tracks),
and you need to either:
- do something to limit the User's thinking about only ONE nominated end of the tuurntable 
OR
- have the system "somehow" work out which end of the turntable the User cares about at any given moment,
and then send the "Correct Turntable End" to the "Correct Landward track"
(Caution! There be dragons!!!)

Happy Modelling,
Aim to Improve,
Prof Klyzlr

For what it's worth

For what it's worth, my turntable controller uses a 16-button keypad for input. It could have been a more conventional 12-button phone keypad, but the bigger one was available, so I used it. It has an extra column down the side, designated A-D. To operate the turntable, you enter the number of the destination track, then 'A' or 'B' to select the end of the table with the operator's shack, or not. 'C' puts you into the "Calibrate" mode where positions are stored, and I never found a use for 'D'. It uses a PIC16F877A processor, but an Arduino would work too.

I just got a 3D printer, and I couldn't resist printing out some optical components to see whether a digital alignment scheme could work. The idea would be that each track would be identified by a code which would be stored as a pattern of bars and slots, to be read back by an LED-phototransistor combination. What I'm trying to do is use a single sensor to read the track number, and also find an edge which gives a precise location for each stopping point. So far I've found that it's possible to print and then read a pattern with bars and spaces each 0.5mm across. It's looking encouraging so far! The picture shows my sample target, with various ratios of bars to slot sizes.

Zero first

Charlie,

I am mostly complete with an Arduino/stepper powered turntable build using a 72' Exact Rail Deck Plate Girder Bridge as a starting point and a pit built from MDF.  My first go at control used an absolute encoder on the lower shaft of the stepper motor, but I gave that idea up and went with a Hall Effect Sensor in the pit wall and a magnet on one end of the bridge. 

When the turntable is first powered up the bridge will rotate, find the initialization point, and turn to Position 1.  Like the success you had with accuracy after multiple moves, I too have found that the accuracy is near perfect over the entire time the layout is powered up.  I use a separate push-button switch for the head and tail at each ray track, and the Arduino calculates the shortest distance and turns the bridge to that position.  A toggle switch can kill the track power.  Here is a picture of my control panel design.

Will soon be modifying a Walthers 130' turntable to do the same thing based on my success.  Hope this gives you some more alternatives.