I would appreciate a non technical, non acronym (unless explained!) guide to train detection and automatic movement of stacked trains

[Tallpaul69]

I am trying to get my head round future proofing my soon to be built DCC layout so that I can eventually introduce "Train/track detection" and "automatic Movement of Stacked Trains" without finding that my existing control system is unsuitable. The layout will be a roundy round double track main line with 4 fiddle yard loops in each direction each holding 3 trains of differing lengths.

There will be a loop plus sidings in each direction and a single line branch in the scenic area. The branch ends in a set of sidings and a run round loop. I have so far invested in a Powercab, and started to get locos chipped with a mixture of Zimo and Hornby TTS chips.

 

My thread titled "My DCC Journey" gives you more details of where I am at in converting to DCC.  

 

I have been reading threads such as "Automatic Movement of Stacked Trains" and "Failed Track Detection" and while having worked in telecommunications for a long while I find I am lost in the technicalities. 

 

I will be pleased to answer any questions that the details above and the above thread do not answer, and am hopeful someone can either point me in the direction of other threads that detail other modellers journey through detection and automatic movement, or explain what is needed and how it works in a not too technical way.

 

As Chaz said in his thread  "Automatic Movement of Stacked Trains" I want to model a railway not do a computer project!!

 

Many thanks

Best regards

Paul

[WIMorrison]

 I think it will be almost impossible to create a description without understanding more of what operating characteristics you want to ‘automate’

 

do you just want trains to stop at stations or do you want them to follow predefined, and variable routes, do you want them to run randomly creating their own routes? Then it comes to train makeup, do you want trains to reverse into sidings and disconnect and reconnect to other trains.

 

the one thing that I can say is that none of these are ‘plug and play’ even the simple stop at station only takes an amount of logic and ‘programming’ - the more functionality you want the more you need to do.

 

from your description of initial ideas you are going to be going down the complex route and that cannot be done without getting involved in a computer project as part of the solution

 

this is a complex subject and it can go whichever way you want but It isn’t plug and play

Edited May 9, 2019 by WIMorrison

[WIMorrison]

Paul

 

in the simplest terms the program needs to know exactly where the train is at all times, it needs to know the length of all the track in the layout and also the logic that exists ie what connects to where. It will need details of the speed profile for all the locos, it will need the length and some other parameters of all stock running on the layout.

 

with this information, and a suitable interface between the program and the command station, control can be undertaken of all the trains giving you a private exhibition as if someone else is operating it all for you.

 

there are many programs available - the 2 main commercial being iTrain and Traincontroller, then there are 2 main open source products JMRI and RocRail - there are more around but these would be the main players

 

many companies provide the necessary electronics with digikeijs being about the most cost effective. 

Edited May 9, 2019 by WIMorrison

[Phil S]

'Train' Detection - for some this means only detection of a 'Locomotive'  (or other power consuming device), and is commonly achieved by detecting whether ANY current being consumed within a 'section'  - and therefore requires (at least one rail of )  the track to be electrically  separated from other rails - a method that has similarities to analogue cab-control/sections, which may explain its 'popularity'/familiarity.

 

As Current Detection requires ALL the detected-track-sections'  power feeds to PASS THROUGH Monitoring Devices, it is best included in the initial design and build of the track, because the wiring distribution needs to be based XaroundX THROUGH it.  Railcom/Railcom+ is a feedback system available for DCC ( matching a similar ability of Marklin's Mfx Digital system to have 2-way communication ), which ALSO NEEDS SECTIONS to identify the LOCATION of the Object ... typically by using more-advanced  current monitoring devices which can decoder and pass-on the extra information obtained to a computer/controller, instead of just a simple occupied or not status.

[Railcom/+ has many features provided by sending back information from the on-board decoder, which can include 'play value' ??? items such a 'simulated coal or fuel load' - or perhaps more usefully for larger automated layouts - running time for servicing interval information ]   {Personally I question the benefit of a loco 'simulating' running out of fuel in a tunnel on the far side of one's layout - but it does have other uses 8-)

 

Other 'detection' methods include Optical (beam break or reflection by a nearby object), Magnetic - using 'Hall Effect' electronic switches or reed relays,  'Contact'/treadle activated switches in the track,  Barcode reading ( as with items in a supermarket ) and RFid tags ( uniquiely pre-coded transceivers which are activated when they are close to an RFid Reader.    THESE ALL monitor a  small, specific, location - where (each) detector is placed, and do not need to be part of the dcc-electrical track system at all - (Which I consider to be an advantage from the point-of-view of fault-finding and maintenance),  and CAN be added AFTER the track layout is built and running .   The OPTICAL detectors will DETECT ANY OBJECT that is not transparent ( to Infra-Red ) and therefore will detect any wagon or obstruction (including a hand)  in the way of  the detector -  they will respond to the WHOLE TRAIN and not just the specific part with a Magnet or Bar Code or RFid tag.

( Personally I prefer the idea of Optical detection - because it IS separate to the actual track running  - and means my track sectioning is chosen for power distribution and fault-finding simplicity, and not confused with analogue-sectioning or train-occupation-blocks. Both can be operated and checked independently for greater reliability. Eg my Transportable Skandi Layout uses 3 power districts = just 3 sections, but for electrical train detection would be 80 sections - and information from all of those would need relaying back across multiple board joins... [less of a problem for a permanent layout ]   whilst I am considering adding railcom to the layout - that will be just 16 blocks (Digikeijs Module) and confined to 2 joined boards which host the main storage areas.  The remainder will again be optical, as with its predecessor layout )

 

MAGNETIC Detection is made easier by modern NEO magnets - so that only a small, and economical magnet needs to be fitted 'beneath' stock- and this could therefore be extended to every piece of stock, making the system 'train'/object detection, as with optical, rather than 'loco' detection. Small magnetic reed relays or Hall sensors are placed in the track bed, and the on/off information passed back, as with other systems, via a 'concentrator'-FEEDBACK-module' which usually gathers together information from 8 or 16 individual detectors, giving them an 'address', and then passes them back on a Feedback Bus  to either the Controller or a Computer

 

BarCode Readers - Lissy(R) or perhaps a system announced by not yet released by Hornby ??? adds the benfefit of unique identification to the simple occupation-detection mentioned above - thus providing definitive train-tracking  information back to a computer (Eg Railmaster, RR+Co, etc).    RFid tags are another, non-contact method of passing back unique identifying information - MERG make kits for members which include  an 8-way Concentrator combining information from 8 detectors through 1 serial port  (or there is now a CAN-bus version)

 

KNOWING which Loco is WHERE is an important aspect of train control ensuring reliable train-tracking under computer control along predicted routes through pointwork ( where the computer assumes the direction of points because they were also dcc controlled ). UNLIKE ANALOGUE  - the identity of EACH controlled loco MUST be known to the software/controller/driver -  whereas a 'simple shuttle'  in analogue could work with ANY unidentified loco placed on the track.  This is why Rfid, BarCode and now Railcom options can be so useful on a 'larger' or computer controlled layout.    Mfx (from Marklin)  automatically identifies a loco placed on the track to the controller, and displays its identity, without the owner having to set a loco address. - the advantage of being an 'in house' desigh rather than via a committee of differing manufacturers.

 

There are also Ultrasonic Transponder systems from a Danish Company, which, in combination with 3 listening sensors, will locate your Object in 3D [ Each fitted loco emits a uique ultrasonic pulse-code when requested, which is triangulated by the 3 listening sensors, like GPS satellites]  ..... and as a side effect, it can firstly build up a 3D track plan of your layout as you drive around it, and then show your trains  position on the plan.... and offer automated control of it - even by the spoken word  [ when we first saw this being demonstrated at the Danish Railway Museum, some years ago, it long-preceded the likes of 'Alexis' or other household voice-activated items ]/

 

To summarise: for Automated, Control or semi-automated operation such as stopping (some) trains in stations, the control system needs to know where THE train is, and this can be detected by a variety of means - each with there own advantages and disadvantages. SOME REQUIRE the manual entry of the specific loco identify, which is then train-tracked around the layout when the controlling device (computer) knows or controls the loco direction and route over pointwork... until it reaches further detectors.   Railcom, Barcodes, RFid, or  Mfx are examples of methods of automatically and uniquely communicating back to the computer information about the loco such as Id, speed, direction, running time etc, for more complete control options.

As mentioned in a previous contribution: Pointwork should be excluded from adjacent  'occupation' sections, as routes need to be changeable

when points are not-occupied.

[Nigelcliffe]

This thread has already become complicated, and not all options discussed yet.

 

I think the only way to approach automation is to list, precisely, what one hopes to achieve, and rate each of those requirements between "nice to have", "important" and "essential".   That should include the existing equipment and how painful replacing it might be. (eg. TTS decoders don't do RailCom, the NCE system doesn't do RailCom - is replacing either an option, or "sorry, they're staying" - either answer is valid, it just places a constraint on the options available, a constraint could be a good thing here, it reduces the vast number of solutions) .   

Then work forwards from the requirements.  

 

 

So far Paul has only very partially attempted this, in saying:
 -  what decoders he owns (TTS and Zimo - already a constraint, TTS decoders don't do RailCom, so if wanting a RailCom solution those locos now need a second decoder adding to transmit the RailCom data, or the TTS decoders have to be replaced ). 

 -   hints that the automation requirement is to move trains up in a fiddle yard with trains stacked in roads  (the list of decoders appears to be a limiting option; the cheap and very simple "Asymmetric DCC braking" solution would work with Zimo, but not TTS decoders  ).  

 

Full automation covering all options can get very expensive.  Knowing which train is where, at all times, requires quite a lot of hardware, a means to gather all that data together (some sort of layout data network) and usually a computer to drive things.   But, limited automation which does certain well defined tasks, with various assumptions, can be considerably cheaper - in some cases the cost can be from 50pence, and an awful lot done with change from £100.  

 

 

If wanting a "all bases covered regardless of how the layout evolves", then my advice is to feed each "block" (track section that one train might occupy on its own) with its own feed, with the wires arranged so they can be broken in future and a detection device added at that break.   

 

 

 

A few years ago, I was involved with a DCC automation demo/clinic at the Warley show, organised by the McKinley Railway team.   It was a vast demo area (far larger than the space that even a large layout would occupy), and there was about 2-3 hours of presentation to work through to explain the options available and how to go about automation.  We covered software, choice of DCC system, types of automation, the issues that will be encountered,  etc..    I've not heard of an attempt to re-run a similar session. 

 

 

-  Nigel

 

 

[Ron Ron Ron]

1 hour ago, Nigelcliffe said:

......eg. TTS decoders don't do RailCom....

 

......TTS decoders don't do RailCom, so if wanting a RailCom solution those locos now need a second decoder adding to transmit the RailCom data, or the TTS decoders have to be replaced .....

 

 

Slightly off-topic, but just a note for anyone interested.

That "second decoder" Nigel mentions, would be a RailCom transmitter.

Lenz, ESU and Uhlenbrock sell them.

 

These can easily be installed in any loco already fitted with a non-RailCom decoder (for example, TTS), to give it RailCom compatibility.

Just 2 wires to the pick-ups, in parallel with the installed decoder.

No other wiring connections required.

 

They can be bought in packs of 5 and by shopping around, they work out at around £9 to £11 per loco.

It's a cheap alternative to replacing decoders with a RailCom equipped type, if you have no further use for the non-RailCom decoder, and/or you really want your locos fitted with RailCom.

 

 

 

 

.

[Tallpaul69]

2 hours ago, Nigelcliffe said:

This thread has already become complicated, and not all options discussed yet.

 

I think the only way to approach automation is to list, precisely, what one hopes to achieve, and rate each of those requirements between "nice to have", "important" and "essential".   That should include the existing equipment and how painful replacing it might be. (eg. TTS decoders don't do RailCom, the NCE system doesn't do RailCom - is replacing either an option, or "sorry, they're staying" - either answer is valid, it just places a constraint on the options available, a constraint could be a good thing here, it reduces the vast number of solutions) .   

Then work forwards from the requirements.  

 

 

So far Paul has only very partially attempted this, in saying:
 -  what decoders he owns (TTS and Zimo - already a constraint, TTS decoders don't do RailCom, so if wanting a RailCom solution those locos now need a second decoder adding to transmit the RailCom data, or the TTS decoders have to be replaced ). 

 -   hints that the automation requirement is to move trains up in a fiddle yard with trains stacked in roads  (the list of decoders appears to be a limiting option; the cheap and very simple "Asymmetric DCC braking" solution would work with Zimo, but not TTS decoders  ).  

 

-  Nigel

 

Firstly, thanks to everyone who has responded to this thread.

Trying to set out what I need the automation I am looking for to do:-

The overall aim is to enable me to run the layout and adhere to the timetable, while I concentrate on the details of activities within the half of the layout that is scenic.

 

The scenic area of the layout concentrates on the following:-

1) a branch junction where a single track branch leaves the double track main line. The station is off scene, but the branch has a track leaving it to go to a branch platform (off scene).  

2) a freight yard comprising up and down loops on opposite sides of the main line. One loop in turn feeds a second loop with sidings off of both ends.

3) The branch has a branch siding parallel to itself and joining the branch adjacent to the start of the line to the branch platform mentioned above.

 

This area is a simplified version of Maidenhead on the GW main line and  the timetable details trains working between Paddington , the London yards and Slough and High Wycombe (on the branch) and points west the first two being Twyford and Reading.

 

The fiddle yard is three parallel tracks in each direction with capacity for three trains each. The lengths will vary from a LE up to a "King " plus 5 coaches.

The branch has its own separate fiddle yard.

 

Here is an example from the morning timetable:-

05.50 61xx tank arrives LE from Slough and moves to the branch siding to couple to a set of suburban coaches

05.55 parcels train arrives from Reading, into up loop and detaches several vans

05.58 local DMU from Reading passes through and stops at the up platform with rear end visible through a bridge

06.00 DMU leaves for London

06.01 61xx pulls train into branch platform, leaves at 06.05

06.07 parcels pulls forward into branch platform, engine runs round.

06.10 parcels departs down branch

During the above 20 mins at least two trains will have run through the down line without stopping.

 

So while I am concentrating on the above shunting activities, I need the following to have happened:_

1) Two trains held behind the parcels to move up the three train loop (which is behind me)

2) Similarly for the loop on which the 05.58 was held initially. 

3) the spaces left empty by 1) and 2) above  will then be filled by the DMU and the 61xx suburban.

4) While I will start the two trains on the down main from the fiddle yard, I need a moving up exercise to happen, to create space for the two down trains on completion of their circuits.

 

I hope the above makes sense?

 

I should add that a "need" is that the " hand in the sky" should only be needed during a timetable session in the case of a derailment etc. Otherwise stock is only to be added/taken from the layout before and after a session.

I also "need" to be able to switch out of the sequence and just let two trains run round and round , until I want to pick up the timetable again. This means emptying two fiddle yard loops except for one train to run round.

 

I know I have not talked about point control and signa control. I think I want to control the signals and points within the scenic area myself, but as timetable sessions will be longer than the above I need to be able to flick a switch or click an icon to change which of the fiddle yard loops is connected to the mainline.

 

Any thoughts?

 

Best regards

Paul 

 

I

[Nigelcliffe]

That helps, it rules out a number of simpler, but limited capability options.

 

I think you need software on a computer, the two market leaders for software are TrainController and iTrain.  
You'll need a fair number of track occupancy detectors, which means wiring your layout so each block (place where a train might be located) can have a block-detector added.  You may also need spot location detectors (typically IR Beam breaking devices) in the track for exact location.  

And a means to get that block occupancy data back to the computer (ie. something to put data onto a feedback bus, the NCE AUI device might be the least hassle for such feedback if you remain with NCE for control).    I haven't checked the limits within the PowerCab for using the NCE AUI, you may have to upgrade it to the PowerPro command station (at which point, think hard whether that's the best option, something with RailCom capability may be better).

 

 

 

 

- Nigel

 

[WIMorrison]

Paul,

 

it would certainly be an interesting challenge to program your desire however it is taking you into a land you state that you don't want to enter, specifically "I want to model a railway not do a computer project!!".

 

You will need to have current sensing over the entire layout - I also suggest that you have feedbacks on your points (at least in the fiddle yard) to ensure that you don't get derailments from stock overhanging into them. This will means that stock which doesn't have lights will need resistive axles to show occupancy. However, with modern software you don't need the IR detectors.

 

Running some areas manually won't be a challenge for any of the current program offerings, the challenge where you will be getting to careful and detailed programming is for your timetable requirements especially as you intend to intervene manually which complicates everything. Finally, you should let the program run the points and switches - you could change them manually but only from within the chosen program.

 

What you want can (probably) be done, and whilst the work on the layout to make it work is trivial, the programming will not be trivial - though automating a layout bring a completely different aspect to the layout - I had some friends around yesterday afternoon  (all modellers) and he were amazed at how trains were stopping starting, running around, disappearing into the fiddle yard to appear 20 mins later and left after 3 hours with a completely different view of automation which they had considered a pointless exercise before visiting me.

 

I suggest that you need to re-consider you're opening comment because if that remains true then your desires cannot be achieved.

[Tallpaul69]

When I said that I did not want to undertake a computer project, what I meant was I did not want to spend ages writing computer code!

 

I am quite happy to set up and run commercial programs on my laptop to make automation work.

 

So if the "programming" referred to is setting up parameters in a already commercially written program, no problem? 

 

I presume the stopping and starting you refer to is decelerating to a stop and accelerating to a set speed not instant stops and starts?

 

Best regards

Paul

[Andymsa]

45 minutes ago, Tallpaul69 said:

When I said that I did not want to undertake a computer project, what I meant was I did not want to spend ages writing computer code!

 

I am quite happy to set up and run commercial programs on my laptop to make automation work.

 

So if the "programming" referred to is setting up parameters in a already commercially written program, no problem? 

 

I presume the stopping and starting you refer to is decelerating to a stop and accelerating to a set speed not instant stops and starts?

 

Best regards

Paul

 

Yes acceleration and stopping are gradual. But you have to do some work with the locos cvs and the computer program. It's not a difficult process to do( I use traincontroller) I have not tried this with I-Train but I'm sure someone will say how difficult or easy it is to do with it.

 

with automation you really need some forward planning and how you wish to operate. 

[WIMorrison]

Paul

 

the detail you need to input into the program is everything about your layout, the more you put in the better the outcome

 

you will firstly need to create a schematic if your layout and this is critical as it will define the logic used when running trains. On top of this schematic you input all the track details, the lengths of it, the feedbacks and blocks, where you want trains to stop, etc.

 

for the locos and the stock you need to enter the lengths and operational parameters such as speed measurements (can be done by the programs), reaction times, etc

 

it isn’t complex (IMHO) but it is time consuming and frustrating when you find that it doesn’t work exactly as you want first time - but the results are well worth it.

 

i use iTrain, others use TC and those are the commercial options which both largely isolate you from the actual program logic. The major difference is that TC will ONLY run on MS Windows, iTrain will run on anything - even a Raspberry Pi  (I have ignored the price differential). They are both very capable programs and either one  should meet your needs though in slightly different ways

 

 

[melmerby]

There are ways of running Windows programs on  Mac, ( just as there are ways of running Mac programs on Windows), there are add on programs designed to do that.

 

[Tallpaul69]

Keith,

Not sure where Macs came into the discussion?

I run a windows 10 Dell laptop!

 

Cheers

Paul

[melmerby]

4 hours ago, Tallpaul69 said:

Keith,

Not sure where Macs came into the discussion?

I run a windows 10 Dell laptop!

 

Cheers

Paul

I was replying to the post from Iain mentioning that TrainController only runs on Windows.

It does, but plenty use Macs running Windows (Parallels etc.) to run TrainController, so computer type isn't a problem.

[DCB]

Lets face it you have too many variables to make this concept even vaguely achievable.  Adding DCC really kicks the concept into the weeds.   The moving up to fill vacant blocks is relatively easy to design in DC but the blocks and trains need to be of uniform length, otherwise the complexity becomes horrendous.  To be honest I would just provide a 6 or 8 volt supply to each block as soon as the block in advance became vacant.   But for DCC you need a computer to record which loco is in which block and move it when required which is ok but what happens if your system crashes or something gets out of sequence?

I have been here with a layout dependent on automation, a workable plan and a complexity and cost which proved prohibitive.  If you need automation try a vertical traverser or two, otherwise I find sometimes find operating the fiddle yard more interesting than the rest of the layout.

[WIMorrison]

8 hours ago, melmerby said:

I was replying to the post from Iain mentioning that TrainController only runs on Windows.

It does, but plenty use Macs running Windows (Parallels etc.) to run TrainController, so computer type isn't a problem.

Keith

 

it is true that there are a few ways to run MS Windows virtualised on a MAC however it is another layer of complexity that has defeated many people and also adds the cost of an additional licence for MS Windows nit to mention the issues and complexity of maintaining 2 operating systems.

 

Works well for some, but not the solution for the greater number of users who are not computer literate (which is most people)

[Harlequin]

Hi Paul,

 

It sounds like it is do-able but it would be simpler if the storage loops were redesigned so that you didn't have to do so much stacking. Or none at all if that were possible. I know that's difficult in the space available but it's worth thinking about it a bit.

 

Regarding trains being out of position (that is, not where the automatic timetable expects them to be): This is bound to happen and you'd expect the software to do something to help. To get trains positioned correctly is a bit like a sliding-block puzzle. Either the software should be able to solve the puzzle by itself (would need some very clever programming) or at the very least it should be able to give you a clear display of which things are out of position, and what the expected position is to help you resolve the puzzle yourself.

 

BTW: I hope these packages are smart enough to allow the temporary substitution of locos for those occasions when they have to be taken out of service for real or simulated overhauls.

 

[Tallpaul69]

3 hours ago, Harlequin said:

Hi Paul,

 

It sounds like it is do-able but it would be simpler if the storage loops were redesigned so that you didn't have to do so much stacking. Or none at all if that were possible. I know that's difficult in the space available but it's worth thinking about it a bit.

 

Regarding trains being out of position (that is, not where the automatic timetable expects them to be): This is bound to happen and you'd expect the software to do something to help. To get trains positioned correctly is a bit like a sliding-block puzzle. Either the software should be able to solve the puzzle by itself (would need some very clever programming) or at the very least it should be able to give you a clear display of which things are out of position, and what the expected position is to help you resolve the puzzle yourself.

 

BTW: I hope these packages are smart enough to allow the temporary substitution of locos for those occasions when they have to be taken out of service for real or simulated overhauls.

 

Phil,

as you will know from your much appreciated design efforts on my behalf, Lower Thames Valley has no room for additional storage loops!

Currently, hope to fit two 4/5 coach trains (or wagon equivalents) plus one short train (railcar, auto, or short freight, on each of the 7 loops (ignoring the branch through loop), so get 21 trains which if they are all reversed, makes 42 trains before a repeat.

 

Am encouraged by discussions of cheap cameras in a thread on the Modelling help section, so may go that way rather than the automation route!

 

Am currently playing with the timetable to fit it around the 42  train scheme, so hope to publish that soon, but better not commit to when, as other unexpected modelling problems particularly in loco chipping  such as Mazak rot, Lima motor replacement, tend to delay things!

 

Best regards

Paul