RR&Co, my control panel & the basics of automation

[melmerby]

Hi TTG thanks for the reply, but I don't quite follow what you mean by "One per track"

 

There are block detectors as shown either side of the junction. The junction is a simple double crossover, no slips, just 4 LH points and 2 diamonds.

Currently I am feeding undetected track power to the point stock rails and diamond "Ks" (six sets of feeds in all) with all frogs fed from microswitches on the relevant points. All stock rails/frogs are isolated from adjacent points/crossings/trackwork.

 

Where would I connect the RS8s outputs to?

 

Cheers

 

Keith

[RFS]

 

There are block detectors as shown either side of the junction. The junction is a simple double crossover, no slips, just 4 LH points and 2 diamonds.

Currently I am feeding undetected track power to the point stock rails and diamond "Ks" (six sets of feeds in all) with all frogs fed from microswitches on the relevant points. All stock rails/frogs are isolated from adjacent points/crossings/trackwork.

 

Keith

 

Keith - the feed to the point stock rails, diamonds and frogs needs to also come either via a spare port on an RS8 or using BY251 diodes as shown by LDT here, but not directly from the DCC bus.

 

Unmonitored track feeds

 

Otherwise you get problems with detection when wheels with pickups bridge the gap at the IRJs. You can get the BY251 diodes from Ebay - not the UK chancer who wants £1.89 each (!) but from the German supplier here, who sells packs of 25 for 3 Euros.

 

BY251 Diodes

[melmerby]

Keith - the feed to the point stock rails, diamonds and frogs needs to also come either via a spare port on an RS8 or using BY251 diodes as shown by LDT here, but not directly from the DCC bus.

 

Unmonitored track feeds

 

Otherwise you get problems with detection when wheels with pickups bridge the gap at the IRJs. You can get the BY251 diodes from Ebay - not the UK chancer who wants £1.89 each (!) but from the German supplier here, who sells packs of 25 for 3 Euros.

 

BY251 Diodes

 

The idea is to feed the junction from the RS8s so that they are detected, but exactly how, so that each of the different routes, 6 in all, are correctly monitored without obstructing any other route.

 

BTW I buy electronic components from places such as Rapid or Farnell where the prices are reasonable!

 

Keith

[RFS]

The idea is to feed the junction from the RS8s so that they are detected, but exactly how, so that each of the different routes, 6 in all, are correctly monitored without obstructing any other route.

 

BTW I buy electronic components from places such as Rapid or Farnell where the prices are reasonable!

 

Keith

 

I don't use detection for points and crossings which is what RR&Co recommend with Traincontroller. Given how many different routes there would be I can't see how it would be easily done. Points are included as parts of routes in schedules so TC works everything out for itself. My layout works very well with the points excluded, but powered from spare RS8 ports or diodes.

 

The only place I could find in the UK selling the BY251 diodes is Farnell but they have a £20 minimum order and I didn't need anything else.

[two tone green]

The reason for feeding point work via RS8 detectors, if you use them and not other detectors, is that you can have a whole train in some cases in point work and not in a block so TC looses tracking at times and releases points to be changed that can be under a train.

 

It also helps with signalling and interlocking as a loco could pass a signal but it wont go to red until it reaches the next block which could be a quite a way away if the pointwork is complex or long.

 

As for one per track, the track between blocks with points, in the diagram all you need is one detector per track from top to bottom, four in all. Allocate the detectors to the routes that they will be used in and TC will become far more safer as it can track the trains over all the routes. In this case, it is not particularly complex but physically it may be long, don't know as I cannot see the actual layout but I suspect it is long enough to hold a loco by itself.

 

Signalling will be easier as well and more realistic as it will reflect the correct aspect across all routes.

 

TTG

[RFS]

The reason for feeding point work via RS8 detectors, if you use them and not other detectors, is that you can have a whole train in some cases in point work and not in a block so TC looses tracking at times and releases points to be changed that can be under a train.

 

 

I've not seen TC lose track of trains in this situation (well not yet!). TC will lock the route between the starting block and the next block and hence also all pointwork between the two blocks. If the train goes "out of sight" whilst travelling to the next block the route still remains locked. I've just run a little test whereby I stopped a loco running a schedule on the pointwork between two reserved blocks when it wasn't being detected and took it off the rails. The route remained locked and no points on the route could be switched until the schedule was manually terminated.

 

As to signals I don't like the way they are set and reset as part of blocks. When a block signal is changed to green for a train standing in a platform the train moves off immediately, or even slightly before. Most unrealistic - the poor guard doesn't get a chance to blow his whistle . So I now don't define the signal to the block but stand-alone. It's set by an action on the route whereby the signal is set followed by a few seconds delay. Works fine as long as a route is always traversed in one direction only. The signal has to be set in the route as unlocked though. Resetting of the signal is done by a flagman activated by the train entering the block the signal is protecting so it changes back to red pretty soon after the loco has passed it. Again much more realistic - and the signal is reset even if I'm running trains manually.

[two tone green]

Don't use block signals to control real life signals, that's a big no no. As you have found out, it does not work as you want it to. The use of flagman or signal logic is the best way to go as you have done. RR&Co uses the block signals to control the trains and does not represent real life operation. Even Mr RR&CO admits this and says to use what he calls cosmetic real signals to represent what we see in real life. The signals that I put on the layout form part of the interlocking and never use the block signals.

 

As for track circuiting of routes, it is up to the users but in complex point work where you can have multiple routes used by multiple trains all at one, it really is very useful to have the extra protection and it does increase route availability and flexibility in operation.

 

On my old layout which had some very complex routes with lots of double slips, three way points etc in them, the extra track circuiting allowed the trains to run in a more prototypical way with them passing on the point work rather then being held up at signals. I found it very useful but it is not for all to use and can add considerably to the cost of adding the detectors. But for me and others who have used it it has added lots to the layout.

[melmerby]

Hi again TTG

 

 

Excuse my ignorance but:

 

Can it be arranged so that the diamond crossings, in my diagram (post #172) above, are sensed but do not lock out a route?

Your post #174, at 19:45 on 25th April seems to suggest no and a train progressing Down Main 5 to Down Main 4 will occupy all three sensors thus precluding a train going in the other direction from Up Main 4 to Up Main 5 as both the diamond crossings will already be shown as "occupied" and thus not available for for another route.

 

Or am I missing something?

 

Cheers

 

Keith

[two tone green]

You can by having separate detectors for the crossings. I do for my double slips so by allowing far more flexibility across all routes.

 

But it gets expensive in detectors.If you are wiring things up its best to isolate the crossing now so that if you do decide to go down the road of detectors for the crossings as well, you can easily install and wire them in.

[melmerby]

You can by having separate detectors for the crossings. I do for my double slips so by allowing far more flexibility across all routes.

 

But it gets expensive in detectors.If you are wiring things up its best to isolate the crossing now so that if you do decide to go down the road of detectors for the crossings as well, you can easily install and wire them in.

 

At present I have the frogs for the diamonds connected to the point frogs and both switched by a microswitch from the point feeds (one switch per point) so it looks like, to start with, I will have to put seperate feeds to the diamonds and extra switches so that the frogs on the diamonds can be switched from those feeds.

 

Keith

[RFS]

At present I have the frogs for the diamonds connected to the point frogs and both switched by a microswitch from the point feeds (one switch per point) so it looks like, to start with, I will have to put seperate feeds to the diamonds and extra switches so that the frogs on the diamonds can be switched from those feeds.

 

Keith

I have a similar situation to you involving a diamond crossing. When you set the route (as on your diagram) from Down Main 4 to Down Main 5 the two points will be set by TC, and in my case (as I believe in yours) the polarity switches on these points also set the polarity on the diamond crossing. The problem arises once the route is released and the next train travels from Block 14 to Up Main 4, ie taking the straight route over the diamond. TC does not reset the points so the polarity of the crossing frogs will be wrong and a short circuit will occur.

 

However it's easy to fix this with TC. In my case I've put an action on the route Down Main 4 to Down Main 5 such that when the route is released the points are reset to the straight position. This has resolved the issue.

[melmerby]

I have a similar situation to you involving a diamond crossing. When you set the route (as on your diagram) from Down Main 4 to Down Main 5 the two points will be set by TC, and in my case (as I believe in yours) the polarity switches on these points also set the polarity on the diamond crossing. The problem arises once the route is released and the next train travels from Block 14 to Up Main 4, ie taking the straight route over the diamond. TC does not reset the points so the polarity of the crossing frogs will be wrong and a short circuit will occur.

 

However it's easy to fix this with TC. In my case I've put an action on the route Down Main 4 to Down Main 5 such that when the route is released the points are reset to the straight position. This has resolved the issue.

 

That would tie up with prototype practice I believe. You would not be allowed to set a route straight through the crossing with the points still in the "turn" position as it would mean a possible conflict.

 

Keith

[alangr]

Hi all

 

I am about to display my ignorance as I must confess to not following the discussion about 'unmonitored track feeds'. I am using Lenz kit with many RS8 detectors but only for blocks. These were only added after much trackwork had been completed as I only came on to TC and its capabilities late in the day so 'additions' to completed work, and expense, were kept to a minimum by detecting blocks (of track) only. I am grateful to the reference to the LDT diagram (and have had a number of these from LDT in response to queries), but I don't follow why it is necessary to monitor as in diagram 1140.

 

I have only yet run with locos (no 'trains') and have always realised that I might have a problem when running a long train through a substantial pointwork as routes might be released as soon as the next block was reached (even using resistive wheelsets). But am I right in thinking that block release can be set to 'release whrn train enters two blocks ahead'? It seems to me that this would cover most problems.

 

And I am still not sure that this is related to unmonitored track feeds!

 

Alan

[RFS]

Hi all

 

I am about to display my ignorance as I must confess to not following the discussion about 'unmonitored track feeds'. I am using Lenz kit with many RS8 detectors but only for blocks. These were only added after much trackwork had been completed as I only came on to TC and its capabilities late in the day so 'additions' to completed work, and expense, were kept to a minimum by detecting blocks (of track) only. I am grateful to the reference to the LDT diagram (and have had a number of these from LDT in response to queries), but I don't follow why it is necessary to monitor as in diagram 1140.

 

I have only yet run with locos (no 'trains') and have always realised that I might have a problem when running a long train through a substantial pointwork as routes might be released as soon as the next block was reached (even using resistive wheelsets). But am I right in thinking that block release can be set to 'release whrn train enters two blocks ahead'? It seems to me that this would cover most problems.

 

And I am still not sure that this is related to unmonitored track feeds!

 

Alan

 

The problem will not result in blocks being released prematurely. What does happen is that when trains enter monitored blocks with their pickups still on unmonitored track the RS8 will not detect them until the whole loco is in the block. This can cause problems with stopping at the stop marker.

 

Try a simple test: find an occupied block connected to unmonitored turnouts. Now place another loco on the turnout so that its pickup wheels are bridging the gap between the block and the turnout. You should see the occupancy sensor go off.

 

I've tried with the 4 BY251 diodes as recommended but I've found trains slow through the points noticably, so I've reverted to using a spare port on the RS8s instead.

[melmerby]

 

 

I've tried with the 4 BY251 diodes as recommended but I've found trains slow through the points noticably, so I've reverted to using a spare port on the RS8s instead.

 

I don't see why that should happen as the current paths should be identical. Did you have the diodes wired "two up two down" in parallel, so to speak?

 

I didn't incidentally notice much if any difference going from a monitored (RS8) section to a direct fed section when testing what I had already done. The trains/locos were not going particularly fast though.

 

Keith

[RFS]

I don't see why that should happen as the current paths should be identical. Did you have the diodes wired "two up two down" in parallel, so to speak?

 

I didn't incidentally notice much if any difference going from a monitored (RS8) section to a direct fed section when testing what I had already done. The trains/locos were not going particularly fast though.

 

Keith

The BY251s were wired correctly which I checked a few times! I've just upgraded my 3-amp TR100 transformer to the 5-amp TR150 so I'll see what effect that has.

 

The problem I encountered was with parking my Bachmann 4-CEPs in the carriage sidings. Space is tight and there's only a couple of inches clearance so they need to stop pretty close to the buffers. With the units fully calibrated they stopped exactly where they should - 90% of the time. But every so often they would overrun by about a coach's length and demolish the buffers. I put an action on the block to have the PC beep when it was entered and noticed that sometimes this only came when the second coach entered - it gave me time to take action to protect the buffers! Now that all the pointwork feeds have been gathered together in a choc-bloc and fed from a spare port on the RS8 this problem has been fixed. When I did all the station approach pointwork too I noticed trains stopping shorter than before, and measurements showed they were now doing so in the right position.

[alangr]

Thanks for the explanation about the unmonitored track feeds. I have not noted any problems with travelling into a block from pointwork yet (tho' it's early days) but I certainly need to add a delay time (in TC) to the dropping of an occuancy to avoid the 'flicker' that is mentioned in the manual.

[two tone green]

Hi Alan,

 

Yes that delay is very important. Do it soon to avoid a host of problems.

[alangr]

Hi TTG

 

Yes, while I have had no problems that I am aware of, flickering is certainly something I have seen on the screen and have Mr F's comments about confusing the software very much in mind.

 

Do you have any views on the matter of 'block dropping' (see my earlier post on this thread)? For example, with three blocks where A and B are some way apart with pointwork in between and C follows not that far from B, can TC be set to release block A not when the train enters block B but when it enters block C (and if so is it wise to do so)? It seems to me that this would be likely to make the whole system less likely to have problems of collision over unmonitored pointwork.

 

I realise that this is really a RR&Co issue but it does arise from this thread.

[RFS]

The problem will not result in blocks being released prematurely. What does happen is that when trains enter monitored blocks with their pickups still on unmonitored track the RS8 will not detect them until the whole loco is in the block. This can cause problems with stopping at the stop marker.

 

Try a simple test: find an occupied block connected to unmonitored turnouts. Now place another loco on the turnout so that its pickup wheels are bridging the gap between the block and the turnout. You should see the occupancy sensor go off.

 

I've tried with the 4 BY251 diodes as recommended but I've found trains slow through the points noticably, so I've reverted to using a spare port on the RS8s instead.

 

I've just replaced my 3-amp TR100 transformer with the 5-amp TR150 version as I need more power for the trains I'm going to be running, plus allow for the stall current draw of the Tortoise point motors. I tried again with the 4 BY251 diodes and this time it worked just fine. I don't really know why that has changed things, but it works now and I'm happy.

[RFS]

Hi TTG

 

Yes, while I have had no problems that I am aware of, flickering is certainly something I have seen on the screen and have Mr F's comments about confusing the software very much in mind.

 

Do you have any views on the matter of 'block dropping' (see my earlier post on this thread)? For example, with three blocks where A and B are some way apart with pointwork in between and C follows not that far from B, can TC be set to release block A not when the train enters block B but when it enters block C (and if so is it wise to do so)? It seems to me that this would be likely to make the whole system less likely to have problems of collision over unmonitored pointwork.

 

I realise that this is really a RR&Co issue but it does arise from this thread.

 

Alan - I've been working only today in this very area so perhaps I could clarify a couple of things.

 

To prevent the "flickering indicator" problem it's recommended to set a delay in TC when a block comes free. You do this on the "memory" tab on the block editor. Set the value "Timer - beginning when turning off" to 2 seconds. This means that when TC gets told the block is now unoccupied it waits 2 seconds before actioning it. So if the sensor flickers back on again within 2 seconds, no action is taken by TC. Works fine for me.

 

As to releasing blocks, the default in schedules is to release a block when the stop marker is reached in the next. So a train travelling from block A to block B will not release block A (and hence all the turnouts in between) until it reaches the stop marker in block B. You just need to ensure your stop markers are set correctly, and that when a train reaches a stop marker, the whole of the train is in the block and not still overhanging the preceding pointwork.

[two tone green]

Hi Alan,

 

RFS is quite right in his explanation in setting 2 seconds as the delay to avoid flicker of the block occupancy detectors and avoid premature release of blocks and strange things happening with signals etc.

 

In effect with the 2 second delay, irrespective of flicking of the detector due to dirty wheels, uneven track etc the indicator wont change on the screen and as a result nothing will happen for 2 seconds after the block become unoccupied.

 

So without this, the flickering could result in a block being released and points changed or another train waiting for the block to move into it even if the block is still occupied. But even this is preventable by changing the settings in the schedule properties and selecting the right tick boxes in it.

 

As for using the block after next to release a block, well it gets a bit complicated to do this and you could well end up using flagman to do this or macros.

 

There are cases where you need small blocks, only as long as a loco in some cases and I found these useful in getting a train to stop under signals in the middle of point work. So you cannot get a whole train in a block in these cases and you can end up with a train spread over two blocks with lots of point work under it. The block the train is stopped in being only as long as the loco. so you don't want to release the block the train has just left and reached the brake marker in the subsequent block as it could allow other things to happen like I said above, points change and waiting trains enter occupied blocks.

 

This is another reason to use track circuiting in routes, point work to avoid this. Of course this is only applicable if you actually need it. Not every route and point needs it but like RFS has found, you can have odd things happen if track is powered straight off the DCC bus between two blocks powered from block occupancy detectors.

 

Have a look here and the class 40 stops in a block as long as the loco with the train straddling the crossings and spread over tow blocks. But the points under the train are locked due to track circuiting so cannot move. Gives you some idea of what happens

 

[two tone green]

This is the view looking from behind the trains what happens.

 

http://www.youtube.com/user/flyingbusman#p/u/10/3im-wv04zQI

[alangr]

Hi-been away for a while.

 

RFS: Thanks for your comments. I kindof knew about the block release and the stop marker in the next block but it is good to be clear! But I realise that I have been approaching the flickering in the wrong way - I have been setting the delay on occupation not that of release. I can see why I did this as I was looking at progress around the layout and so not considering the release situation. This I can change!

 

The real problem is likely to be long(ish)trains overhanging pointwork with the train in a shorter block. This led me to my query about block release. Clearly one approach would be to make the delay to avoid flicker several seconds but this does sound somewhat over the top.

 

TTG: The video and your explanation are very clear, thanks. My trouble is coming late to TC and although I have managed to undo much trackwork and install blocks, the pointwork is straight booster feeds in all cases. As a result I have to try and cope with trains 'overhanging' pointwork with no detection and hence my thoughts about the release of earlier blocks being dependent on a gap of not one but two blocks. I will have a think/play on the flagman issue and see what I can come up with.

 

Alan

[two tone green]

You could use a flagman triggered by the block the train enters to lock the route behind it until the train has fully left the block. In conditions put the schedule and the train that it applies to. That way a short train wont be affected but a long train is.

 

I cannot try this as I'm in the south of France and my RR&Co software is back in the UK but its worth a go and some experimentation.