DCC Controlled (PECO) Turntable Project using a Arduino Uno

[Simond]

Well, I suggested, or at least meant to suggest, there must be power to everything, and a common ground.  Your usb connection will provide power, but not necessarily a common ground, so I would not hang too much on that.  

[melmerby]

IMHO the Macbook can't supply a ground to the Arduino, because it shouldn't have one, unless something else is also connected to it that does have a ground.

The chargers are double insulated so no ground from those.

 

The Mac can however power the Arduino through the USB socket, but should not be trying to power the shield.

The Uno has quite a complicated power supply arrangement, allowing it's internal 5v supply to be obtained from several sources: The Power Jack, The USB & directly from the 5v connections on the board.

These are protected to stop e.g. voltage from the power jack being fed back to the USB socket or the 5v and power jack from being directly connected.

 

I suggest that what could be happening is part of the Arduino circuitry has been damaged and the Mac is giving it an alternative supply via the USB.

 

However without being able to prod about on the Arduino with a meter, we are really flying blind.

 

 

[geoff]

Melmerby and Simon, flying blind is what I have been doing since the first day of the project to build this turntable mechanism but thanks to the generous help of everyone who contributed to the project back in 2017 I managed to create a reliable, accurate working turntable until the events of a few days ago.

How the power supply wire came to be disconnected is a mystery but I could have dislodged it while trying to resolve another unrelated issue. It would seem that my mistake in connecting the dislodged wire to a feedback output on the Switch Pilot rather than the common to which it was originally connected may have caused this problem since I find it difficult to believe the disconnection itself could have caused such a failure.

The "normal" power connection is from the "Output A" and "common" of the Switch Pilot to the power jack of the Arduino and then via the jumper link on the Adafruit Motor Shield. This arrangement still works in as much as the LEDs on the Arduino and the Motor Shield light up and the turntable will go through its initial rotations but there is no response from DCC commands. If I power it through the Motor Shield connection with jumper in place the same result is achieved.

If I remove the jumper and connect the USB lead to my Mac Book but leave the Mac Book closed, so effectively asleep, and leave the power supply connected to Motor Shield the turntable will operate normally to DCC commands. I have checked the continuity of the ground link between the DCC interface and the Motor Shield and it is good. I have mechanically checked (given them a tug) all the other connections between the DCC interface and the Motor Shield and they appear good.

From what you both have said I suspect that something has failed on the Arduino board in the area of the I/O connections which is where I suppose the instructions from the DCC commands are handled to cause the turntable to respond appropriately. 

I certainly don't feel confident to dismantle the set up to go hunting around the Arduino board for the problem and I imagine it could be a significant challenge to replace any defective component since I guess they are all tiny surface mounted devices installed by machines.

I suppose I could consider replacing the Arduino but then the pessimist in me feels that something will have been "updated" which will mean the sketch I have will no longer work. For the time being at least I will just take my Mac Book to the railway and connect it up when I have running sessions. The railway may not have too much longer to live in its present form as we are hoping to move house when sanity returns to the housing market.

Thank you both for your help and interest in my problem. If you should have any further thought or suggestions I will be pleased to read of them and consider whether I could implement them.

 

Regards.

 

Geoff

 

[Simond]

I feel sure that a replacement UNO (or a clone) would still work with the sketch you have, but that’s not the same as saying “it will work” :)

 

I suspect we are in the “damaged component” territory.  

 

I recommend trying a generic USB wall wart to power the Arduino, if it works, it means you could leave it in place and switch it on and off with the layout.  And likely cost about five quid.

 

Cheers

Simon

[Simond]

On 19/12/2022 at 10:55, nikkib said:

Simon, that would be a great help many thanks

Oh dear, it seems I completely forgot, I do apologise.

 

general overview of tt.  
 

 

Close-up of position sensor.  There’s a piece of white plasticard under the bridge deck at the end where a careless loco man left one of his lamps.  This is used to initialise the position, and resets the counter on every revolution.

 

 

Control panel, still work-in -progress, witness the elastic bands, where did I put the screws?   The six buttons correspond to the six positions of the t/t, again, where the loco lamp is.  There’s an Arduino Mega and a CAN module in there.  
 

The table only rotates one way.  I got fed up with trying to eliminate backlash, and it’s not operationally a disadvantage, so I took the easy way out.

 

 

this is the tt controller, Arduino nano clone, an MCP2515 CAN transceiver, and the Stepper driver.  Sorry it’s really difficult to make out, the 12v supply for the stepper is at the bottom left - red & black twisted pair, the CAN board is hiding the stepper controller, which is one of those little red numbers with the sticky-heat-sink on top.  
 

the connections to the tt are the four stepper wires, +5V and ground to the deck polarity relay and the sensor, the relay signal and the sensor output, total 8.  And they go…

 

sorry, this is a lousy photo, it’s dark under there!  You can see the stepper and it’s gearbox to the left, the red light is the deck relay and between them are the connections to the sensor.  This is a a photo transistor and an infrared led, in the tiny package in the second photo.

 

and for some reason, it’s not working.  The tt currently fails to initialise, so it just goes round and round…. I haven’t got around to plugging in the laptop to see what’s not doing what it ought.  It’s worked pretty well to date, so I’ll be surprised if a component has failed, but it’ll likely be an easy fix.

 

I’ll post up some more when I find out what’s awry.

 

atb

Simon

[geoff]

Thank you for your thoughts Simon. I have a redundant iPad charger I could try I guess. If someone could confirm that a replacement Arduino Uno would work with the sketch I have I might be tempted.

 

Regards.

 

Geoff

[melmerby]

3 hours ago, geoff said:

certainly don't feel confident to dismantle the set up to go hunting around the Arduino board for the problem and I imagine it could be a significant challenge to replace any defective component since I guess they are all tiny surface mounted devices installed by machines.

I suppose I could consider replacing the Arduino but then the pessimist in me feels that something will have been "updated" which will mean the sketch I have will no longer work. For the time being at least I will just take my Mac Book to the railway and connect it up when I have running sessions. T

I certainly wouldn't normally try and repair an Arduino, unless it is something obvious that is easy to replace.

 

Personally I would replace the Uno itself with a 'clone', at a fraction of the cost (I don't use genuine ones) and reload the sketch. You can get one for about £6 on ebay from UK sellers inc postage. If it is still faulty you know the fault is elsewhere and you have a spare Arduino.

They don't change spec very often, even then they will be compatible. (e.g. the latest ones have a small quad SMD, the earlier ones had a big DIL chip but they are electrically identical.

 

Arduinos are open source and anyone can make and sell ones identical to the official ones.

Arduino publish all the info such as circuit diagrams, components etc. online.

 

 

 

 

Edited February 5, 2023 by melmerby

[geoff]

Thank you Melmerby, that is helpful information.

 

Geoff

[geoff]

Good afternoon folk. this is by way of an update since the last entries on this thread.

I have powered my Arduino Uno from a spare iPad charger connected to the usb socket along with the motor shield being powered from the original power supply from the ESU Switch Pilot with the jumper link removed. The turntable works as reliably as ever so the original inconvenience has been resolved. There remains the nagging issue of why this problem arose. As was suggested I obtained a "clone" Arduino Uno but when I connected this to the usb from my MacBook a whole series of leds lit up (on=steady, L= double flashes and RX= single flashes.) and when I tried to upload a sketch it failed with the following error report; avrdude: ser_open( ): can't open device "/dev/cu.GeoffreyRobinsons iMac-B-2": Resource busy

I contacted the supplier who asked me to provide them with screen shots and to check the baud rate, com port etc and down loaded and installed " CH340 Serial to USB drivers" which I have done.  Now I am not conversant or comfortable with delving into the brain of my MacBook but I did, via the menus in the Arduino IDE find that the correct Arduino and com port were selected but I could not (dare not) find which baud rate was set. I have not heard from them since, nor have I pursued the matter. 

When I first ventured into this project I do not recall having to worry about downloading drivers or checking baud rates etc but just connected my genuine Arduino Uno using the supplied usb lead and a single led lit up. I then followed the instruction to upload the "Blink" test sketch which worked and then followed on through the guidance given on here to achieve the working set up.

My gut feeling is that there may be something amiss with the "clone" Arduino but the lack of follow up from the suppliers, who admit to having no experience of working with a mac of any sort, suggests to me that I will not get much further with this unit. I would welcome your observations/suggestions.

 

Regards

 

Geoff

[melmerby]

The CH340 is a later/different VCP (Virtual Com Port) driver IC than was used a few years ago, so anything connecting to it may need drivers.

Both the genuine and cloned Arduinos use them now.

I'm not so sure the baud rate would need any tinkering.

 

Some of these VCP drivers may be bundled with the PC's OS, some may not. (I know nothing about Mac hardware/OS)

 

[Ray H]

I have been tinkering with Arduinos on and off for a while now and one of the early lessons I learned was that my (Intel based) laptop/Arduino combination wasn't too struck on using a high speed serial connection so I always run mine at 9600 baud.

 

Apologies if I've got the wrong end of the stick as I've literally only started looking at this thread again earlier today and only glanced at this and the first page.

 

I recall Ray starting the thread and followed it for some time but having not done any Arduino work at that time I let it go.

 

My interest has been re-kindled because a colleague has an O gauge turntable that he thinks has a stepper motor. He drives it (with fingers crossed) using nothing more than an SPDT switch. I know that stepper motors can offer more precise operation - it'll always rotate the same way because it is very noisy in the other direction.

 

Things have generally moved on a bit since this thread started - thanks Ray - so I wonder if anyone can point me in the direction of a suitable page to start reading that will avoid me scrolling through the entire thread especially as many of the original pictures have been lost.

 

Thank you.

[geoff]

Hello Ray, another Ray (@Tender) posted the list of components to build an Arduino controlled Stepper motor driven turn table on page 1 although the list was quoted again somewhere around page 8 or 9 I believe. I must have started to venture into building mine after following through from page 1. I have enjoyed many years of faultless working until a power supply wire became disconnected. After re-connecting it to the incorrect output from the power source, albeit volt free as far as I can tell, my set up will only work if I power the Arduino from the usb socket and the Adafruit motor shield from the original source. i have purchased two replacement Arduinos but so far have not been able to upload any sketches to either of them, always getting a failure to up load "source busy etc" error report. For the first one I bought that even happened with a fresh download of the Arduino IDE software on a Windows 10 machine which had not been previously used for such a job, I had previously used my ancient MacBook Pro.

Depending on your experience in these projects you may be better off starting at page 1.

 

All the best.

 

Geoff

[Simond]

I habitually run my serial monitor at 115200 baud.  No issues to report.

[melmerby]

On 11/03/2023 at 21:31, Ray H said:

one of the early lessons I learned was that my (Intel based) laptop/Arduino combination wasn't too struck on using a high speed serial connection so I always run mine at 9600 baud.

Must be very very ancient if that's the best it can handle, my Intel based and now fairly old laptop does 115200 without a problem

[SHMD]

On 11/03/2023 at 21:31, Ray H said:

 

I have been tinkering with Arduinos on and off for a while now and one of the early lessons I learned was that my (Intel based) laptop/Arduino combination wasn't too struck on using a high speed serial connection so I always run mine at 9600 baud.

 

 

Hi Ray,

 

Although I don't use Arduinos, (I use the PIC processor family), I too "tinkered" with RS232 coms at 9600 between the PIC and the PC, and found the link to be totally unreliable with about 20% of all characters transmitted being "randomly lost" at the PC end.

 

The PIC transmitted everything beautifully, (verified by capturing the signal on a Digital Storage Scope), but messages could only reliably be received if transmitted at a slow Baud rate BUT with a big delay added to the end of each character being sent by the PIC.

 

The PC was new(ish) and of quite a high spec, so imagine my disappointment when things had to be slow, oh so slow, to reliably send and receive bytes.

 

It turned out that the problem was the operating system on the PC.

PCs run "lots" of stuff all simultaneously, have a look in Task Manager.

...but PCs DON'T run things simultaneously, they actually "time slice" the processor resources between the various tasks that the operating system demands.

So the program I wrote, (in Visual Basic Express 2010), was only "polling" the coms port, AND thus, losing characters that slipped in between "poll".

 

The solution, (after much searching, hard thinking, and even harder implementing), was to use "Threading" in VBE.

This basically, runs TWO programs - one being the Thread that handles the coms, and the other being my program that uses the communicated bytes.

 

This then worked very well.

 

 

Kev.

[Ray H]

Thanks for the suggestions and comments.

 

I have been ploughing my way through this thread - and some of the linked ones - over the weekend. Alas the image side of some of the posts hasn't recovered from the site's outage a while back but I haven't as yet found this a problem.

 

My comment about 9600 baud was the result of a problem I had a few months back where my sketch, the compiler or something else took exception to me using the 115200 rate so I successfully knocked it back to 9600 and have left it like that since.

 

I'm not sure I understand what difference the baud rate makes as I only use the serial monitor for debugging but I'll have another try at a faster rate and see what happens.

[melmerby]

1 hour ago, SHMD said:

Although I don't use Arduinos, (I use the PIC processor family), I too "tinkered" with RS232 coms at 9600 between the PIC and the PC, and found the link to be totally unreliable with about 20% of all characters transmitted being "randomly lost" at the PC end.

 

The PIC transmitted everything beautifully, (verified by capturing the signal on a Digital Storage Scope), but messages could only reliably be received if transmitted at a slow Baud rate BUT with a big delay added to the end of each character being sent by the PIC.

 

The PC was new(ish) and of quite a high spec, so imagine my disappointment when things had to be slow, oh so slow, to reliably send and receive bytes.

 

It turned out that the problem was the operating system on the PC.

PCs run "lots" of stuff all simultaneously, have a look in Task Manager.

...but PCs DON'T run things simultaneously, they actually "time slice" the processor resources between the various tasks that the operating system demands.

So the program I wrote, (in Visual Basic Express 2010), was only "polling" the coms port, AND thus, losing characters that slipped in between "poll".

If that was the case why do most PCs do it without a problem?

20% of characters dropped would make a PC unusable for the many devices which rely on the USB bus for serial communication.

 

 

 

[SHMD]

17 minutes ago, melmerby said:

If that was the case why do most PCs do it without a problem?

20% of characters dropped would make a PC unusable for the many devices which rely on the USB bus for serial communication.

 

 

 

 

I can only guess that most commercial software uses multiple "threads" in their finished software.

 

If you are "Polling" the coms port, instead of using "interrupts", then you WILL lose data whilst the PC is off servicing some other routines when more than one byte is received.

Once I added the second "thread", for coms servicing, then I didn't lose a byte AND I increased data throughput significantly.

 

 

Kev.

 

[geoff]

All this discussion about baud rates is very bewildering. When I ran into this problem " avrdude: ser_open( ): can't open device "/dev/cu.GeoffreyRobinsons iMac-B-2": Resource busy" and contacted the vendors 'Digitalcure' they offered this advice: "

New message from: digitalcure (20,574)

Hi Geoffrey,
Firstly, thank you for your purchase.
Sorry to hear of the issue you're experiencing.
As you know, we genuinely test and upload our own sketch on the day of dispatch.
This sketch makes the onboard LED double blink (a single flash every one second is the standard sketch) and output 'DigitalCure' to the Serial Monitor.

Unfortunately, my knowledge of the MacOS is severely limited.
But have you installed the CH340 Serial to USB drivers?
If not, some guidance can be found here:
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/all#mac-osx

If you have installed the CH340 drivers, please could you select the correct port in AIDE and open the Serial Monitor.
Please make sure the baud rate is set to 9600.
Could you tell me what you see, perhaps even a screenshot?
And at this point, could you try to upload your sketch again.
Thank you for your cooperation and patience.

 

Well I downloaded the driver, not something I had to do with my initial foray into this project  but I couldn't find a way to check the baud rate of my MacBook Pro, nor could I open the Serial Monitor, getting the same error report. I even went so far as trying with a fresh download of the appropriate Arduino software on my Windows 10 machine which I haven't used for this project before but I still got the same result.

This is all well out of my comfort zone so I think I will just put up with having to provide separate power to the motor shield and usb power to the Arduino on my original set up. If anyone wants the two new Arduino UNOs to try out just PM me.

 

Geoff

[Ray H]

I've spent this morning completing my read of this thread - I've always been a slow reader.

 

I've had a look at part of Simond's Arduino thread as well.

 

I have managed to copy some of the code examples - for some reason I keep getting errors when I try to download the .ino files.

 

I've since gone back to Ray's initial series of posts and managed to copy the sketch in part 7 of his series.

 

However, I'm aware that there have been several modifications over the intervening years but can't find what I believe I previously saw which was a more recent version multi-track dc only version which I think references different drivers/libraries.

 

I don't have the turntable to hand so can't organise some of the hardware but I do have an Arduino's beginner kit that includes a stepper motor. I also have a few push buttons that I can hook up to do some basic testing.

 

Can anyone point me in the direction of a more recent copy of Ray's original sketch please?

 

I'm also a little unclear how precise the Hall Effect device is. Assuming a magnet (or other metallic item) is fixed on the end of the bridge and the Hall Effect device is fixed to the well wall does the Hall Effect device always "trigger" when the bridge is at the same position/step relative to the device?

[Ray H]

Progess Update.

 

I've mounted six push buttons in a small project box - the turntable will be dc only.

 

I've used the 28BYJ stepper motor and a ULN2003 driver, both of which came in an Arduino Upgraded Learning Kit that I purchased a while ago, to prove the logic. I've mounted the motor on a piece of 2mm  thick plastic and knocked up a "pointer" made from a coffee stirrer. I've glued a 3mm by 1mm round neodymium magnet to the end of the pointer. The pointer is glued to one of the motor shaft's two flat sides.

 

I've mounted a KY-003 Hall Effect Magnetic Sensor Module vertically on the outside edge of the plastic holding the motor.

 

The sketch uses the AccelStepper library. The void setup() function sets up the six push buttons and the sense pin from the KY-003 for INPUT_PULLUP and the motor's max speed and acceleration rate. It also initialises the bridge's base position.

 

The void loop() function simply checks each push button in turn in order to detect any button that is pushed. I spent a (very) long time this morning wodering why one of the button's code appeared to work in the opposite way to the others thereby preventing it from being detected. It wasn't a dodgy push button or naff coding - I'd picked the button at random from several that I had, only to finally realise/find that the one I'd chosen was a Push to Break when all the others were Push to Make. Doh!

 

There's a small array that holds the "move to" position (number) for each button. The pressing of one of the five buttons moves the bridge to the stored position relative to the bridge's home position (as decided by where the sensor stopped it earlier). The sixth button currently turns the bridge through 180 degrees from its most recent position and that's all there is to it.

 

The code has been tested and tidied up and will hopefully form the basis of the code used for the O gauge turntable. I appreciate that there may need to be some alterations to the code for the larger motor and its controller and that I may need to investigate/use a larger magnet. I also realise that the 180 degree turning may result with the bridge not aligning properly after the turn but I won't know this until everything's set up on the layout.

 

The code is attached below for anyone that's interested but remember it will most likely need revising to be used with larger motors although I do wonder if the current motor would be sufficient for N gauge.

 

I'll aim to provide an update once the O gauge turntable is up and running.

 

Stepper_Motor-V2c.ino

 

 

[Ray H]

The coding for the change of motor/driver involved alterations to just a few lines of code. I haven't installed the Hall Effect sensor so far. Instead I'm just using the motor's initial position setting when the sketch starts, as the base position, for testing.

 

The sketch causes the motor to move in response to the operation of any one of 6 push buttons. Buttons 1 to 5 will cause the motor to always move the turntable's bridge to a nominated position. The sixth button will move the bridge through 180 degrees based on its previously nominated position (set by buttons 1 to 5).

 

What I thought initially was a problem with repeated 180 degree turns has become a problem with regaining a nominated position when intermediate moves involve consecutive moves in opposite directions.

 

I'm using the AccelStepper library.

 

Is there a way using this library to always make the bridge move in the same direction?

 

Update

 

A simple Loop() code of:

        myStepper.moveTo(2400);
  // Run to target position with set speed and acceleration/deceleration:
       myStepper.runToPosition();

       delay(500);

  // Move back to zero:
      myStepper.moveTo(0);
      myStepper.runToPosition();

      delay(500);

 

causes the same problem

 

Edited March 25, 2023 by Ray H
Edited to add the update.

[Simond]

Ray

 

Simply comment out the lines that set the direction to the one you don’t want.  There’s probably a Boolean variable “DIR”? that can will go one way if it’s 1 or t’other if it’s 0,  
 

If DIR Is always 1 or always 0, It’ll always go the same way.

[Ray H]

2 hours ago, Simond said:

Ray

 

Simply comment out the lines that set the direction to the one you don’t want.  There’s probably a Boolean variable “DIR”? that can will go one way if it’s 1 or t’other if it’s 0,  
 

If DIR Is always 1 or always 0, It’ll always go the same way.

 

Thanks for the suggestion Simon.

 

I'd thought of that but as you can see from the addendum to my previous post, there's no specific set direction code. The direction pin is allocated (and set for output) but that's the only reference to the direction that there is. I suppose that I could try forcing the pin High or Low prior to each .runToPosition statement.

 

I might try stepping one step at a time within a for loop for example but I suspect that might make each overall movement slow.

 

Keeping the direction constant may solve the problem but I'd like to avoid it if I can because moving the bridge (say) 340 degrees when the two roads are only 20 degrees apart seems wrong.

 

Luckily the layout generally only uses diesels so turning them isn't too much of a problem and as its a terminus the appearance of the odd steam loco will be wanting to be turned.

 

I did briefly look to see if there was a different library to use with the A4988 controller but didn't find one.

 

 

[Simond]

My t/t only goes one way, because that was a satisfactory way of solving the issue of backlash.  
 

I have three possible outlets, and thus six positions for the table.  A loco arrives on the coal road, tender first (because it has reversed from the terminus), drops its ash, and takes coal, turns, and leaves (tender first) by the adjacent road to go on shed (tender out) or parks in the “back siding”.   If the latter, it would be tender first, so chimney out.  
 

As the adjacent road is only a few degrees  from the coal road, the t/t has to do about 170 degrees to turn the loco, so going only one way is entirely reasonable.  The empty table then does the 10 degrees to reset for the next loco.

 

if you go through this process in your head for your layout, you might find turning is logically one way only too.