Post any questions arising from "First Steps with RR&Co"

thanks john

RR&co is like a jigsaw with a couple of pieces missing, it is a nightmare putting it together but once you find the missing piece everything slots into place.

Tip

i found this worked for me

after every session building the software up save it as a new doc ie. when you close  it down and click save as, date and time it. this way if you make a mistake and cannot find the fault revert back to the previous save.

it is easy to click a box by mistake and a lot harder to find it again. :oops:

 

Hi John, Thanks again for continuing with the tutorial. I have to confess that I did not follow the homework to the letter, but rather did more or less the same on my own layout diagram. Not having any real detectors yet, I am just using the automatically assigned diagram positions of column and row to identify detectors within blocks just now.

I now have the simulator working well - it will not work if you miss anything out - for example having a block without a detector assigned - it just stops and doesn't know what to do.

The indicator panel to the right of the brake in the Train Window is for signalling and resources. The upper red/green circle depicts the home signal state, and the lower one the distant signal state (I think only as predicted by the simulator) and they blink on and off as the simulator takes the engine from one block to another - if speeds are set low you can see that they tie up with the signal indicators at the exit of each block. The blue bar indicates amount of water on board if use of that resource has been set, and the black bar indicates amount of coal on board.

Looking forward to the next lesson.

Thanks again.

Have now created two engines, one steam and one diesel. It is fun watching them run under the simulator waiting for each other as their random routes cross each other. I discovered that I needed to add a fourth block in a circuit which had only 3 as if an engine got into that circuit, it always wanted all three blocks - the one it was in, the one it was moving into and the next one reserved. This meant that the other engine could never get across or into one of these blocks. Adding the fourth solved the problem, but I guess that there are other ways, if not, I may have to consider more blocks than I first thought?

Here is a shot of the despatcher screen showing the engines at work:-




You can see the signal indicators at work in the Train Windows. The upper window if for the steam engine, which is currently in the block near the centre of the screen travelling vertically up the screen. Its route is shown in yellow and the block it is about to enter, and the next, reserved, block are both shown with grey engines in them and are both accessible, so both home and distant signals are shown as green.

The lower window is for the diesel which is currently in the rather small block just to the upper left of the turntable, heading downwards towards the terminus. The block in the terminus is shown as reserved, but because it is the end of the line, its exit signal is red, so the home signal is shown green, but the distant shown red.

If one engine has set a route which blocks the other, then you see both signal indicators go to red, until the route is clear again.

You can perhaps see the resource indicators beginning to show drops in water, coal and oil (for the diesel). It is fun when they run out, as the engine just stays where it is regardless of the position of the throttle. The simulation has to be stopped and then the resource simulator used to "load" the necessary resources.

Just spent an hour or two forming actual, real blocks on a small part of my layout. In the screen shot of the despatcher window above, I have addressed the area which is formed by the reversing loop (near the bottom, centrally across the screen) and the single approach line together with the three departure lines or storage sidings. All of this area is under my main scenic level, but through experience from the first layout attempt, is easily accessible.

Breaking into the blocks shown has been fairly straightforward by unsoldering droppers for one side of the track and taking advantage of insulating joiners already on the various frogs. Looking at the three storage sidings (going vertically up the screen) the most sensible arrangement of blocks is for each to be contained by the point frogs at each end. However, the block which includes the reverse loop (which incidentally I found could be split into two blocks as it would hold 22 coaches!) naturally would include the fan of two points that feed the storage sidings. Similary the exit block from the storage sidings also naturally includes the fan of two points at the end of the storage sidings.

Up until now, in our tutorial and in the RR&Co manual, I had assumed that all pointwork would be permanently connected outside of adjacent blocks, but I cannot see anything logically wrong with the above arrangement. I would like to keep it that way as it simplifies the retrospective wiring connections, but is there something I am not seeing?

 

Phew! 89 blocks configured with 89 associated occupancy detectors - at least on the computer. Can I ever imagine wiring up this many detectors on the real thing??

Hi Geoff

Imagine modifying an old fashioned switch board as opposed to how easy it is here

Thanks for explaining the lights and resources on the throttle. I think I need to change a setting somewhere because the signals dont seem to work at all on my throttle with the simulator

To answer your questions

Block Conflict…………this can certainly be resolved with schedules ie you dont need to insert a fourth block. What mode are you running under?  As I understand it the problem is that when using the simulator and driving Loco 1 from Block A, across Block B to Block C…….if you try and drive Loco 2  across Block B even when it is clear (ie Loco 1 is safely in Block C) Loco 2 will not enter Block B? 

Points and Occupancy Detectors

[1] You know that TTG and I have agreed to disagree! There is a current thread on RR&co which strongly supports my view that occupancy detection of points/routes is not desirable.

[2] Points within blocks…….it is generally perceived that this is a no no. I would be inclined to do a search on RR&Co or actually post a query. Before I knew better I had included a single point in two of my blocks but they are sidings used for shunting and so far I have seen no adverse effects

I am less certain about having a fan of points within a block as busy as the exit/entry to storage yards. I think it could jeopardise the integrity train detection and I would worry about route confusion with schedules

Thats probably not what you wanted to hear…..I think I would ask RR&co

Kind Regards

 

   

Thanks for the answers, John. At this stage, I don't think that I will worry about isolating the two fans of points from the adjacent blocks but wait until I get things live and then see what happens. I can always get at these areas of track quite easily to cut them if it proves necessary, but don't want to make unnecessary cuts which may introduce running problems.
If I do have to cut them later, it won't mean extra blocks, just rewiring the feed to the pointwork track directly back to the appropriate bus.

I have been working out the simplest ways of forming the blocks on the parts of my layout already in place and also how I should isolate the blocks in the areas still to have track finally laid. At the same time, I have taken a look at what blocks I would implement first to give me something for RR&Co to run, leaving manually operable areas outside of its initial control.

It looks like this:-




Green blocks are those that I will implement initially. It will mean 7 LDT s88 detector units - but should be able to make 6 of these from the kits. Have a first one with an HSI88 interface on its way to me.

Red and Black arrows indicate rail gaps either already there through insulated joiners, or to be made in track not yet laid. There are a few blocks I will just have to do without to start with as they will require cuts to be made in existing scenic track and I don't want to do that until I am sure that the rest works and is worthwhile.

I have marked up the switchboard using PPT so as to avoid opening up RR&Co unnecessarily and therefore losing another of my 30 days worth of trial time. By the way, does the 30 day time period only affect the ability to save files as the licence suggests, or does it also limit operating days - I know operating time is limited to 15 mins on each occasion.

 

Geoff

the 30 day trial starts when you plug in the command station to RR&co (making it live with the layout). you can re start the software as many times as you like within the 30 days. after the 30 day trial you can do everything except connect to the layout. i made this mistake and connected it to a rolling road to play with the throttle.

one question on isolating sections

is it best to use isolated rail joiners at the end of each section or to lay the track and then cut the track to isolate it?

 

 

Thanks for the info on the 30 day timescale, Matt. I don't have a controller to plug it into at the moment, so I should be fine for now.

Your question about insulated rail joiners or cut track is a good one. I have now wired up my hidden storage area and reversing loop ready for the occupancy detectors. I have generally tried to make use of breaks already in place due to insulated joiners at frogs, but that was not sufficient for every break so I have had to cut rails as the track is already laid.

Electrically, of course, everything is fine both ways, but because in my storage area I have not glued the track down - just a few pins - there was a tendency for the track to misalign vertically either side of the new cut. I have sorted it with some packing and glue, but it was not a nice situation.

My conclusion is that I will use insulated joiners on all breaks when laying new track, and try to stick to existing ones at frogs for track already laid. Cutting only as a last resort.

Another advantage of using joiners is that the rails can never reconnect, whereas with a cut rail, it is possible either through expansion or the length of rail sliding in its sleepers, that the gap could reclose.

Cheers

In regard to occupancy detectors. Lenz package just 2 detectors in one unit, whereas others including ESU and LDT package 8 detectors in one unit. On the face of it, that makes sense to keep costs down. However, I have started to worry about signal integrity across the DCC feeds.

I had taken care to ensure that both sides of the DCC bus(es) were kept in close proximity, or even twisted, to reduce deterioration of the transmitted signals. As soon as you start routing 8 detector leads back to one unit, that neat running of buses goes away. The non detected rail being fed from the bus, but the detected rail being connected back to the other side of the DCC signal more in the style of individual spurs. There is no resemblance of the two sides being close together.

What is the experience of those who have had block detectors in place for a while? Do most use the 2 block Lenz unit anyway - I know that John does, or have some used these 8 way detectors on large layouts without any DCC signal problems?

I ask, because if it is necessary to scrap the bus and run twisted pairs to each section of track from the occupancy detector unit, I need to completely rethink my wiring strategy.

Thanks

Hi Geoff

I have to leave shortly (its 8.30 am here) so I plan to comment (if I may) on your blocks this evening

With Lenz you feed power into the detector using droppers from the bus and then feed power back to the block…..its optional whether you feed the common to the block from the bus or the detector…………I like to have my detectors at the front of the baseboard in clusters around the decoder so they are easily accessible so in some instances there is quite a long run from the bus and I havent always twisted them:oops:   But without discernible problems:lol:

There was a long thread on RMWeb about 3 months ago (maybe V3) about the pluses and minuses of twisted pairs……If I recall a surprising numbery didnt twist and reported no adverse effect

Hope this helps

Kind Regards

 

 

 

 

My God, I am so glad that my Newcastle Emlyn layout is DC and not DCC.

Because… I would just have to be into TC!!!!

Great tutorials John and discussion here all involved.

A very useful and exciting resource for when DCC comes to West Wales.

Keep it up.

Hi Geoff

The block layout looks very good and it is much easier to discuss now that each block is identified.

[1] I assume that where there is a block in the middle of a long stretch of line, say block 54 at the bottom, the block actually covers most of the line? I tend to extend my blocks to approximate to their length….. not very symmetrical I know 

[2] A block on the the line immediately below block 57 would be a good idea if you are contemplating any shunting in the terminus otherewise a schedule starting in block 51 or 52   has to go beyond the second fan of points to block 59 or 60 before you can get a destination block 

[3] Immediately above block 16 and 17 there is what looks like a loco stub or headshunt…..it may have some other purpose…..but if a loco is likely to go there I would recommend putting a block there……based on bitter experience!

[4] A few weeks ago I would have suggested second short loco stubs in blocks 53 and 54 but we now know how to get a second loco into a occupied block:lol:

[5] One of the problems with TC is that with the exception of [4] above you can only have one loco in a block so you are reduced to having almost the same amount of section isolation (and wiring) as DC. There is a thread on RR&Co which demonstrates a really elegant way of storing and identifying 4 (and could be more) locos in a long siding with only one detector….its well worth downloading the files……I am going to try and use it in my branch storage files.

I dont know whether any of this is useful but I assume you would like suggestions/comments

Kind Regards

 

 

 

 

[user=434]John Dew[/user] wrote:

[1] I assume that where there is a block in the middle of a long stretch of line, say block 54 at the bottom, the block actually covers most of the line? I tend to extend my blocks to approximate to their length….. not very symmetrical I know 

[2] A block on the the line immediately below block 57 would be a good idea if you are contemplating any shunting in the terminus otherewise a schedule starting in block 51 or 52   has to go beyond the second fan of points to block 59 or 60 before you can get a destination block 

[3] Immediately above block 16 and 17 there is what looks like a loco stub or headshunt…..it may have some other purpose…..but if a loco is likely to go there I would recommend putting a block there……based on bitter experience!

[4] A few weeks ago I would have suggested second short loco stubs in blocks 53 and 54 but we now know how to get a second loco into a occupied block:lol:

[5] One of the problems with TC is that with the exception of [4] above you can only have one loco in a block so you are reduced to having almost the same amount of section isolation (and wiring) as DC. There is a thread on RR&Co which demonstrates a really elegant way of storing and identifying 4 (and could be more) locos in a long siding with only one detector….its well worth downloading the files……I am going to try and use it in my branch storage files.

John, thank you for taking so much time to look at my block diagram. I really value your suggestions and comments. Taking them one at a time:-

[1] You are correct. I tended to go for what looked neat as opposed to properly representing the length of the block. Blocks 53 and 54 in particular go the full length of the associated platform lines.

[2] There is no gap in reality between the pointwork below block 57. The station approach is actually on an angle and with curves and the like, this whole area ends up much closer together than I can show in the Switchboard Window where I am restricted to trying to keep blocks horizontal or vertical. This picture will help you see. (Sorry it is inverted compared to the switchboard window)

 


This does illustrate my concern about putting detectors in long sections of pointwork, because your point (excuse the pun) is still correct. When I operate the layout, I run an engine around block 52 using blocks 50 and 51, but I do not go back anywhere near blocks 59 or 60. Instead, I stop the loco on top of the double slip as shown by the tank in the photo, before then returning to the train in block 52. Could TC do this without the slip being seen as its own block?

This photo also helps to show what I meant about including points either end of a block in that block. The simplest way for me to isolate Block 57 is to include the points at each end of it. (Just one each end). Looking at it, I cannot see what harm that would do as nothing can enter either of those points without entering the rest of block 57 anyway?

[4] Agree - funnily enough though, I did construct the terminus lines (blocks 53 and 54) with breaks at the ends for locos as I started this part under DC, so I could make them separate loco blocks still if the other method proves difficult.

[5] That is a clever idea and something I may have to consider at a later stage. Even though I have found it very interesting getting these diagrams completed, I have to start small in its implementation, just as I have with the layout itself. There are still large areas which are not much more than plain plywood, so I can see several years in front of me before I will have RR&Co running anything like the whole layout.

Thanks again

Another question has arisen for me whilst getting on with listing the accessory decoder addresses for some of the pointwork. In several cases I use one decoder output to drive two point motors - in one case by using wire in tube, I use one point motor to drive both the points on a crossover.

So the question is whether there is a way to tell TC this. I realise that I can just give both turnouts the same address, but I presume that TC will then hit the one decoder output twice as it tries to operate each motor? Been looking, but can't find the answer in the blurb provided.

Geoff

can you not give that point an obsolete address like 999, this way TC will try and throw 999 and nothing happens but when it throws the attached point that is attached to 999 both will be thrown? or am i barking up the wrong tree:oops:

Great Photo Geoff and now it is a lot clearer.

Running Around

I have a similar situation with points and was able to create a tiny, isolated, block betwee the toe of two sets of points. TC doesnt know the length of blocks (unless you tell it for max train length purposes) so you can have a stop marker for the head of the train outside the block to clear the xover point provided the rear of the train is still in the block. The key thing is to have a destination block. There is a bit of a work around using a macro at the end of a schedule where you can move a loco back and forth within a block but it can be cumbersome and is not as precise as using stop markers

I am still uncertain about blocks containing points….particularly at a busy throat….I look forward to hearing what happens
 but I think in the case of Block 57 where you just have the two bases (toes) in it will work ok


Point Motors

I think Matt's solution may work. A V 7 enhancement was allowing you to operate two motors from one address for double slips and the like (previously you needed two addresses) but thats not quite what you want. If you have two turnouts with the same address you will get error messages on Dr Railroad but I dont think it prevents operation so your solution may work also. Naturally you wont be able to run fully automatic schedules with wire in tube!

Kind Regards

 

 

 

Matt, John, thanks for the answers. The idea of a phantom address for one of the turnouts did occur to me as well while driving this afternoon. It may be necessary to set a condition so that the other turnout has to be changed by TC before attempting the phantom to ensure that it does not only try the phantom on occasion, because then nothing would happen.

The wire in tube is only used to connect a turnout to a motor. I find it very useful in confined spaces, and, as I said, I have even found that two points in a crossover formation can usefully be connected to a single motor with wire in tube. The motor is still connected to an accessory output, so full automation of the wire in tube is possible.

Cheers

YES!!  I have managed to get a few small black dots on my laptop screen to turn red when a loco enters various blocks of track!

Doesn't sound very amazing does it, but it is an exciting step for me towards potential computer control.

In deciding to go down the route of s88 for occupancy detection, I stumbled across a secondhand deal for one of LDTs occupancy detectors together with their PC interface for s88. I paid for them yesterday, and they arrived this morning.

I was busy this morning, so I had to wait to this afternoon to try them out. The interface was fairly old and required an RS232 serial COM port. Luckily I have a docking station for my laptop which has COM1 available. First problem was that I had some old software loaded which was using that port, so RR&Co was refused access. Realising what it was, I removed the said application, and the RR&Co was happy, and talked nicely to the LDT interface.

I had already taken the trouble to prepare 4 blocks ready for detection, so the next stage was to connect the occupancy detector to the PC interface. The instruction leaflet suggested testing it before connecting to the track. Sadly as soon as I set up an address on RR&Co for one of the blocks I was ready to connect, it showed occupied. It didn't matter what address I chose, it showed occupied. Unplugging the detector from the interface, returned the display to unoccupied.

*!*! I thought, serves me right for buying secondhand. I did a quick check and found a lack of supply voltage on the board - it should be fed from the PC interface module - checking that, it was giving out power, with nothing connected, so I concluded something on the board was pulling the power down. All I could do was write an email to my supplier to explore what we might do about it.

However, not to be outdone by what seemed such a trivial problem, and having had a good meal with a few glasses to wash it down, I decided to explore further. I found an age old problem - the detector board comes with an attached flying lead for the s88 bus - 6 wires with a crimped in-line connector on the end. The problem was that the ground lead was only crimped by its insulation, there was no electrical connection. Pulling it off, restripping and then inserting the copper strands into the side of the connector to make contact, and we had music!

There is no stopping me now. LDT supply these boards as kits. The circuit is actually very simple so shouldn't pose any problem for me. Even if I don't have a way of controlling trains yet, I am determined to get the layout connected up with block occupancy detectors fairly quickly.