Arduino Applications and Programs

[melmerby 14,716]

On 14/01/2021 at 12:21, tender said:

Yeh, its a plug-in replacement for the A4988 apart from the direction which is reversed.

 

Decided to convert my traverser to stepper motor drive.

I ordered some TMC2208's which arrived this morning.

I have purchased the V3.0 which seems to have some different options to V1.0 regarding UARTs.

Any ideas if it makes a difference?

 

I'm just knocking up a breadboard to test the workings using a Nano & a Shinano stepper out of an Epson Scanner

I also ordered some more Pulleys and a belt (from CNC Planet) in case what I have isn't suitable.

[tender 3,934]

15 hours ago, melmerby said:

 

Decided to convert my traverser to stepper motor drive.

I ordered some TMC2208's which arrived this morning.

I have purchased the V3.0 which seems to have some different options to V1.0 regarding UARTs.

Any ideas if it makes a difference?

 

I'm just knocking up a breadboard to test the workings using a Nano & a Shinano stepper out of an Epson Scanner

I also ordered some more Pulleys and a belt (from CNC Planet) in case what I have isn't suitable.

 

 

Yeh, you need to make sure you set it to Legacy Mode if using as a drop in replacement for the A4899 (same code).

On the underside there should be a row of 3 solder pads. Make sure there are no links bridging these.

V3.0 boards may have a link.

This might be useful.

 

[melmerby 14,716]

1 hour ago, tender said:

 

 

Yeh, you need to make sure you set it to Legacy Mode if using as a drop in replacement for the A4899 (same code).

On the underside there should be a row of 3 solder pads. Make sure there are no links bridging these.

V3.0 boards may have a link.

 

 

I'm starting from scratch to replace the noisy DC motor & gears on my traverser, so this type of stepper driver is all new to me.

I have used a L298 with an Arduino before but that's very basic driver.

The BigTreeTech  TMC2208 V3.0 board has three extended pins and a wire link supplied, so I assume that is a replacement for the jumpers.

 

EDIT

Or is it already set to UART mode, hence the extended pins & jumper lead?

One of the solder pads is already linked by what looks like a SMD resistor. (Probably a R0 to use as a link)

 

 

Edited January 17 by melmerby

[melmerby 14,716]

OK

Got the basic settings using UART working with this code:

 

TMC2208_SoftwareSerial_Nano_Pins.ino

 

Wow. I didn't know a stepper could be so quiet, it's making much less noise than a brushed motor.

Just need to work out the change of direction etc.

 

 

[tender 3,934]

19 hours ago, melmerby said:

OK

Got the basic settings using UART working with this code:

 

TMC2208_SoftwareSerial_Nano_Pins.ino 1.06 kB · 0 downloads

 

Wow. I didn't know a stepper could be so quiet, it's making much less noise than a brushed motor.

Just need to work out the change of direction etc.

 

 

 

Looks like you just need to define another Nano pin for the direction.

[melmerby 14,716]

23 minutes ago, tender said:

 

Looks like you just need to define another Nano pin for the direction.

Probably also need a couple of other inputs for the end stops, as I found that you can get "slippage" if relying on absolute positioning when I was experimenting with the L298 driver

Currently I have a microswitch each end of the travel which gives very accurate stopping using the present DC motor drive.

[tender 3,934]

5 hours ago, melmerby said:

Currently I have a microswitch each end of the travel which gives very accurate stopping using the present DC motor drive.

 

I just have one microswitch at the end of travel in one direction. I just run slowly up to this during startup and set position to zero. All other movements are then relative to this.

I figure if 3d printers can run continuously for hours without loosing sync then a traverser should be a doodle.

I've run the traverser back and forth all day after without loosing sync.

[melmerby 14,716]

4 hours ago, tender said:

 

I just have one microswitch at the end of travel in one direction. I just run slowly up to this during startup and set position to zero. All other movements are then relative to this.

I figure if 3d printers can run continuously for hours without loosing sync then a traverser should be a doodle.

I've run the traverser back and forth all day after without loosing sync.

My previous printer, from whence came a couple of the steppers, regularly re-set it's position and used an optical strip parallel to the carriage to know how many steps it had made.

Similarly the paper feed had an etched disc with an optical sensor to know how far it had fed.

Epson obviously weren't taking chances.

I still have the strip, wheel and sensors

[melmerby 14,716]

14 hours ago, tender said:

 

I just have one microswitch at the end of travel in one direction. I just run slowly up to this during startup and set position to zero.

I don't think I can use that method as the traverser needs to be able to start from either end when first used, it might even have a train straddling it, so shouldn't move unless required to and safe to do, so no startup indexing.

[Simond 7,246]

I got so fed up with my turntable losing position that it indexes & zeroes its position counter when I turn it on, and on every revolution thereafter.  I'm going to try these other stepper drivers, in the hope that they don't make the motor whistle...

 

Our CNC machine tools at work all reset themselves as part of the start up - you have to push a button to initiate it, they don't do it on their own, in case they would destroy a workpiece or tools, possibly after an e-Stop (it can't "know" why it was off).

 

I designed & programmed an arduino traverser drive for Paul Ashton, and I put a switch at each end - it did not have intermediate positions, but would initialise itself by going to both ends and triggering the switches.  Again, it would trip the switches at each end on every cycle, the step count was to allow a smooth acceleration and deceleration as this was a scenic traverser.  Could easily have intermediate stops and I suspect would be repeatably accurate.

 

Car windows of the anti-trap variety were part of my working life some 20 years ago.  They tended to use the rise in motor current to signify that the motor had stalled and therefore the glass was either full-up or full-down.  They generally counted the motor revs to work out intermediate positions, but the requirement was for force control, not positional accuracy, though the boundaries for the force control were quite tightly controlled.

 

I suggest you don't park a train across the gap when turning the layout off, or if that is a risk that you can't exclude, (it can't know why it was off) then have a start-up routine that is initiated by a finger-pressing-button, possibly the normal control, so you have to look and decide that it is safe to initialise the traverser.  Or fit a light beam / photodiode to ensure that it is safe to initiate movement.  Or both

 

atb

Simon

 

 

[melmerby 14,716]

12 minutes ago, Simond said:

 

I suggest you don't park a train across the gap when turning the layout off, or if that is a risk that you can't exclude, (it can't know why it was off) then have a start-up routine that is initiated by a finger-pressing-button, possibly the normal control, so you have to look and decide that it is safe to initialise the traverser.  Or fit a light beam / photodiode to ensure that it is safe to initiate movement.  Or both

 

atb

Simon

 

 

It is presently controlled by a DCC decoder, and operates as part of a computer controlled set up so it needs to know exactly where it is at start up without moving. All movement is controlled by the program.

That's why I don't really want any step counting routines.

All I require is the motor, under DCC control, to move the traverser from one end stop to the other.

[Simond 7,246]

Ah, an “automated Crispin”.

 

if it needs to know where it is without moving at start up, I suspect you need to park it on a switch (or something similar) that indicates that the system is in a known state when switched on.
 

as with my CNC machine tools, your computer cannot know why it had been turned off, and if it was an emergency stop, or power cut, the deck possibly won’t be where the computer thinks it should be, even assuming the program has a position variable containing valid data.  Once initialised, the CNC has feedback that confirms the axis positions at all times, but like your digital caliper, they need to know where home is.

If there’s a train across the end of your deck, it clearly can’t move without the risk of damage, so some indication of that is also needed.  And if the deck isn’t parked where it should be (I’m not sure how many positions you have, sorry if I missed it) your computer needs to sense that too and go through some kind of recovery routine (which may include requiring a human input) to get into a proper initialised state.  

hope these thoughts are helpful

atb

Simon

 

[melmerby 14,716]

When it's operating with it's present set up it is up against one or other of the end stop microswitches and there is a also DCC command, as with a point decoder, of normal or thrown (which the decoder also stores when power is off) so it can never be half way unless the power goes down in the middle of operation.

 

If it is "normal" position, that end's microswitch is operated and the decoder is in the normal position.

If the decoder is now operated (to the thrown position) the deck will be driven across until it reaches and operates the thrown end's microswitch where it will stop.

This is exactly the same as the original point machine which donated the decoder board, motor & some gears, the microswitches I installed are larger but wired the same. As far as the decoder (and computer) knows it is still a Traintronics TT300 point machine.

 

I really just want to replicate that operation but with a stepper as it is much quieter and more powerful than the RF300 motor used (which is underpowerd for the traverser.

Edited January 20 by melmerby
rephrased

[Simond 7,246]

Hi Keith,

 

That makes sense.  You can have, indeed, I think you need to have, microswitches as you have now, they can talk to the Arduino that I assume you’re going to use to control the stepper.  I’ll have to get on the laptop, but I’ll post the sketch I wrote for Paul.  Hopefully you can use that, though I’m not sure how you’ll interface the Arduino and your decoder.  It may be convenient to have two microswitches at each end, the Arduino could react to the motor signal from the decoder, perhaps.

 

The power going off mid travel would need some kind of reset, but that’s probably the least of your worries!

 

keep well

Simon

[melmerby 14,716]

11 minutes ago, Simond said:

Hi Keith,

 

That makes sense.  You can have, indeed, I think you need to have, microswitches as you have now, they can talk to the Arduino that I assume you’re going to use to control the stepper.  I’ll have to get on the laptop, but I’ll post the sketch I wrote for Paul.  Hopefully you can use that, though I’m not sure how you’ll interface the Arduino and your decoder.  It may be convenient to have two microswitches at each end, the Arduino could react to the motor signal from the decoder, perhaps.

 

The power going off mid travel would need some kind of reset, but that’s probably the least of your worries!

 

keep well

Simon

Hi Simon

I originally was going to use the Arduino as both the driver & decoder as I did for some motor driven points, rather like I intended for this project but unfortunately It  doesn't remember the state, so each time it powers up it returns to the normal position (if it isn't already there) - I could do with learning about saving to the internal memory so it could store the state and power up correctly.

 

However I might leave the present DCC decoder in place and just take the state from that.

[Donw 14,215]

You can save Data to EEPROM on most Arduinos  I think the Due has flash memory. The problem is you do not really want to keep writing to EEPROM after each move. The really clever do a quick write on detection of the voltage dropping before it goes into brownout. Dont ask me how to set all that up. 

Don

[47137 3,642]

16 hours ago, melmerby said:

Hi Simon

I originally was going to use the Arduino as both the driver & decoder as I did for some motor driven points, rather like I intended for this project but unfortunately It  doesn't remember the state, so each time it powers up it returns to the normal position (if it isn't already there) - I could do with learning about saving to the internal memory so it could store the state and power up correctly.

 

However I might leave the present DCC decoder in place and just take the state from that.

Here are a couple of ideas:

 

(1) Supposing your traverser only stops at a road (and not at a gap between them), add a reed switch for each road, operated by a magnet attached to the mating surface. When you power-up the system, have the Arduino examine these switches to work out where the traverser is.

 

(2) Use a wafer switch with three positions as the 'power' switch for the system. The positions being "run", "park" and "off". So when you switch off, you let the traverser drive itself to a known parking position, and the system will have a known position next time you power up.

 

- Richard.

[melmerby 14,716]

Hi Richard

It's DCC controlled only, no manual operation. (except via a DCC handset)

It only has two positions and when at either of them, the relevant μswitch is operated so it knows exactly where it is.

 

It is based on this prototype:

https://www.warwickshirerailways.com/gwr/gwrms1223.htm

 

Birmingham Moor Street had two of them as engine releases due to the limited space.

Snow Hill used a different solution:

https://www.warwickshirerailways.com/gwr/gwrbsh1679.htm

[Donw 14,215]

If you have a micros switch at each end which tells the motor is has got there can you not take a signal from that to the arduino/whatever that way the arduino will know if it at either end if not either it must be in between ( e.g power failure)  so end A signal it is at start , Bsignal it is in the other position, neither signal it moves it back to A to be certain of its position.

Don 

[melmerby 14,716]

1 hour ago, Donw said:

If you have a micros switch at each end which tells the motor is has got there can you not take a signal from that to the arduino/whatever that way the arduino will know if it at either end if not either it must be in between ( e.g power failure)  so end A signal it is at start , Bsignal it is in the other position, neither signal it moves it back to A to be certain of its position.

Don 

I was going to do it on the basis of signal from decoder = drive one way or other (DIR), no signal on respective μswitch = enable drive (EN).

That way if it stops midway due to power failure when it powers up again it will continue driving until it gets to the end (the decoder doesn't lose it's status)

If it's already at the end nothing will happen until the decoder reverses.

[Simond 7,246]

I smiled.  The sketch & design I did for Paul is for a 7mm MOOR ST. (My mistake!)

 

I’ll put the sketch up tomorrow

 

atb

Simon

Edited January 21 by Simond

[47137 3,642]

7 hours ago, melmerby said:

I was going to do it on the basis of signal from decoder = drive one way or other (DIR), no signal on respective μswitch = enable drive (EN).

That way if it stops midway due to power failure when it powers up again it will continue driving until it gets to the end (the decoder doesn't lose it's status)

If it's already at the end nothing will happen until the decoder reverses.

 

When power is restored your traverser will be in one of three states:

- at one end or the other, with an engine across the gap

- at one end or the other, but free to move

- somewhere in between

 

You need a visual inspection to tell whether there is an engine across the gap, and to my mind this asks for a sort of "permission to start" push button to let the DCC system take control. It is good the decoder doesn't lose its status, but I'm not sure whether you can rely on this where there are delicate models involved.

 

If you are going to have such a button, this leaves you to decide whether the traverser controller should also need a push on it when it powers up between end stops.

 

I suppose, the hardest decision is whether your traverser controller should be committed to the control system for the layout. If the DCC system were to provide just a pair of clean on/off contacts to tell the traverser to move one way or the other, then you can build the traverser controller in isolation, away from the DCC controller, give it the logic it needs to restart in a predictable if possibly long-winded way; and test its operation with a toggle switch.

 

- Richard.

[Simond 7,246]

“Engine across gap” is eminently detectable by a light beam & phototransistor aligned with the gap, or two such arrangements set a few mm either side of the gap.  Indeed, there are arguments to suggest that doing this anyway, and checking before every move, would be a good thing.

 

ideally the control system / decoder setting a pin high for one position, and low for the other, seems like a simple control logic.  The Arduino can set a pin high or low depending on its position, and another depending on whether it is moving or correctly “parked in position” if full interlocking is required.

 

Fully agree that setting it up on the bench will be far easier and much more comfortable!

[melmerby 14,716]

I think some of you are over thinking this.

It is part of a computer controlled layout, it normally moves under command of the program, when certain conditions are met, although it can be controlled from the DCC hand set.

There will never be an engine "across the gap" when it moves. It only moves when an engine is either fully on or fully off.

If the power goes down it doesn't matter as whatever was happening before will continue as before.

If a complete train is standing part on it, it won't move.

 

When the Arduino powers up it will have a logic signal from the decoder which will determine direction by controlling the TMC2208 DIR pin.

It will have logic signal from each of the end stop switches which will control the TMC2208 EN pin

 

 

 

[Donw 14,215]

6 hours ago, melmerby said:

I think some of you are over thinking this.

It is part of a computer controlled layout, it normally moves under command of the program, when certain conditions are met, although it can be controlled from the DCC hand set.

There will never be an engine "across the gap" when it moves. It only moves when an engine is either fully on or fully off.

If the power goes down it doesn't matter as whatever was happening before will continue as before.

If a complete train is standing part on it, it won't move.

 

When the Arduino powers up it will have a logic signal from the decoder which will determine direction by controlling the TMC2208 DIR pin.

It will have logic signal from each of the end stop switches which will control the TMC2208 EN pin

 

 

 

 

If the power goes off when it is halfway surely neither microswitch at either end will be operated. So you expect the decoder to still be sending a logic signal telling it which way to move. If has been a break in the mains supply the DCC system will go off too. I assume that the decoder will restart. I would expect the decoder to revert to a default position not remember which way it was set. This is fine with a turnout you just re-operate it. But if it has a loco on it when the power out occurs the loco should be in the centre track and would not be an issue i will either go to one or the other side  according to the default. If it is the wrong side you just re-operate it.