Arduino Applications and Programs

[Ray H]

3 hours ago, eldavo said:

If you omit the "break" statement the execution drops through into the next case by default.

 

Cheers

Dave

 

Dave

 

I wasn't aware of that facility. That could save some lines of code. Thanks for pointing that out.

 

My conundrum is whilst lever X may always operate servo A, lever Y may operate servos B and/or C and, in one instance a lever can operate 1 of a group of 4 servos depending on the setting of several points.

 

I was hoping to have a direct correlation between each lever and servo but that made the frame too large (added to which some levers switch two servos for crossovers).

 

The servos are currently  "arranged" numerically - with possible a, b, c & d suffixes - such that lever 3 (for example) operates servos 3a & 3b (which are a crossover).

 

I've kept thinking there must be a different way and think that I may have just thought of a better one by re-arranging the servo connections.

 

Thanks again, I'll let you know how I get on.

 

Edited to add:-

 

I wrote the above before you posted Don but appear to have forgotten to submit/send/post it.

 

I'm now looking at a different option whereby I group those levers that only operate one servo together, levers that operate two (not route set dependent) servos in an upper group with those levers that are route dependent in the middle. I can then do three conditional checks (ifs) based on these groups rather than a multitude of case statements.

[melmerby]

21 hours ago, melmerby said:

If one pin is high and one pin is low is it OK that one pin is sourcing current and the other is sinking the same current?

.

It works OK

The Arduino High is about 4.4v and Low is just under 0.2v when passing about 10mA source to sink. (2.28v across the 220R series resistor)

The LED was not quite as bright as I would like, so I upped it to 15mA which is fine and well within pin capacity and overall current draw limits.

[andysollis1]

On 20/01/2021 at 13:14, Simond said:

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

 

 

Hmm

Ive had my turntable set up running and now having a few issues that if it should snag due to warm weather/expansion it wont align roads. The hall sensor though is brilliant at setting zero on power up each time (providing the deck doesn't jam.

 

I'm wondering now, If I was to swap for a full board rather that the small board I have if I could instead add 5 more hall detectors and (as the 6 lines are all opposite) set it up so it just searches for the relevant sensor when the selection button for that entry/exit road is pushed? ie just ignore if it trips the other 5 in passing if the magnet should trigger them?

 

Whats your thoughts Gents ?

 

Andy

 

[Simond]

Andy,

 

this sounds plausible - you could do as I did for Paul, and count the steps between, and only use the count for the acceleration and deceleration of the table, aim to decelerate to a crawl one or two steps before it hits the sensor position.  It will then only need to stop from a very slow speed, meaning it won’t override or skip a step.

 

This should end up with a very robust setup which provides smooth operation, and repeatable stopping, pretty much the aim of the game.

 

question for further debate, is accel/decel necessary on a turntable?  
 

I spoke to “Castle”, who is one of the loco crew at Didcot, and asked how long it takes to turn a loco - I’d have to go back and look, but I recall that I copied the actual turning time, but did not include accel/decel in my sketch, so I was not concerned about overloading the motor - at least I didn’t have an issue with it, when I was setting mine up.  
 

It’s not very quick, anyway

 

atb

Simon

[gz3xzf]

Gents

Found this on YouTube of the Mogul being turned at Didcot (pushing it round rather than using the crank handles), hope this helps on how long to turn.

 

[Ray H]

Our club has four control areas on its O gauge layout.

 

One area is a small subset of a second area and the remaining two areas are largely independent of the others.

 

We're planning to use servos to operate the points and have LEDs on the associated control panels with the selection of a route by push button causing a number of LEDs to be illuminated and a number of other LEDs not being illuminated (to avoid confusion over which route has actually been selected).

 

There will be four "tables" for each control area: one table indicating which points will be normalised and another indicating which points will be reversed to set the required route. The other two "tables" will indicate which (control panel) LEDs will be illuminated and which LEDs must not be illuminated.

 

I plan to have a direct correlation between a push button's Arduino input pin and the requisite row in each of the four tables. e.g. If a push button is connected to input pin 20 and the relevant "row" in the tables is row 4, I can set the table index as pin number minus 16 to point at the required table "row" to access the data. 

 

Each of the "tables" will  have several rows/records containing several fields as in the following example:

const int rows = 2;

const int columns = 3;

int array1[ rows ][ columns ] = { { 1, 2, 3 }, { 4, 5, 6 } };

int array2[ rows ][ columns ] = { 1, 2, 3, 4, 5 };

int array3[ rows ][ columns ] = { { 1, 2 }, { 4 } };

 

Is there a compact way to set up the tables or will I have to repeat each rows' fields one line at a time for each table?

 

Two of the tables will (ideally) be alphabetic, the other two numeric.

 

Some fields will be empty as will some of the rows if I am to maintain the correlation to speed up the table searching process. Presumably I can omit an empty row in the definition stage. Is it acceptable to separate empty fields using two commas without spaces in between?

 

I can reduce the number of tables by increasing the number of fields in each row and using a separator in a field between the different areas of the table. For example, I could have the first two fields of a record to indicate which LEDs are to, be lit then a separator and then fields with the LEDs to be unlit. The sketch code would re-act to the separator and know that it has to process what follows in a different way.  I reckon this could reduce the data storage area by at least 50%.

 

Finally - for now at least - there will be more than 10 push buttons, LEDs and servos. Could I convert a field's content to be the ASCII code for the number it represents? For example, if I need to store 65 as the servo number in a field can I substitute the letter A instead as this would reduce the field sizes.

 

Thanks in advance.

 

[Donw]

Hi Ray 

I do not quite follow your logic about the tables it seems a bit complicated for me.  First off yes you can use the ascii characters and their number value in a mix and match when using arrays of char.  I have declared the assignment of characters to a keypad in an array i then have a switch/case statement which does varoius things according to which key is returned. However when needingto know if the key pressed was one of the numeric assigned ones I check the value of key was between 48 and 57.

If you think about it a char is just an 8 bit binary number in the computers memory  so whether it is treated as a ascii character  or a numeri value just depends on what you are doing with it in the code. 

 

To return to your logic I would assume only one route in a area can be set at once or do you have a means of checking conflicts.

 

Don

[Ray H]

1 hour ago, Donw said:

Hi Ray 

I do not quite follow your logic about the tables it seems a bit complicated for me.  First off yes you can use the ascii characters and their number value in a mix and match when using arrays of char.  I have declared the assignment of characters to a keypad in an array i then have a switch/case statement which does varoius things according to which key is returned. However when needingto know if the key pressed was one of the numeric assigned ones I check the value of key was between 48 and 57.

If you think about it a char is just an 8 bit binary number in the computers memory  so whether it is treated as a ascii character  or a numeri value just depends on what you are doing with it in the code. 

 

To return to your logic I would assume only one route in a area can be set at once or do you have a means of checking conflicts.

 

Don

 

Many thanks for your response Don. One of the Arduinos will have some code to prevent conflicting movements being set but none of the others require that much detail.

 

There will be around 30 push buttons connected to a couple of the Megas. When anyone of them is pressed it will be necessary to set some points normal and some reversed and for some of the LEDs to be illuminated and others not. The Control Panels will be of the mimic style with push buttons and LEDs affixed to the relevant part of the panel's track diagram.

 

Imagine a crossover in the middle of an otherwise pointless length of double track. There will be a servo attached to each point and there will be three push buttons and three LEDs on the diagram. There will be a LED and a push button on each of the two main running lines and a third of each on the crossover track.

 

Pressing the mid crossover push button will cause the two servos to operate, the LED on the crossover track to illuminate and the other two LEDs to be "turned off". Pressing either of the other two push buttons will cause the reverse to happen. That's fairly straight forward. But I need to hold data for each push button's operation. I need to know which point(s) need to be reversed or normalised and likewise for the LEDs turning on and off so I see the need for four data fields in each (push button's) data record.

 

Some of the layout areas are more complicated than this with up to 8 LEDs needing to be turned on or off as the result of a single push button's operation. There won't be as many servos needing to be operated but even there for one bush button there might be five - the plan is to ensure any subsequent trailing points are also set correctly.

 

In order to cater for the above I could use four distinct data tables - servo/points normal, servo/points reverse, LEDs On & LEDs off. Therefore I need to have each record/row capable of having sufficient fields to accommodate the maximum required on any one record. I'd estimate that around 80% of the fields will be "empty".

 

Another idea that I had was to combine all four tables into a single table. Merging all that data and still allowing for the maximum number of fields for each of the four distinct data sets in each record won't save any data storage space.

 

There are a known number of data field item entries required for each record - e.g. an individual (push button) record may need to operate (say) 2 servos normal, 1 reverse, 3 LEDs on and 2 LEDs off, a total of eight fields. Throw in a separator between each group pushes that number up to 11. Other records may require more or less data fields (but I can work out the maximum for any one record and only allow for that. Subject to checking, this arrangement will reduce the data storage required by 15% (or 45% if I could avoid an allocation for section separators).

 

Does that clarify what I'm trying to do? Can you suggest any other way of reducing the data storage area required?

[Simond]

Ray

 

it seems to me that within each of your four districts, you have a limited number of routes, and each route requires some pins to be high, and all the others low (or the opposite)

 

Simply setting the necessary pins high when setting each route would be feasible, provided you have a "reset all to low" after the move.  I guess the reset could be a preliminary function of the next move, as in press the route button, and it clears any previous route, and then sets the new one, or it could be a separate button, or it could be triggered by the arrival of the train in the destination section.

 

On this basis, would you not simply need a table of the pins that need to be set high associated with each route? 

 

I would use a 2D array, where the row number was selected by the input pin, and the the columns are the possible output pins, the elements in the array would be boolean 0 or 1 according to needs.

 

hth

Simon

 

[Ray H]

Simon

 

Thank you for the suggestion. Unfortunately a blanket "Unset/Reset" wouldn't work as, for example, there may be a train travelling along one route that is controlled from the same control panel that we don't wish to stop whilst there is a train on an adjacent route that we need to change the route of without affecting any other movement.

 

I'm just trying to find a way to reduce the data storage required which I would have thought should also reduce the amount of processing time taken and how quickly the system can be available to respond to the next push button activity.

 

One of the MEGAs would have to hold a 27 records (in four tables with a combined total of 20 fields). 

[Donw]

Ray

 

first thing the LEDs are defined by the turnouts I assume . Secondly you shouldn't need to know whether something is set or not  because operating a turnout that is already on is not an issue nor is turning on or off and led already in the correct state. Besides the LEDs on the panel should show whether a turnout is operated or not. 

I would expect each turout to have two or three LEDS associated any other LEDs would be associated with other turnouts.

 

So you could have simply an array

 

char PBlinks [ number of PBs][ max number of links ];

 

the max number of links would be for the biggest number of any PB +1

 

so for PB4 say the entry for the links might be   '#'08!:;NUL'   where # is turnout 35 0 is LED 47  etc. the NUL shows that is the end

 

Don

 

 

 

[Ray H]

 

Apologies for the poor quality of the attached but I'm hoping that I can use it to demonstrate what I'm attempting to do.

 

At the bottom right of the above image are two carriage sidings. The lower one (like most of the others) has a push button (shown in blue) and an LED (shown in green). The rectangle to their left is the servo operating the point. There could be trains shunting in the Goods Yard (under the control of a separate operator) and there may also be a train approaching platform 1 of the station when we want to move a train out of the carriage siding. As a result we can't do a blanket reset as I believe was suggested earlier.

 

One of our members is dyslexic so we have to take that into account.

 

The only way a train can leave the carriage siding is to pass over two further points, the prior status of which cannot be guaranteed so all three servos will potentially need operating.  There also three LEDs associated with the move. The need to illuminate the one in the (bottom) siding is a given. However, once again, the status of the other two LEDs is not guaranteed so one or both may need setting. Issuing a command to illuminate an already illuminated LED costs nothing whereas retaining its status so that it can be checked and a decision then made as to whether it needs illuminating or not has a processing overhead which is why I don't plan to store the status.

 

We don't need the LEDs in the other carriage siding or the platform three track illuminating so they will need to be turned off if they are on (which we may not know).

 

That's one move sorted and in time executed.

 

Imagine then if you will that the next movement in this small area is a move from the other carriage siding. The relevant push button will be depressed and the relevant servo will be operated and the siding's LED will be turned on. However, I don't need the LED in the lower carriage siding illuminated - leaving it be (illuminated) would be confusing - so that needs to be turned off .

 

Hopefully this shows why (for any push button operation) I need to store data that tells me which LEDs need to be on and which need to be off (to avoid confusion). Likewise which points need to be in the reverse and which need to be normal.

 

I know we could add more push buttons to reduce the data storage but why make the system less user friendly just to save some data storage?

[Simond]

Ok, returning to my suggestion, don’t reset all the points and lights, merely set the route, and when the move is complete, press the same button again to “unset” it, ie return all points to normal and turn off all leds.

 

but in the case you describe, you will have multiple simultaneous moves, that’s great, providing you don’t cause moves to conflict.

 

if you arrange that “unsetting” can only be done by pressing the same button again, it could provide a measure of route locking; an alternative route would not be able to conflict because the points would not be permitted to change.

 

I still feel that you do not need to have a working memory of each led or point setting, you merely need to reliably set pins high or low depending on the route button you pressed, and then return them to normal when the move is complete.

 

atb

Simon

[Ray H]

Simon

 

I'd agree with you if it was a private layout. I'm not so sure with a club layout and what happens if someone forgets the second press of the button? Surely that leaves a potential for unwanted derailments/contact(s) and the like.

[Simond]

well, if the route were "locked" until the second press of the same button, nobody could create a conflicting route.

 

You'd need a "route locked" flag raised when the route was set which could usefully illuminate the appropriate button, making it unlikely to be forgotten.

 

the flag would prevent other routes moving the points or unsetting signals, or route leds.

 

 

[Ray H]

Simon

 

Thanks once again for the suggestion which, as it's club night, I can discuss with those present.

[Ray H]

Here's a belated update on the above.

 

The new control panels are in situ and their LEDs are illuminating to show the route selected. We've basically used a slimmed down version of route control where, for example, there is a fan of several tracks either side of a single line & there are push buttons that set the route from the single line to the desired siding and said push button only illuminates the LEDs applicable to that route so one push button may cause the operation of several LEDs and servos.

 

The servos on the two smaller panels are also in and working although their associated frog polarity switching relays have yet to be installed - they're replacing some currently unsuccessful frog juicers.

 

There are three Arduinos remote from control panels. These are linked to the nearest control panel via a CAN bus and are used to keep wiring runs to a minimum or where an I2C link to a servo/relay would need to be several meters away.

 

We've largely ignored "interlocking" as experience on our OO exhibition layout has taught us that it adds nothing other than confusion for the operators!

 

Apologies for the delayed update.

[Andy Keane]

Just had this thread pointed out to me which is great.

I have just finished building an Arduino that is linked to a set of DCC concept signal/point levers and runs a signalbox interlocking table and drives to the NCE data bus if anyone is interested.

Andy

[Simond]

Yes, I’m interested!