Do these blocks make sense for TrainController?

[Carl]

Hi all,

 

I'm a little confused about the best way to organise my blocks for TrainController (I have TC Gold), I would appreciate it if someone could sanity check my plan.

 

Below is a track diagram, my layout is N.  I'm planning on each of the coloured areas being a block.  My traffic is going to be a mixture of DMUs and long passenger/freight (which could be upto ~8ft long.). The long trains will be using both the mainline and the branch (which is singled in part.)

 

 

Some DMUs will be stopping at Reddish South, and I envision them being able to wait for trains to clear the single track having left the mainline (waiting in the yellow block on the branch.)  I think the branch line is just about long enough to hold (at least some of) my freights without fouling Heaton Norris Junction or the entrance to the fiddle yard, and would like them to be able to stop on the branch travelling in either direction - but they definitely will be longer than the blocks I have on the branch.  Will that be a problem to setup?

 

I understand it's possible to stack short trains in a single long block and have them move up to make space at the entrance end of each road, and this is preferable to many, short blocks in the fiddle yard.  My longer trains (especially the freights) are about the length of the roads in the fiddle yard, and in most cases, they'd leave the fiddle yard, traverse the layout, and re-enter onto the same road without having to wait for trains to move up at threshold speed.  For DMUS, the other trains in that block will be moving up 1ft or less.

 

I don't really know the break down of long trains vs short I'll be running.  In some operating sessions, I might prefer longer trains and in some, shorter, and wouldn't want to reconfigure either TrainController or the layout to suit, so I'd have all of the fiddle yard set up to work like that.  Is my understanding of this "auto-move up" process correct?  I guess this is my real question for this thread.

 

Also, Is there any disadvantage to adding blocks to TrainController in the areas around the junction?  I will wire them up anyway, I have plenty of block detectors available (I'm using DR4088s, and have three of them) but I'm specifically asking about adding them in TrainController.  There is enough room for DMUs to stop in the four sections above the text "Slow-Fast-Fast-Slow" (which, when travelling anti-clockwise, might be useful if they have to wait for trains to move up in the fiddle yard), and there is quite a long section on the outer slow at the junction.  But usually, I think I wouldn't want trains to enter the junction area without being able to immediately clear it.  Can I set some blocks to be ignored by some types of trains?

 

(Edit: just noticed I haven't coloured the four short roads in the fiddle yard as blocked, but they should be.  They won't really be used for running trains regularly, just for holding trains awaiting setup or maintenance etc - they are next to my programming track.)

 

Thanks for reading,

Carl.

Edited January 31, 2021 by Carl

[jamespetts]

There is some ambiguity in your post (which is understandable given the complexity of the topic) which makes it difficult to give good advice without a little more information.

 

First of all, are you planning on full automation of the whole layout, semi-automation (e.g. automation of movements inside the fiddle yards only, or something else), or manual operation but with a computer interface instead of a control panel?

 

Secondly, do you mean "block" in the sense that TrainController uses this term or are you referring to a physical occupancy detector section? The two are not the same - one can have multiple occupancy detector sections in a single block and it is possible to have occupancy detector sections not linked to any block (e.g. on turnouts).

 

If you are planning on full computer automation, you need blocks on more or less every length of track that is not part of a turnout or closely connected set of turnouts. TrainController will need to know where trains are and signal/move them in accordance with blocks. If the only blocks that you are planning to have on the whole layout are those that are coloured, then you will not have enough for full automation.

 

In terms of the "move up" functionality, I suggest reading the manual relating to this in detail; it has some very specific limitations, the details of which I cannot entirely recall, but which are of some importance in planning.

 

One particular thing to bear in mind is this: if a given block in the fiddle yard encompasses all the track between a pair of turnouts, then, if any train is occupying any part of that block, the only way that the computer can tell that another train has entered the block is that it has left the preceding occupancy detection section. There are two issues with this: first of all, the farther away that the previous occupancy detection section is, the less accurate that the stopping point of the incoming train will be, so you are likely to need to have an occupancy detection section on the turnout itself (which will not be part of any block). Secondly, and more problematically, the DR4088 and other occupancy detection systems have a debounce feature meaning that there will always be a delay between the time that the train leaves a section and the time that the section is reported as unoccupied. This can be reduced in the configuration settings but cannot be removed entirely. This will also make the stopping point inside the block much less accurate. Accurate stopping is especially important for the move up feature. The solution to this is to split the block into multiple occupancy detection sections and in particular have a short section just after the turnout and before the part where all but the last train to fit in that section will stop so that you can control trains stopping in the block on the basis of detection of trains entering rather than exiting an occupancy detection section.

Edited January 31, 2021 by jamespetts

[Carl]

Hi James,

 

Thanks for that, especially the points about having some kind of detection immediately before each road in the fiddle yard - that's exactly the kind of consideration I was after.  Fortunately, I can easily do that.

 

In terms of your questions :

 

4 minutes ago, jamespetts said:

First of all, are you planning on full automation of the whole layout, semi-automation ..., or manual

 

I'm aiming for full automation ultimately, although I will want both other options too (which I guess falls out of being having full automation.)

 

8 minutes ago, jamespetts said:

Secondly, do you mean "block" in the sense that TrainController uses this term

 

Yeah, I do - I probably should have been a bit clearer with that, sorry.  Most of the blocks in my diagram will have multiple occupancy detectors due to baseboard boundaries etc.

 

29 minutes ago, jamespetts said:

In terms of the "move up" functionality, I suggest reading the manual relating to this in detail; it has some very specific limitations, the details of which I cannot entirely recall, but which are of some importance in planning.

 

I've read through this several times, but reading it again, it does explicitly say that the sensor which triggers the brake and stop must not be occupied by waiting trains, which I hadn't appreciated before your reply.  That actually forces me to have some detection immediately before each road in the fiddle yard, as the distance to the previous sensor varies depending on where the train has come from.

 

I am probably jumping the gun thinking about it given I've just started laying track and wiring it up, but I guess I am really checking that my goals are achievable.  I think your advice of "add occupancy detection everywhere you can" and "don't conflate blocks and occupancy detection" are two things that hadn't clicked for me.

 

Regards,

Carl.

[Andymsa]

1 hour ago, Carl said:

Hi James,

 

Thanks for that, especially the points about having some kind of detection immediately before each road in the fiddle yard - that's exactly the kind of consideration I was after.  Fortunately, I can easily do that.

 

In terms of your questions :

 

 

I'm aiming for full automation ultimately, although I will want both other options too (which I guess falls out of being having full automation.)

 

 

Yeah, I do - I probably should have been a bit clearer with that, sorry.  Most of the blocks in my diagram will have multiple occupancy detectors due to baseboard boundaries etc.

 

 

I've read through this several times, but reading it again, it does explicitly say that the sensor which triggers the brake and stop must not be occupied by waiting trains, which I hadn't appreciated before your reply.  That actually forces me to have some detection immediately before each road in the fiddle yard, as the distance to the previous sensor varies depending on where the train has come from.

 

I am probably jumping the gun thinking about it given I've just started laying track and wiring it up, but I guess I am really checking that my goals are achievable.  I think your advice of "add occupancy detection everywhere you can" and "don't conflate blocks and occupancy detection" are two things that hadn't clicked for me.

 

Regards,

Carl.

 

hi Carl,

 

looking at your reply to James regarding the move up function makes me wonder if you have grasped this function. I tried this function and as James says there are some limitations, I will report what I found when I experimented with it. The first train would enter ok and stop the next train just carried on at normal speed and ran into the first train sometimes, when I did get it to stop as expected when the first train left as the second train moved up it would run at the slowest speed setting IE crawl speed. Eventually I gave up using this function and divided the storage siding roads into multiple blocks, of course you will need to know approximately what length of trains you will be using but I do find sometimes that a very long train can occupy both blocks at the same time. My advice is avoid the move up function.

 

as to points needing detection TC doesn’t strictly need it, but I do it as a sort of safety interlocking. Before laying any track you need to know where your irjs need to be placed this wil save much heart ache at a later stage. If you require more info PM directly as I don’t want to get embroiled into differing views 

[5BarVT]

Hi Carl,

Another set of inputs coming.  I hadn't thought of the points that James made, but they are good points and I'm glad that they helped put things into place.  There's a lot to TC!  I haven't used the 'line up' function but I'm aware of others for whom it hasn't worked well, especially due to the crawl forwards as mentioned by Andy.  It will be possible to do something to emulate that as I know that people did with versions before the line up was available.

On to your initial question about TC Blocks.  You will be able to operate the layout with just those Blocks and I think full automation would work but with some limitations.  I'm a bit of a signalling purist (it's the day job for one more month) so I am fitting train detection everywhere on my layout.  However, my coaches and wagons don't have conducting axles yet so I will need to apply extra measures to maintain the route locking behind the train when long trains hang out of the back end of a block.  Although I haven't actually done that yet, I can see ways that it can be done in TCG.  (You would need that for freight on the Reddish branch if you don't have conducting wheelsets on your wagons.)

The latest form of TCG has the ability to input train (vehicle) lengths and can do calculations on them, so I'm sure that you could do something about rear end protection using that.  (A tip I have picked up is that if you have fixed formation trains, treat each 'set' of wagons as a single vehicle.)  Once you have added train lengths and given each Block a length I think there is a schedule rule that prevents the route releasing if the train is longer than the Block until it has fully entered the Block.  That should work for holding the junction whilst the train is running on to the branch, and likewise holding the locking for a long freight using the whole of the branch for standage.

Your question about short Blocks on the approach to H N Junction from the FY: Yes it can be done and there are ways to limit then to short MUs only.  One way is to have separate schedules for freight and MUs, you can make them critical in the freight schedule but not the MU schedule.  There will be other ways too.

If you are wanting to have trains running round continuously you may need to think carefully about whether you need another Block on the circuit.  The issue is that the train needs the next Block free to continue at speed, but if your route release doesn't happen until the stop marker is reached then the train will stop and start in each Block.  If you want the whole of the viaduct section to be one signalling block (i.e. only one train at a time) it can still be achieved.

 

 

This is the layout I am building: U1/2/3 are the roundy roundy part and I have three blocks so that the train runs at speed.  I have put a condition in the Route U1<->UD of U1 not reserved, U2 not reserved, U3 not occupied.  That means there is only ever one train at a time running round and a following train is held in UD until the first is on its way into the yard.  (U3 was originally 'free' too, but that meant that the first train had stop in the yard before the route released and second train follow.)  I hope that this gives you confidence that there will be ways to make your layout work as you want it to.

 

Back to signalling purist: some of your block colouring goes right up to the physical limits of the points - that will not be clear of trains on leaving the adjacent road.  Being a purist, I have kept my train detection limits back at the clearance point but it does add to wiring complication.  However TC can cope with this - you just make the stopping point in the block far enough back to be clear (with a tolerance for stopping position variation).  Both of these approaches will work, you just need to decide which is best for you. 

 

Hope this helps, and have fun!

Paul.

 

 

[Carl]

Thanks @5BarVT and @Andymsa.  I’ll reply when I get a few minutes to think about what you’ve written.  I’m sure I’ll PM you too Andy, your personal experience will be valuable, thanks for the offer.

 

Thanks again!

[Kubel82]

Guys,

This is my first post on here after Administrator sorting an RMWeb software glitch.

 

I have just downloaded TC Silver as the Gold version is too expensive for me.  I considered the Bronze version, but I was put off by the comparison charts which say that Silver (and Gold) will give 'accurate' stopping points, whereas Bronze will not?  But, reading your posts, it appears that even you can't guarantee an accurate stopping point without an additional detector, such as an IR one?

 

Keith

[jamespetts]

26 minutes ago, Kubel82 said:

Guys,

This is my first post on here after Administrator sorting an RMWeb software glitch.

 

I have just downloaded TC Silver as the Gold version is too expensive for me.  I considered the Bronze version, but I was put off by the comparison charts which say that Silver (and Gold) will give 'accurate' stopping points, whereas Bronze will not?  But, reading your posts, it appears that even you can't guarantee an accurate stopping point without an additional detector, such as an IR one?

 

Keith

 

It is possible to get accurate (as in circa +/- 1cm) stopping points using only occupancy detectors, but the trains must all be speed profiled fully to do this, and must use a good quality back-EMF decoder.

 

The closer that the occupancy detector section is to the desired stopping point, the greater will be the accuracy.

Edited February 15, 2021 by jamespetts

[RFS]

3 minutes ago, jamespetts said:

 

The closer that the occupancy detector section is to the desired stopping point, the greater will be the accuracy.

 

Don't understand what you mean by this. I use a single occupancy detector per block and have no problem with trains stopping accurately. I also have blocks with multiple brake and stop markers according to train groups, and all is managed just via the single detector. Trains have to be fully profiled and it's best to use good quality decoders that have accurate Back EMF. I use only Lenz and Zimo decoders.

[jamespetts]

1 minute ago, RFS said:

 

Don't understand what you mean by this. I use a single occupancy detector per block and have no problem with trains stopping accurately. I also have blocks with multiple brake and stop markers according to train groups, and all is managed just via the single detector. Trains have to be fully profiled and it's best to use good quality decoders that have accurate Back EMF. I use only Lenz and Zimo decoders.

 

What I mean is that the greater the distance between the point where the software detects the train entering a section and the point where it has to stop, the more potential for slight inaccuracies to be magnified. One source of inaccuracy that cannot easily be mitigated is the different performance of motors when warm from being run compared to being cold - not even back EMF compensates fully for this. It may well be that inaccuracies of even fairly long distances between the occupancy detection break and the stopping point are still low enough to be acceptable in many situations, but where an especially high level of accuracy is needed (e.g. when coupling a locomotive to waiting carriages/wagons automatically), it is preferable to have the stopping point as close as possible to the actual occupancy detection section break.

[RFS]

12 minutes ago, jamespetts said:

 

What I mean is that the greater the distance between the point where the software detects the train entering a section and the point where it has to stop, the more potential for slight inaccuracies to be magnified. One source of inaccuracy that cannot easily be mitigated is the different performance of motors when warm from being run compared to being cold - not even back EMF compensates fully for this. It may well be that inaccuracies of even fairly long distances between the occupancy detection break and the stopping point are still low enough to be acceptable in many situations, but where an especially high level of accuracy is needed (e.g. when coupling a locomotive to waiting carriages/wagons automatically), it is preferable to have the stopping point as close as possible to the actual occupancy detection section break.

 

I've not experienced any problems with stopping in long or short blocks and I've been running TC for many years now. Stop markers tend to be at the other end of the block from where the section break is most of the time.  A small variation of 1-2 inches is acceptable (and I allow for it), and is usually the result of cold/warm locos and also a result of locos becoming fully run in.

 

The one recommendation I've seen is to have all brake ramps of roughly equal size, and when profiling locos to also calculate the brake compensation with a similar size brake ramp. 

[Andymsa]

I think a point is being overlooked about speed profiling, when you speed profile in TC only acceleration is affected by speed profiling, the brake speed profile or deceleration is not affected by the profile. It is the brake ramp of the block that affects the deceleration, the only time the deceleration speed profile has an effect is during manual control using the on screen TC throttle. Also if there is a lot of TC activity taking place again delays are introduced, there is only one sure fire way to get accurate stopping and that is to use a second detector and even then at times this can be slightly inaccurate.

[5BarVT]

2 hours ago, Andymsa said:

I think a point is being overlooked about speed profiling, when you speed profile in TC only acceleration is affected by speed profiling, the brake speed profile or deceleration is not affected by the profile. It is the brake ramp of the block that affects the deceleration, the only time the deceleration speed profile has an effect is during manual control using the on screen TC throttle. Also if there is a lot of TC activity taking place again delays are introduced, there is only one sure fire way to get accurate stopping and that is to use a second detector and even then at times this can be slightly inaccurate.

Are you sure?

Speed profiling isn't about acceleration or deceleration, its about knowing how fast a loco (or train) is moving at any given speed step.  Agreed the deceleration profile is defined by the braking ramp, but accuracy of stop on any given ramp depends on accurate speed profiling.  Once the train has passed the physical marker ( spot detector or start of detection section), where the train is and where TC thinks it is is only consistent if the speed profiling is accurate.  (Its a similar problem on the big railway with Level 3 ETCS relying on tacho accuracy between balises, and our pway friends not moving balises without telling us!)  The greater the distance from marker to stop point the greater the accumulated errors and the less consistent the stopping position.

Yes acceleration is also affected, but it doesn't impact operation because it doesn't involve stopping positions.

N.B. 'Short distance moves' are not considered in the above analysis!

Paul.

 

[Andymsa]

58 minutes ago, 5BarVT said:

Are you sure?

Speed profiling isn't about acceleration or deceleration, its about knowing how fast a loco (or train) is moving at any given speed step.  Agreed the deceleration profile is defined by the braking ramp, but accuracy of stop on any given ramp depends on accurate speed profiling.  Once the train has passed the physical marker ( spot detector or start of detection section), where the train is and where TC thinks it is is only consistent if the speed profiling is accurate.  (Its a similar problem on the big railway with Level 3 ETCS relying on tacho accuracy between balises, and our pway friends not moving balises without telling us!)  The greater the distance from marker to stop point the greater the accumulated errors and the less consistent the stopping position.

Yes acceleration is also affected, but it doesn't impact operation because it doesn't involve stopping positions.

N.B. 'Short distance moves' are not considered in the above analysis!

Paul.

 

yes this is correct, looking back at the post I probably didn’t put it very well. The point I was trying to make was that speed profiling does not affect braking as the brake ramp controls this. I have noticed that if there is a short ramp then the loco may not have enough time to give a smooth stop and will abruptly stop, of course this is dependent on the speed of the train travelling through the block to the stop point.

[Kubel82]

Guys,

This is my first post on here after Administrator sorting an RMWeb software glitch.

 

I have just downloaded TC Silver as the Gold version is too expensive for me.  I considered the Bronze version, but I was put off by the comparison charts which say that Silver (and Gold) will give 'accurate' stopping points, whereas Bronze will not?  But, reading your posts, it appears that even you can't guarantee an accurate stopping point without an additional detector, such as an IR one?

 

Keith

[Kubel82]

Thanks for all your comments Guys.  It has been really informative.  This user community is invaluable.  

 

I am using Lenz by the way.  Anyone want to comment?    :-)

 

Keith

[RFS]

11 hours ago, Kubel82 said:

Thanks for all your comments Guys.  It has been really informative.  This user community is invaluable.  

 

I am using Lenz by the way.  Anyone want to comment?    :-)

 

Keith

 

I used Silver till a few years ago (I now use Gold) and did not have a problem with accurate stopping. It all depends really on how accurate you need to be: if you're stopping over an uncoupling ramp perhaps you need to be more accurate but I don't do this. My stop markers are set so that as long as trains stop within 1-2 inches all is fine. If any train is less accurate than that it usually means re-profiling or re-calculating the brake compensation. So I think you will be fine with a single detector per block with Silver.

 

I also use Lenz - a 5-amp LZV200 just for running the trains, and a LZV100 managing points (Tortoise), signals and detector feedback (LDT RS8s). Having 2 separate buses spreads the load.

 

I recently upgraded my PC as the one I was using was coming up for 10 years old and had started to show some errors. The upgrade was for an a simple Intel I3 processor with 8 Gb memory on a new motherboard. I did some basic checks on performance: with TC ramped up to run as many trains as possible, CPU utilization by TC never got above 10% so I don't see any performance issues.

Edited February 16, 2021 by RFS

[Kubel82]

Thanks RFS.         

 

I have another Lenz question if you can help.  The A&H Models website shows a video of an LS100 Point Decoder with Feedback, connected to a Fleischmann point motor.  Chris at A&H has fitted 2 jumper wires to the RM connectors on the LS100 and when he MANUALLY moves the point blades the + and - indications correctly change showing the blade has moved.  I am using Seep PM2 motors with LS100 Feedback Controllers.  My LH101 handset shows the 'Fe' symbols that Feedback is being received, and I have fitted the 2 jumper wires as Chris did.  Electrically, the point switches fine and changes the + and - indication, BUT when I manually move the point blades.  The + and - do not change and are now incorrect.   Can I fix this?    How does a Lenz LS100 measure Feedback?  (Coil resistance or...???)

 

Keith

[RFS]

1 hour ago, Kubel82 said:

Thanks RFS.         

 

I have another Lenz question if you can help.  The A&H Models website shows a video of an LS100 Point Decoder with Feedback, connected to a Fleischmann point motor.  Chris at A&H has fitted 2 jumper wires to the RM connectors on the LS100 and when he MANUALLY moves the point blades the + and - indications correctly change showing the blade has moved.  I am using Seep PM2 motors with LS100 Feedback Controllers.  My LH101 handset shows the 'Fe' symbols that Feedback is being received, and I have fitted the 2 jumper wires as Chris did.  Electrically, the point switches fine and changes the + and - indication, BUT when I manually move the point blades.  The + and - do not change and are now incorrect.   Can I fix this?    How does a Lenz LS100 measure Feedback?  (Coil resistance or...???)

 

Keith

 

Sorry can't really help you with that as I don't use feedback controllers for turnouts. I instead decided to use slow-motion motors (Tortoise) as these were by far the most reliable ones.  I control them using NCE Switch-8 accessory controllers. 

 

I did start out with Peco PL-10s with Lenz LS150s, but there were occasionally not reliable, plus every time TC sets a route it always fires all the points regardless of their current position. Of course this doesn't happen with slow-motion motors, which made operation much more pleasant when there were quite a few schedules running. 

[Kubel82]

Thanks once again for another gem about TC firing the points.  I am just looking at the MTB MP1 slow motion motor which is much smaller and cheaper than the Tortoise.  Have you tried them?

 

Keith

[RFS]

2 hours ago, Kubel82 said:

Thanks once again for another gem about TC firing the points.  I am just looking at the MTB MP1 slow motion motor which is much smaller and cheaper than the Tortoise.  Have you tried them?

 

Keith

 

No - I managed to fully stock up on Tortoises a few years ago before they became expensive!  There's more choice today now with servos etc. but I find the Tortoises ultra reliable which is what you need with TC, or any automation program really. 

[WIMorrison]

MTB MP1 are excellent, I now have 32 off them and would replace all the cobalt IP if it wasn't for the cost  or replacing working items :))

[KingEdwardII]

Keith,

 

I operate all the points on my layout with MTB MP1s - they are great. Very compact, easy to install with excellent adjustments if you don't line things up perfectly. Very reliable, low power and with a built-in switch that can handle frog power. I now drive them all from a touch screen using JMRI on a Raspberry Pi.

 

Yours, Mike.

[Kubel82]

Thanks for that MTB MP1 information guys.  I have just received and fitted one.  I took the drive apart to see if the small plastic pin was fitted in the 3mm N Gauge position.  It was fitted in the OO Gauge position so I needed to remove and fit it.  I thought "Now whatever you do, don't drop the pin on the carpet and.....PING. It shot out of the tweezers across the room.  I thought I will never find it again, but had a look anyway and.....It was sat there glowing red on my grey carpet!!   :-)  Phew.  I fitted the pin, reassembled and fitted the drive to the baseboard.  Interestingly, MTB do supply a spare pin with the drive, so I am probably not the first one to have dropped it. 

 

It was then an interesting exercise to read and decipher the Lenz manual for my LS100 feedback decoders to change the pulse time to 2 seconds, but I succeeded and It worked !!     Yay.     The motor drives beautifully with a real-world sound and pushes the blades hard against their stock rails.  Lovely.

So I just ordered 12 more for my main lines.  If/when I get Traincontroller, it doesn't matter if the Route selection fires the motors again because if they are already in the correct position, nothing will happen and nothing will be heard.

 

So all in all, thanks to you guys for steering me in the right direction with a perfect solution at the right price.   Keith