DCC auto-progress fiddle yard

[96RAF]

Planning my next layout which will have a set of sidings (aka fiddle yard) to accommodate surplus stock.

 

What I want to do (and I basically know how to do the stop - shuffle up - go methodology in DC from running trams with an auto-bus-stop system) is to have a smilar DCC shuffle system for trains. I.e. they enter an auto-selected as and where available yard siding and shuffle up along that siding as and when the train ahead moves out, until they are called out on track again on roster.

 

Two problems essentially:

How to recognise the available free siding and change points to route an incoming train to that siding.

How to stop the train in its available siding slot and then shuffle it along as the train ahead moves out.

 

I presume RM Loco Detection is going to help me.

[2e0dtoeric]

Mk 1 eyeball? Maybe with the help of a cctv camera, if the fiddle yard isn't easily visible from the operating position.

Or optical switches driving an LED display, such that if a space is occupied, the LED illuminates.

But either way, you need some way of knowing the loco i/d, so you can tell it to move forward to the next parking space!

-

Another possibility is to leave dc enabled - then have the fiddle-yard dc powered, controlled again by the optical switches, then when a space is vacated, it 'tells' the next space back to send the loco in it forward, and you get the domino effect. The switch would need to be at the exit-end of each section, of course, or you could have the situation where train A hasn't left, before train B tries to move in!

[St1ngr4y]

@RAF96

 

Hi Rob,

 

I don't think this can be answered until we know a lot more about how Hornby LD will work. A lot of assumptions have been made on the Forum, based on the bits and pieces which have been incorporated into Railmaster, two or three years ago. PJ created a thread on the Railmaster Forum which lists the commands which were available at the time in Railmaster, and that post is still on display at the head of the Forum.

 

However, let me put forward a couple of initial thoughts...

 

1. I think this thread should have been posted in the Railmaster section because, as I understand it, the LD system needs to interface with Railmaster.

 

2. For LD to have any viability at all, it needs to be able to interface with the existing macro-programming feature already built-in to Railmaster. However, the very nature of the existing structure of Railmaster programs would make this extremely difficult, without re-designing the whole programming syntax currently in use.

 

Ray

[RB51]

At its most basic Rob I'd have thought you would need a sensor at each of the start and end positions of all the "parking" spaces in each siding. Ergo, for 3 spaces in a siding there would be four sensors.

 

I cannot see any reason why, although as Ray says we don't know the parameters of LD yet, one sensor could not handle both the "in" and  "out" events. Might be a bit expensive in terms of sensors though. R-

[96RAF]

Thanks for all the ideas.

 

I didn’t put it in RM initially as I wanted a basic DCC solution if possible.  This sort of thing is bread and butter to Rocrail and other software packages, so if it progressed to RM I could see the staging block shuffle events possibly being handled much like how signals will change aspect, only moving trains along a block on these signal events via sensors. The staging blocks being train length not extended track block length. Until we know more about RM LD then we can only guess the logic steps based on the commands list already published.

 

Generally block events are handled by 3 sensors to handle bi-directional movements (i.e Enter - In - Exit). Enter slows the loco, In stops it and shows the block occupied and Exit starts the loco and shows the block clear. A single sensor can be used but relies on the next sensor to be its partner, in that sensor 1 stops the loco and indicates the block is occupied (or not). Sensor 2 allows the loco to start if it is itself unoccupied - so on down the yard.

 

The DC method is totally reliable and proven - essentially there are gapped rail sections at each stop where an incoming vehicle first makes then breaks track continuity that starts the next vehicle and stops itself, but I don’t know how this could be applied to a series of DCC controlled vehicles.

Lets call the DC vehicles A, B and C with 3 bustops in a circle. A, B and C sit at stops 1, 2 and 3 respectively.

A leaves stop 1 and approaches stop 2 activating B which moves off. A stops.

B approaches stop 3 activating C which moves off. B stops.

C approaches stop 1 and stops.

End of one cycle.

This is a manually initiated single sequence, which almost equates to my requirement for staging blocks in the yard, but I need the shuffle up to take place in reverse order (i.e. C moves out of the yard onto the main leaving the slot clear for B which moves up out of the way of A leaving room for C to return) so there is always an empty block at the entry to the yard roads. This can be achieved using the same gapped rails method with manual switching set to initiate the departure and shuffle up sequence.

 

As stated how do you get DCC locos (with DC running enabled) to respond to simple sensor events. Not that I want DC running enabled due to previous runaway experiences. I feel there needs to be some other hardware to link back to the DCC controller, just relying on loco zero runaway methodology could be dodgy.

[St1ngr4y]

Hi Rob,

 

In your DC example, who or what is actually controlling the three vehicles A B C, when they automatically stop and start at the "bus stops" ?

 

Ray

[96RAF]

Ray

The ‘trams’ are DC controlled in the usual fashion for direction and speed. The basic shuffle up tests were done using the top wiring diagram in the link and 2 DC locos... 

http://www.gordonstrams.net/ATSpage3.htm

... also see the bottom video which shows the staging yard effect required but I need it in DCC.

The test setup is dead simple as I just used straight track lengths with missing rail joiners for the gaps and jump wires clipped to the rails, with a Go switch to initiate the DC shuffle.

[St1ngr4y]

... ok, so the user has a DC controller with a forward speed set to a reasonable speed for this area of the layout. If this was to be repeated for a DCC layout, and the user still wanted to be in control using a knob on either a Select or Elite, then three DCC loco addresses would need to be selected, commanded to go and stop etc etc. In my opinion this would be too difficult to be handled "manually" using a Select or Elite, and Railmaster (or equivalent software) would be required.

 

I've just had a look again at the commands available in a LD sensor icon in the Layout Designer. To me it looks like someone has had a try at guessing the requirements (both detection and consequent action) and put these into a dropdown list, but that's all it is. There won't be, I believe, any RM code behind each of these to do anything at present.

 

Ray

[96RAF]

I will have a dig around to see if there is maybe a diode matrix or simple sensing method available for DCC, but it looks like it will have to be RM LD as that will be the only,way to know which train is in which staging slot and hence when prompted to move them all along one in the queue.

The code will be there behind the drop down, it just won’t have anything to make react from it. Tap the command(s) into a simple program and see what the progress bar reports.

[St1ngr4y]

Here is a screenshot of the LD sensor configuration window in the layout design window....

 

/media/tinymce_upload/2fccd072f7f006af45b98f77c221b9a2.png

The bottom half is labelled "ACTIONS" and is divided into two columns, but neither column has a heading. The left column seems to have a dropdown list on each row of the column. The right hand column doesn't seem to have anything loaded into it. Now, I would suggest that the correct logic for one of these sensors should be based on actions to take depending on which loco has triggered that particular sensor. So the left column should contain a list of loco ids, and the right column should define the action(s) to be taken when the loco in the left column has triggered the sensor. In fact, one column for the actions might not be enough. It might require two columns for actions, one for the rsource, the other for the operation. For example, all of these entries might appear in the configuration of one sensor ...

Loco                                Resource         Operation

0004                                 Point 24            Switch right

0004                                 Signal 236        Clear

0006                                 Point 24            Switch left

0006                                 Signal 236        Single yellow

0007                                 Loco 0008         Forward to [20]

 

Ray

[96RAF]

I will look at my beta copy after lunch Ray to see if there is anything behind mine.

The Tram guy says his method would not work with DCC but Block Signalling guy says his DC M1 module using the same gapped rail logic but with a dual relay module to do the switching would work. Module works in conjunction with IR sensords.

[St1ngr4y]

@RAF96

 

Rob,

 

Based on the logic I proposed in my previous post, here is a possible solution to your example....

/media/tinymce_upload/f721e8304b9f6b74de1d9aa2060d109c.png

 

This simple example assumes a couple of things. First, that this is part of a loop, so a train exiting stage left will re-appear stage right, by which time the last (right hand) block of the siding will be clear. The locos are numbered 4 - 6 and the sensors are numbered 1 - 4. Sensor 1 is a block outside of the siding, and acts to flag that the first block is now clear. So the commands in each sensor could be like this....

 

Sensor 0001

Loco     Resource     Operation

0004     Loco 0005    Forward to [10]

0005     Loco 0006    Forward to [10]

0006     Loco 0004    Forward to [10]

 

Sensor 0002

Loco     Resource     Operation

0004     Loco 0004     Stop

0004     Loco 0005     Forward to [10]

0005     Loco 0005     Stop

0005     Loco 0006     Forward to [10]

0006     Loco 0006     Stop

0006     Loco 0004     Forward to [10]

 

Sensor 0003

Loco     Resource     Operation

0004     Loco 0004     Stop

0005     Loco 0005     Stop

0006     Loco 0006     Stop

 

Sensor 0004

Loco     Resource     Operation

0004     Loco 0004     Stop

0004     Loco 0005     Forward to [10]

0005     Loco 0005     Stop

0005     Loco 0006     Forward to [10]

0006     Loco 0006     Stop

0006     Loco 0004     Forward to [10]

 

I tried this out with 3 bits of paper numbered 4 5 and 6, on top of a print of the layout diagram, and I think it works ok. Of course, this is just hypothesis. It could be made even more sophisticated if there was yet another column in the configuration - column two could be a "Condition" for example "Signal 234 Clear" then do the operation, then another line underneath could be "Signal 234 Stop" then do a (different) operation.

 

Any comments welcome.

 

Ray

[RB51]

For my understanding Ray and for the sake of teasing it out, am I right in thinking that the "Condition" element is what indicates that a train can move forward?

 

Also, does not this solution pre-suppose that the trains always travel in a specific order?

 

R-

[St1ngr4y]

For my understanding Ray and for the sake of teasing it out, am I right in thinking that the "Condition" element is what indicates that a train can move forward?

 

Also, does not this solution pre-suppose that the trains always travel in a specific order?

 

R-

 

The condition could be made to determine whatever the user wants, including allowing the train to move forward, but equally it could be simply to determine whether the loco blows its whistle or not  😀

 

... and yes, this example was specifically designed to enable Rob's requirements to be achieved.

 

And just to be absolutely clear, these columns in the configuration of the sensor are only my suggestions, and may be completely different to what the RM designers had in mind.

 

Ray

[96RAF]

Ray

I havent got my head round the detection logic yet so the above confuses me already.

Is this right...

Sensor 1 when it sees loco 4 then resource loco 5 moves ahead at speed 10. Next reaction of loco 5 is when other sensors see it. Ditto other locos listed - the associated resource carries out the listed operation.

Sensor 2 when it sees a listed loco then it commands the resource to do the operation.

Sensors 3 and 4 ditto.

All the above happens upon detection not in the order listed.

Yes/No?

[RB51]

All the above happens upon detection not in the order listed.

 

That would be possible if the sensor reads back the detected loco ID to RM and RM moves it to the next position - or off onto the layout.

 

Absolutely hypothetical but interesting to discuss.

 

R-

[96RAF]

Nothing more in beta version Ray

/media/tinymce_upload/0383938cd8b69c8e225485527caa344b.PNG

Typical picks from drop down list of selections shown but no possible operations yet via drop down.

[St1ngr4y]

Rob,

I'll try to list the events in the order they should happen chronologically, assuming that the starting position is as shown - locos 4 5 and 6 stationery at sensors 2 3 and 4 respectively. To initiate everything, loco 4 should be started "manually", lets say at 10mph., then .....

 

0004 triggers sensor 0001, causing loco 0005 to go Forward to [10]

0005 triggers sensor 0002, causing itself to stop, and loco 0006 to go Forward to [10]

0006 triggers sensor 0003, causing itself to stop

0004 triggers sensor 0004, causing itself to stop, and loco 0005 to go Forward to [10]

0005 triggers sensor 0001, causing loco 0006 to go Forward to [10]

0006 triggers sensor 0002, causing itself to stop, and loco 0004 to go Forward to [10]

0004 triggers sensor 0003, causing itself to stop

0005 triggers sensor 0004, causing itself to stop, and loco 0006 to go Forward to [10]

0006 triggers sensor 0001, causing loco 0004 to go Forward to [10]

0004 triggers sensor 0002, causing itself to stop, and loco 0005 to go Forward to [10]

0005 triggers sensor 0003, causing itself to stop

0006 triggers sensor 0004, causing itself to stop, and loco 0004 to go Forward to [10]

 

...which is where we started.

 

Ray

[96RAF]

All the above happens upon detection not in the order listed.

 

That would be possible if the sensor reads back the detected loco ID to RM and RM moves it to the next position - or off onto the layout.

 

Absolutely hypothetical but interesting to discuss.

 

My understanding of Ray's listing is when SENSOR # sees LOCO # then it OPERATEs RESOURCE # as written - e.g when sensor 1 sees loco 4 it will operate loco 5 forward at speed 10. Await next sensor report.

 

As many sensors may be listening around the track several events could be happening in concert.

[RB51]

e.g when sensor 1 sees loco 4 it will operate loco 5 forward at speed 10. Await next sensor report.

 

I think I am on the same page here, but let me check. If LD knows that loco 5 is not behind loco 4 and ready to move up (but loco n is) RM could instead move loco n forward? R-

[St1ngr4y]

Rob,

 

Yes you seem to have the gist of what I'm saying.

 

R-

 

Rog,

 

LD doesn't know where the locos are in relation to each other - only the user, who configures the sensors accordingly - knows that relationship. As I said, this example was specifically for Rob's requirement to have 3 locos move up in turn in their shared siding, while one takes its turn around the loop. Incidentally, to have the loco which is out on the loop go at a faster speed, then all that needs to be done is change the speeds in sensor 0004, to, for example, Forward to Cruise or Forward to [40] or whatever.

 

Ray

[RB51]

Thanks Ray. R-

[96RAF]

Lot of water to go under the bridge yet as legal team are still faffing about so nothing will get build until I get a house to live in, but it pays to plan ahead and maybe setup some test tracks on the deck when the sun comes out.

If I thought LD wasn't coming very soon I would buy a couple of Block Sensing M1 modules to play with.

[Fishmanoz]

Has anyone checked that the drop-down list still matches the PJ list?  These commands were listed progressively in at least a couple of RM revisions and the current list replaced a less extensive previous list.  Also if you go back and look at the forum at the time, there is quite a lot of discussion on the logic of the commands.  That said, this discussion seems to me to be getting it correctly.

 

Let me emphasize the one simple and unbreakable logic of RM.  It never know where anything is, even under LD.  What LD adds that isn’t available now is that the system via the sensors makes detections of what LD ID is passing a sensor and in which direction.  But it is none the wiser on where anything is because it doesn’t know where the sensors are.  You must supply all the position information based on where you know the sensors are and where on what routes your locos and trains are running.  Then looking at the list of commands, you will see that can make a lot of conditional decisions based on a detection (what loco, locos or all locos and what direction and what signal/point state) and then action what to do with particular locos, signals or points, or to run a program.  Quite powerful but still without the system knowing where anything is (remember, your RM would operate exactly the same if all you had in your RM layout were all the points piled in one corner, all the signals and accessories piled in a second corner, and all the pieces of rail containing a sensor piled in a third, no connecting pieces of rail anywhere in sight.  You only add the interconnections for your convenience, not RM’s).

[St1ngr4y]

Here's a thought on how LD might be enhanced a little. Suppose they were to add a new trackpiece which can be used in place of an existing trackpiece, but which is configurable with an address. This wouldn't be a DCC address, as such, and the range of addresses for these trackpieces wouldn't conflict with any other DCC addresses. The idea of this would be for it to represent a "block". There would be a command available either in a program or as one of the commands within a LD sensor. When a sensor is triggered, a command within that sensor could copy the DCC address of the loco to this new trackpiece, thereby effectively flagging the block as occupied. The colour of the icon on the track diagram could be made to change at the same time to give the operator a visual indication of the occupied block. Elsewhere on the layout another sensor could be set to test the value of this block - if zero, block is vacant, if non-zero, block is occupied. When the train leaves that block, yet another sensor could change the value of the block back to zero. 

 

Ray