Video Archive         Recent Topics      
YMR logo

You are here:  Your Model Railway Club > Getting You Started. > The Lineside. > Processor Control of Lineside Items To bottom of page
                 

 Moderated by: Spurno
Start New Topic Reply Printer Friendly

Processor Control of Lineside Items - The Lineside. - Getting You Started. - Your Model Railway Club
AuthorPost
 Posted: Mon Jul 27th, 2020 03:20 pm
PMQuoteReply
link to this 1st post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

This will become an occasional series of items that will concentrate more on the method by which I have - and still intend to automate certain aspects of my John Street layout (http://yourmodelrailway.net/view_topic.php?id=14501&forum_id=21&page=1) so that in a running session I can concentrate on actually driving the trains around the layout and not have to worry about which signal needs to be changed and whether it can even be legitimately changed to a proceed aspect and to automatically open/close the Level Crossing gates. I like to see a lot of animation on the layout other than the trains moving around.
 
To supplement the John Street layout topic, this will be somewhat more technical in nature and it'll leave the main topic as to how the layout itself is being built up and run.
 
Up to press I've automated a Home signal and Theatre Display on the approach to the Terminus and installed a number of Uncoupling Ramps for the tension lock type of couplings within the Terminus, and I'm almost there with a Level Crossing controller as well as progressing the signalling project for the entire layout; the Terminus area has been more-or-less completed (but not yet installed) with the remainder of the layout not far behind.
 
There are numerous methodologies of controlling signals, etc. from shop-bought items from the likes of TrainTech - to mention just one (apologies to other companies for not mentioning you [my mind has gone totally blank on it at the moment!]) but this topic is to concentrate on MY methodology of DIY. Personally, I get far more satisfaction from building something myself rather than going out and buying a ready built unit (which may/may not do what you might want to achieve on your layout).
 
Even on the DIY front there are various ways of automating signalling. My first layout - a rather simplistic layout - simply used a number of 1N4148 diodes and biasing them either "on" or "off" via switches and point voltages to achieve a given signal aspect. It was a bit clunky, but on that rather simplistic layout, it worked fine.
 
From here on in, I'd like to state that I am not an authority on any of the following bits of kit or technologies other than to say I know of their existence and in the case of the PICAXE range of processors how I have got them to do what I want them to do.
 
Moving along, hardware-wise, other than numerous diodes or, maybe, even relays, on the electronics front there is the Arduino Uno (and other types of boards from Arduino - the Nano, the Mega and others - not to mention the cheaper clones of them). Personally, I'm not particularly versed in what this series of boards can and cannot do but essentially they are built onto a ready-made circuit board and can be easily expanded by what is known as "shields" (add-on boards) which plug onto the Arduino pcbs to give some versatility and expansion of functionality. I think they can be made to do pretty much the same as I've managed with the PICAXE series of processors. But you do need a knowledge of the C++ language in order to program the Arduino series.
 
That is not where I'm coming from - I know absolutely nothing about C++. My knowledge only stretches to the BASIC language in one form or another and dates way back to the days of the Sinclair Spectrum (that's showing my age!). Whatever language you might choose to work with, it's only a matter of learning the syntax relative to that language and then using the right hardware for it.
 
The programming software used has the built-in capabilities of converting (or compiling) your code, whether you program in BASIC or C++, into the language that the processor understands - more easily understood as the "machine code". I once tried to directly program the Z80 processor of the Spectrum (in machine code) in order to gain additional memory space - not easy - and I still ran out of memory! 48k of memory is miniscule by today's standards.
 
Getting back to the subject of hardware for my layout. My criteria was to keep costs down and the learning curve short. Hence I decided to continue with the BASIC language together with the relative cheapness of the PICAXE chips. OK, so the whole PICAXE system was designed more as an educational system for schools. But, in my mind and those of many others, it can be so much more. Also needed is (as I build the kits) a piece of stripboard and a few other small/cheap components like resistors, capacitors and +5volt regulators - these PICAXE devices, like most logic chips, only run with a well regulated +4.5 to +5v supply.
 
Hence I have gone for (and I hasten to add, I have no connection to this company other than as a user) the Revolution Education series of PICAXE chips. These are standard PIC chips from Microchip Technology but with a pre-programmed on-board bootstrap interpreter that enables the use of the BASIC programming language.
 
That's a very brief introduction to making a start on automating various aspects of a layout. Incidentally, both the PICAXE and Arduino can be programmed from a PC or Laptop without anything more than a USB port and a cable - all software to do the programming is either supplied or free to download.
 
A couple of links for those that might be interested in looking deeper into this area of possibilities:
https://picaxe.com
https://www.arduino.cc/
 
Coming up next..... My projects, either working or in the planning/build stage.
 

Back To Top PMQuoteReply

 Posted: Mon Jul 27th, 2020 04:26 pm
PMQuoteReply
link to this 2nd post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

A bit of background first. And a bit of techie talk. As mentioned above, I'm using the PICAXE series of processors from Revolution Education which uses a version of the BASIC programming language. I've used BASIC in one form or another since the days of the Sinclair Spectrum but never got to grips with C or C++ or any other form of programming language (of which there are many - and the list is expanding all the time).
 
I first mooted the idea of using the PICAXE microprocessors to automate some aspect of John Street way back in Sept 2016 (see my 2nd post). And following on from this first success, decided to take it a whole lot further rather than simply dream about what might be do-able.
 
If the option of using the basic Revolution Technology PIC processors are used, they can hold around twice the program size of the equivalent PICAXE and the programming itself can be more involved, more complex. Thus is the simplicity of the BASIC language as opposed to the rather more complex C++ command set. The number of input/output ports is the same which ever option is chosen, PIC or PICAXE, it's the same basic chip. I should mention that the PICAXE chips come in a variety of pinouts versions, from 8-pin, 18-pin, 20-pin, 28-pin and 40-pin varieties. Anyway for what we, as model railway enthusiasts require, complexity I don't think really comes into it. Although that just depends on what you might want to achieve.
 
Each port of these processors can only source/sink a maximum of 25mA with an overall capacity of 185mA/200mA or so per chip (chip type dependant). Therefore, if more than one LED needs to be driven per port (such as the signal itself and a mimic board LED) or if the overall chip current capacity is likely to be exceeded then the use of a driver chip such as the ULN2003a or ULN2803a (or even a basic transistor) can be used to increase the current capacity of each output port to approaching 500mA - more than enough for driving any peripheral, even DC motors. Not that the driver chip will be capable of driving all 7 or 8 ports at 500mA each - the datasheet does specify a maximum current at a certain duty cycle. Driving 3 LEDs on each output at 15mA per LED still only comes in at 350mA (for the 8-port ULN2803a) but at a possible 100% duty cycle. So this needs to be bourne in mind.
 
My first project was to make a Theatre-type display on the approach to the Terminus together with the Home Signal controlling the access. As the Terminus has six roads/platforms to arrive into, I also needed to have inputs from each of the numerous points so that I would only get a green aspect when a correct path had been set and when nothing was likely to cross the path of the incoming train, i.e. by a shunt movement.
 
This involved the 10 points of the Terminus, a red/green Home Signal, a couple of sensors and 4 outputs for the display - i.e. 18 input/output ports. This decided the chip version I needed to use - a 28-pin PICAXE 28X2 has a possible 21 input/output ports. The other pins are for programming, supply rails, an external resonator to provide for other than the pre-programmed speed of operation and a reset pin.
 
The programming was created to keep prototypical signalling schemes as far as possible and this involved keeping the Home Signal at danger until a train was on close approach (this is to ensure it slowed down sufficiently prior to access to the Terminus and to allow for the train to stop prior to the signal should access to the Terminus not be available at that time) before turning to a green aspect and only then if there was a valid path for it to arrive at a platform. Along with the green aspect, the 7-segment display would then also show the platform number. At the time of building, designing a fibre-lit theatre display was not realistically possible.
 
The programming was relatively straight forward, mostly IF (this condition)..THEN (do this) command strings: so we wait for the approaching train sensor, then checking a series of points and if a valid path was available, give a green aspect and display the appropriate platform number on the 7-segment display, then wait for the train passing the next sensor and turn off the theatre display and go back to a red aspect, then await the next approaching train. If access was not possible, due to a points conflict, then the danger aspect would remain until the line did become clear to enter the Terminus.
 
The programming editor features a "simulator" mode so that the program can be stepped through command by command before programming the PICAXE itself. Make a mistake and on the layout it doesn't do quite what you thought it would? no worries. Correct the program and re-program. Simple.
 
As probably noted on the John Street pages, the project involves:
the PICAXE 28X2 processor driving a
4511B BCD decoder - 4 control lines in from the processor : 7 lines out to the
7-segment display LuckyLight 1202 KW1-321CWB-JY - a 8mm (0.32") high display.
The processor also drives 2 outputs for the Home Signal via a
ULN2003a (7-port) driver for the
Red and Green LED aspects (copied to the Mimic display),
two RPR-220 in-track sensors and
10 inputs from the various points.
 
One processor port could have been used to combine the Home signal Red and Green outputs. This could have been achieved with the addition of a 7404 inverter chip: the signal output would then be routed direct to one port of the ULN2003a to provide (say) the Red aspect and also via one 7404 port to invert the signal and then be passed to a second ULN2003a port to provide the Green aspect. So that if the Red aspect is set to be a "high/1" output it would switch on the ULN2003a and pull the supply via the LED to ground, thus lighting the Red aspect, while via the 7404 the output here would become a "low/0" signal and the ULN2003a would be inactive and the Green LED remain off. If the signal output on the processor went "low/0" then the direct line to the ULN2003a would also be "low/0" and the Red LED would remain off, whereas the signal via the 7404 would be inverted and become a "high/1" and turn on the Green LED. Easier to work it through on paper than it is to describe in words! If a Yellow aspect is also required, then the processor still only needs to output the Red and the Green signals. This time both would be passed direct to the ULN2003a and again both would be passed via a 7402 NOR gate so that if both Red and Green signals were at a "low/0" level the output would be a "high/1" and would drive another ULN2003a output producing the Yellow aspect. I've not delved into the Double Yellow scenario just yet but should be simple enough with a bit of logic fiddling to make it light correctly - unless your processor has enough ports to drive each LED separately of course.
 
But, in this case of only needing a Red and a Green aspect, and as I had sufficient ports available to me, I left them as separate outputs from the processor. But the above idea of producing a Yellow does come into its own further down the projects.

 


Next up......servos and a working set of Uncoupling Ramps.

Back To Top PMQuoteReply

 Posted: Wed Jul 29th, 2020 08:37 am
PMQuoteReply
link to this 3rd post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

A bit of a lengthy item this (in 3 sub-sections), but bare with me - hopefully all will get explained regarding servos.

The next working project has been to make and semi-automate a number of Uncoupling Ramps using miniature SG90 servos for the tension type of couplings. The size of these servos: 32.2mm long, 11.8mm wide, 31mm high (including the arm) and only 9gm in weight. The SG90 servo cable has wires coloured Orange for Data, Red for +5v and Brown for 0v/ground. Other colours may be seen depending on the manufacturer of the servo - always wise to check the spec sheet.
 
For those not familiar with servos, they (generally) operate/move an arm (known as "horns") over about 180 degrees, have 3 wires to operate them: a +5v supply, a ground (0v) connection and a Data line. Some servos can be modified to produce a 360 degree rotation of the arm. But we'll be concentrating on the normal (unmodified) servo with the 180 degree movement.
 
One problem with servos is that they have a tendency to generate a lot of electrical "noise", both on to the supply wires and also to a degree in a radiated form. As far as the supply wires are concerned, a decent amount of decoupling capacitance is required - a small 0.1uF ceramic capacitor to reduce any high frequency noise and some large decoupling capacitors to keep the output from the +5v regulator smooth and free of voltage/power "brown-outs" as some of these servos can take quite a hefty amount of current, sometimes in excess of an amp. Just using a normal 7805 regulator on its own might not give sufficient regulation without the addition of the reservoir/decoupling capacitors or if the supply to the regulator doesn't have enough headroom.
 
It should be noted not to use the same +5v supply for both servo and processor due to the electrical noise coming from the servo on the supply cables. Keep the supplies on separate +5v regulators (but keeping the 0v rails tied together). It's also a good idea to keep the cable away from other sources of electrical interference, such as the DCC wires and mains supply cables as the servo's Data cable acts as an aerial and any interference introduced onto this cable might be interpreted as a valid signal to move the arm.
 
Servos seem to be prone to jitter and twitching of the arm and, in this case at least, it was not fixable by the addition of supply line decoupling, etc. when using the 'normal' commands to move the servo arm. Some additions to the normal circuit that feed servos might include, as noted above, one or more 0.1uF ceramic capacitors and up to 6800uF of electrolytic capacitors (rated 15v min) and a 10k resistor in line with the data feed from the processor. Some comments I've seen mention a 330R resistor (which I tried) without much success. Also it has been suggested to lightly twist the cable between the processor and servo to try to eliminate stray noise or to pass the cable though a ferrite ring a couple of turns to introduce a bit of inductance to help stop noise and interference or even to add a 0.1uF capacitor between the Data cable and either the +5v or ground wires. It seems to be a different set of circumstances and fixes required dependant upon all manner of things, such as circuit board layout, positioning of the servo in respect to its surroundings and how the cable runs between the processor board and the servo.
 
As far as the "data" required for the servo is concerned, the servo likes to have a regular series of pulses 20mS apart with a positive pulse of between 0.75mS and 2.25mS - with 1.50mS representing a central position for the arm (some variation of these figures is servo dependent).
 
The PICAXE series of processors can very kindly produce a continuous series of 20mS pulses using the SERVO command and upon this is added the required positioning pulses using the SERVOPOS command. The SERVO command starts the timing of pulses while SERVOPOS inserts the required positioning pulse length. The syntax for the commands are:
SERVO B.4, 75     ; start the 20mS pulses on port B.4 and move the arm to the left-most (-90 deg) position - every 20mS a 0.75mS pulse will be added and this will hold the servo arm steady at that point
SERVOPOS B.4, 150     ; move the arm on port B.4 to the central (0 deg) position and that 1.50mS pulse will be output every 20mS (until the next SERVOPOS command)
 
From my experience, if you try to slow the servo down too much by adding PAUSE commands between each SERVOPOS command, it can lead to some arm jitter which is nigh-on impossible to get rid of no matter how much decoupling, etc. is thrown at the circuit. I may be wrong here, but that's my experience of trying to get a smooth operating speed for my level crossing gates which require moving at a slow speed (more on this in the next article). A servo normally takes less than 0.5 second to swing the arm through 180 degrees, so to slow it down to swing 90 degrees in maybe 5 seconds or so is quite a slowing-down of the servo. Also, I have issues of where the gate suddenly flies off to the servo end-stop (I presume that's where it goes) before flying back to continue its intended movement. I feel that this has something to do with a timing issue between the commands, but I could be wrong. But the level crossing is for another day.
 

Back To Top PMQuoteReply

 Posted: Wed Jul 29th, 2020 08:40 am
PMQuoteReply
link to this 4th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

Back to the Uncoupling Ramps. So, to try and eliminate these issues of jitter, I decided to go right back to basics with the code (and with the help of the PICAXE forum members - a very helpful group of people) and try another command that is present within the PICAXE system - the PULSOUT command. Those on the PICAXE forum call this method of servo control "bit banging". This only sends a pulse to the servo as and when you need to send that pulse - so there is no continuous stream of 20mS spaced pulses being sent by the processor and if there is any force normally being applied to the servo arm, then the arm will tend to move and not be held steady by the continuous series of pulses as sent out by the previous two commands. But as long as the minimum period of 20mS is kept between each required pulse (and no external force is being applied) then all should be well with the world. If running the servo at a slow speed then this minimum 20mS timing aspect should not present a problem.
 
Yet in my program the PULSOUT command still uses the same PAUSE command (as with the SERVOPOS command)....and the servo seems to work much smoother. The syntax for this command is:
PULSOUT B.4, 150     ; send a pulse on port B.4 to move the arm to the centre (0 deg) position
PAUSE 20     ; wait 20mS before looping back to the next PULSOUT command (as part of a FOR...NEXT loop) - this pause can be any suitable length to make the movement of the arm as slow as you would like it to be.
 

The pulse shown here is for a 1mS to 2mS pulse, whereas it might normally be 0.75mS to 2.25mS as noted above

The difference, as I see it, is the SERVO command sets up a continuous series of timing intervals as required by the servo and the SERVOPOS command sets the length of the pulse that governs where the servo moves to. Whereas the PULSOUT command simply puts out a single pulse to control where the servo moves to one step at a time and so long as the minimum required interval between pulses is maintained there can be no timing errors. The timing of the next pulse by using PULSOUT is controlled by taking into account the length of time any intervening commands take together with any pause command to pad out the timing to get the right speed of movement. That's my theory of it anyway, rightly or wrongly. I stand to be corrected here.
 
Components used for the Uncoupling Ramps:
PICAXE 18M2+ processor,
a rotary switch to select the ramp to be raised
a push button to activate the raising of the selected ramp.
 

Back To Top PMQuoteReply

 Posted: Wed Jul 29th, 2020 08:41 am
PMQuoteReply
link to this 5th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

The 18M2+ processor is capable of driving up to 8 servos, but I only used 6 as each servo needs its own outgoing Data line and its own incoming activating signal. And when you add an indicator LED and take into account the 2 supply rails and the programming ports there is only one spare port to play with.
 
The program was written such that a servo once selected would slowly raise a short length of plastic, about 35mm in length (taken from an old VHS cassette case - the same thickness of the track sleepers - I said earlier, cheapness and DIY! - laid between cut-away sleepers to disengage the tension hook couplings, wait for around 10 seconds to allow the rake of trucks or coaches to move away and then slowly lower the ramp again back to its resting position.
 
Two thin nails were put through this "ramp" and glued in place and allowed to freely pass through the baseboard - these nails are to keep the ramp aligned and central within the track. The actuator used on this design was a short length of 3.5mm OD pvc tube (to allow for flexibility in movement/alignment) inserted and glued into the ramp and connected at the other end via a short pin through the servo arm itself. The servo being mounted, in this case, on another offcut from the VHS tape cassette (other methods of mounting these servos are available!).
 

  Initially while testing, I found that with the SERVO/SRVOPOS commands being used that the small 7805 +5v regulator got impossibly hot due to each servo being constantly powered with the 20mS pulses. Changing to the PULSOUT command reduced the current consumption to acceptable levels. At the time of building and testing I was not aware of the amount of current these servos can take - something in the order of up to, and sometimes in excess of, 1 amp - not a widely publicised fact, a fact I found to be strange given these servos can be used on battery powered equipment, such as model aircraft. And not all SG90 servos are equal in respect of how much current they take!
 
The end result is that the Uncoupling Ramps raise (and lower) nice and slowly so there is no chance of sending a truck or loco sky high at a rapid rate of knots if the positioning of the coupling between trucks is not correctly aligned before the ramp is raised. Some careful adjustment of SERVOPOS figures is required so not to try to pull the ramp down through the baseboard on lowering the ramp or to raise it too high so as to lift a truck off the rails, just enough to disengage the couplings.
 


That's the Uncoupling Ramps about covered for now. Next time I'll take a look at the Level Crossing Gates - work is still in progress here, so maybe a few days or so before posting this next item. Bare with me.
 
 

Back To Top PMQuoteReply

 Posted: Wed Jul 29th, 2020 03:45 pm
PMQuoteReply
link to this 6th post
BCDR
Moderator


Joined: Sat Oct 19th, 2013
Location: Reston, Virginia USA
Posts: 3425
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

Hi Dave,

I'm bearing with you. Definitely not baring with you though.  :lol:

Nigel



____________________
©Nigel C. Phillips
Back To Top PMQuoteReply

 Posted: Wed Jul 29th, 2020 04:41 pm
PMQuoteReply
link to this 7th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

Thanks Nigel.

T'was early this morning I twiped the item up with eyelids wide shut at the time. Shame the auto corrector didn't pick it up (but I guess it was a valid spelling, although not necessarily in this context!). Memories of Morecambe and Wise with Andre Previn...... classic sketch. That's my excuse.


Back To Top PMQuoteReply

 Posted: Fri Jul 31st, 2020 03:51 pm
PMQuoteReply
link to this 8th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

I ought to make a suggestion that if anyone has any comments,
   or suggestions as to how to make any of these projects better or in a different way,
      or suggestions as to other subjects I could cover,
         do please contribute.
It's all about learning. And I'm always keen to learn - keeps the grey cell active!

Other items on my list to complete and then write up over the coming months:

1.   coming up,  end of next week hopefully - automatic train-activated Level Crossing Gates using Wills SS56 kit (across a single track line); followed by....
2.   automatic colour light signalling, using Eckon signals - this is mostly related to linking processors, together with....
3.   automatic semaphore signals using Ratio kit 486, LNER upper quadrant signal (if my fingers are supple enough!).

Most of these have been covered before in one form or another, mostly as standalone items and/or as manually operated, but my idea is to link them together using the PICAXE series of processors so that they all form part of the overall track plan.


Back To Top PMQuoteReply

 Posted: Fri Aug 7th, 2020 03:55 pm
PMQuoteReply
link to this 9th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

Automated Level Crossing Gates.

There's been a bit of a delay in getting this next topic sorted due to problems with linking the servo to the level crossing gate itself. So, apologies for that. More on the gates in a moment.

Moving on and yet keeping on the subject of servos, this item is about automating Level Crossing Gates so that they will open with an approaching train (hopefully in plenty of time) and then close again once the train has passed - with the proviso that if a train needs to reverse into the siding, the gates need to remain open until that movement is complete. It also needs to recognise when a second train is approaching and to keep the gates open until the second train has passed. It's all in the software!

This kit is built up using a pair of
Wills SS56 Level Crossing Gates (4mm OO gauge) and again a pair of
SG90 servos across a single track line (and with adjacent access to a siding) together with a
PICAXE 18M2 to control it all and
2 RPR-220 infra red in-track sensors and
LM339 voltage comparator and
1 infra-red separate transmitter and receiver (across-the-track sensing) and
1 point for access to the siding.

First things first - the automation bit. Train detection. For this I have opted for Infra-Red transmitters and receivers/sensors.

The RPR-220 Infra-Red transmitter and receiver pair can be regarded in exactly the same way as normal, individual transmitter and sensor items except that it is packaged as a single item and is suitably sized so as to be buried into the baseboard, which will sit nicely between the tracks and fit between two sleepers (hardly visible). The Tx/Rx pair measures just 4.9mm x 6.4mm x 6.5mm high. Forward current to the transmitter is to a maximum of 50mA with a forward voltage of 1.34v - generally, the current taken should be around 17mA. The receiver collector needs to be fed via a 470k resistor (from a +12v supply) or 10k (from a +5v supply) and this will give a good degree of sensitivity. As the output from the collector of the receiver can vary with the amount of reflected (Ir) light, it is advised to feed that output into an LM339 comparator - this is a 4-port device so is expandable for other sensors on the layout. This will give a clean change (no bounce) in voltage levels to be applied to the input of the processor. The point at which that changeover takes place can be varied by means of a 22k pre-set resistor on the associated port of the LM339 so is relatively independent of the reflected light.

I had emailed/requested Rob Paisley for permission to include the (copyrighted) circuit here, but at the time of posting this, I have received no reply. So below is the web link to the page - the circuit is the last one on the page entitled "4 - INFRARED PHOTO-DETECTORS USING AN LM339". If permission comes through at a later date, the circuit will be included at that time.
http://www.circuitous.ca/ATDetIR.html (the web page has changed from that shown in the actual circuit diagram).
Also see http://www.circuitous.ca/Comparators.html for a complete write-up on voltage comparators. Overall, this is an excellent website for all things electronic, quite a lot railway related or adaptable for it.

Using another port of the LM339, I also used Ir Tx/Rx separates as individual items as an across-the-track sensor pair set at an angle across the track such that there would be no gap sensed between trucks and therefore the gates would not be closed against the train prematurely.

In the circuit noted above, when the sensor (receiver) becomes blocked, i.e. no train passing over, the LED lights. Or to put it another way, the output goes low. This state can then be sensed by the processor and action taken as appropriate. If there is a need for the LED to be off, i.e. the output voltage to be high, when the sensor is blocked, simply swap the two inputs over. Incidentally, to cater for differences in sensor components or positioning, each mid point pre-set voltage level can be individually set rather than using the same voltage level across all ports, as shown in the circuit by using the two fixed 10k resistors.

Now moving on to getting the level crossing gates themselves working.

Back To Top PMQuoteReply

 Posted: Fri Aug 7th, 2020 03:58 pm
PMQuoteReply
link to this 10th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides

Something I perhaps should have mentioned in the previous item about servos and the pulse passed to them being between 75mS and 225mS with a mid-way position of 150mS. Shortening to the pulse (towards 75mS) will make the servo arm turn anti-clockwise and, strangely enough, lengthening the pulse (towards 225mS) will make the servo arm turn clockwise. Having got that out of the way.....

The problem here, yet again, like the uncoupling ramps, is getting a smooth operation/swing of the gates. It was thought the ideal time taken to swing one gate would be around 5 or 6 seconds. Any jitter on either servo would be wildly exaggerated due to the length of each gate and the rather flimsy structure of the gates themselves. So getting a 'smooooooth' servo operation is of the utmost importance. So that effectively ruled out using the SERVO/SERVOPOS command pairing and making use of the PULSOUT command. But I did try using the twin commands just in case - no, jittery.

I was able to get the right speed of swing but there was still quite a lot of flapping about of each gate which got worse as the gate swung through its 90 degree swing. As mentioned in the previous post, copious amounts of capacitance was added across the +5v supply rail but this made no real difference. But this wasn't simply just servo jitter - as I later found!



The level crossing gates themselves each have a length of wire inserted and glued into a hole drilled (very carefully!) into the gate post. This provides the gate pivot pin.

One thing I did notice on the original setup, and more by accident than anything, was that the servos were not exactly aligned underneath the gate pivot pin which passes through the baseboard and then connected directly above the centre of the servo arm through a choc-bloc connector - see the photo above. This was most likely due to a misaligned mounting and/or non-alignment of the servo arm wire. Neither wouldn't have helped keep the movement smooth.

Alignment of the servo to the gates seemed to be a huge problem in trying to get it all aligned correctly so that not only did the gates swing through the 90 degrees - that was simple enough once the PULSOUT figures in the program were sorted, but also that they swung horizontally and not either scraped the road surface or rose into the air - namely that the gate (hinge) post needed to be truly vertical.

So the initial arrangement (in the picture above) was eventually scrapped as being too difficult in the space available to me to make the adjustments so I opted for a remote servo with a linkage to the gate pivot pin.

This new arrangement involved having the servo moved away from under the gate pivot pin and using a couple of linkage wires to link between the servo arm and the gate pivot pin. I can't claim any originality for this method, but it would appear to be easier to setup - certainly in places where there is little wriggle room for arms/fingers/screwdrivers/you-name-it!



The above is a test mock-up of the actuator to make sure I could get enough "swing" on the gate with the servo and arm at the top (just held in place with a screw) and the linkage to the level crossing gate at the bottom. With this arrangement I can get around 105+ degree swing - more than enough.

If you're anything like me, I couldn't drill a truly vertical hole if I tried. To overcome this shortcoming in dexterity with a drill I initially drilled a larger hole through the baseboard than was required then glued a small square of relatively thin plastic (part an old credit card would be ideal) with a hole very slightly larger than the gate pivot pin to pass through in the correct place on the top of the baseboard. Then once the glue was fully dry, glue a similar piece of card under the baseboard and, before the glue had set, it was adjusted to obtain the correct alignment of the gate such that it wouldn't scrape the road surface nor would it ride high as it swung. Then once that glue was dried and set solid, the linkage arms were fitted along with the servo sitting between blocks of wood (about 18mm - 25mm high) - or in my case, on a short length of angled wood moulding.

In the mock-up (just the servo arm, linkages and dummy pivot pin - just to test to see if it worked) the linkage arm from the gate pivot pin is about 15mm in length (about the same length as the servo arm). The length of the adjoining link can be any length that suits the space available. Some old Twin&Earth house wiring was used here, but any suitable stiff solid core wire that comes to hand would most likely be usable. Some positioning adjustments can be made using the choc-bloc connector (or within the servo program) and by altering the length of the shorter linkage arm if the full 90degrees (or thereabouts) cannot be obtained. It's very much trial and error to adjust. But this mock-up largely worked and was hugely better than the direct-drive from the original servo version (above).


Back To Top PMQuoteReply

 Posted: Fri Aug 7th, 2020 03:59 pm
PMQuoteReply
link to this 11th post
Dave C
Full Member


Joined: Sun Oct 26th, 2014
Location: Doncaster, United Kingdom
Posts: 198
Status: 
Offline

My photos:
view photos in Gallery
view photos as slides




Final installation of the servos and linkage arms - the small pieces of plastic card can be seen where the pivot pin emerges from the layout side of the baseboard.

So to recap, as this series is about automation. The whole module is controlled by an 18M2 PICAXE processor as described earlier. The adjacent Halt Home signal is normally showing a red aspect (the gates being held closed to trains). A train is detected some distance away in its movement towards the level crossing as it crosses an in-track "approach" sensor. The gates then swing open and this in turn triggers a signal to the signalling processor to change the Home signal to a green (or a yellow) aspect for the train to pass - provided of course this next "block" is known to be clear. The train gets detected as it passes over the in-track sensor shortly after the Home signal. This is again then passed back to the signalling processor to put the signal back to a red aspect, the preceding signal to a yellow aspect and to flag the next "block" as now being occupied. Once the train has cleared the across-the-track sensor beyond the gates, the gates then close to trains. And we await the next train to cross the "approach" sensor. In the case of a train requiring to reverse into the siding, the across-the-track sensor remains blocked, the gates remain open and once the in-track sensor again detects a train (with the point noted as being set for the siding) and the processor will then wait until that sensor is again cleared as well as the across-the-track sensor before opening the gates.



I should point out that servos are not the only method of activating Level Crossing Gates. There is also the option of Stepper Motors - but these also require processor control to move the motor rotor and to count how far the rotor has moved - and straight DC Motors with low reduction gearing to reduce the speed to an acceptable level. Also needed here would be some form of method of stopping the gates in the correct position, either with microswitches or Hall Effect switches (little solid state devices that react to the effects of a magnetic field) and with a small magnet mounted on the gate or on an arm mounted under the baseboard.

That's about it for the Level Crossing. Next up will be the automatic signalling.

Back To Top PMQuoteReply

This is topic ID = 16438     Current time is 03:45 pm  
You are here:  Your Model Railway Club > Getting You Started. > The Lineside. > Processor Control of Lineside Items
You can type a quick reply to this topic here. Click in the box below to begin.

Or to reply to an individual post, or to include images, attachments and formatted text,
click the Quote or Reply buttons on each post above.

To start a new topic in this forum, click the Start New Topic button below.
To start a new topic in a different forum, click the Forum Jump drop-down list below.
Start New Topic


Back to top of page

           
15 Most Recent Topics

Problems with this web site? Please contact the Webmaster.

All material submitted to this web site is the responsibility of the respective contributor. By submitting material to this web site you acknowledge that you accept full responsibility for the material submitted.
Unless stated otherwise, all the material displayed on this web site, including all text, photographs, drawings and other images, is copyright and the property of the respective contributor. Registered members are welcome to use it for their own personal non-commercial modelmaking purposes. It must not be reproduced or re-published elsewhere in any form, or used commercially, without first obtaining the owner's express permission.
The owner of this web site may edit, modify or remove any content at any time without giving notice or reason.    © 2008

                 

Recent Topics Back to top of page

Powered by UltraBB 1.15 Copyright © 2007-2011 by Jim Hale and Data 1 Systems. Page design copyright © 2008-2013 Martin Wynne. Photo gallery copyright © 2009 David Williams.