Train-Tech signals and set up in RailMaster

[PJ_model_trains]

Hang on in here RDS

It only seems complicated because there is so much we don't know. 

PJ

[St1ngr4y]

PJ,

I'm looking forward to seeing what loco detection brings, but I've said it before on the Forum, I think people will be very disappointed with what will be available.

In the real world, block occupancy is based on track circuits i.e. when a section of track has at least one pair of wheels and an axle on it, an electrical circuit is "made". The block is considered to be occupied while this electrical circuit exists. 

With any model railway, DCC or DC, I think I am right in saying that this technique cannot be used, hence the use of sensors placed around the layout at key positions. But the sensor in its very nature, only creates a signal for a brief instant in time, indicating that either a loco or the last vehcle of a train has passed over the sensor. The programming necessary to make use of this information to "protect" a block of track would, in my opinion, be immensely complex to cater for every possibility in the movement of trains around a layout.

Ray

[Fishmanoz]

Don't forget that Detection capability is already in RM. You can add detectors to your layout in track design and then see the programming possibilities they allow. The only problem is the hardware to actually do. Big problem I know, but you can still play around with what will be possible. 

[PJ_model_trains]

Hi Ray

We are stepping in to the crystal ball area again. Until the patent is through and the product produced and on sale we will not know more than we know now. A lot will depend not just on the sensor but, on the way the information is received then processed. 

I doubt if the sensor will work on movement as a train can stop, so does it then work on tags or reflective tags or bar  codes. Which ever I think, quote I am assuming, a tag will be fit to the underside of a train and underside of the last carriage, a code or address will be sent to RM and the software processes the information received. The important part will be keeping the sensors clean.

We have seen the amount of settings we can put into signals to change multiple signals and points, until we play I don't think we realise just how complex that area can get but, I am guessing Loco Detection will have similar controls we can set up and the train travelling codes sent back to RM will have priority over the settings put into signals and points.

A clever bit of kit no doubt but, it can be as easy or as complicated as we make it.  Although we appreciate we cannot know about the workings of Loco Detection yet, it would be nice to know if our thoughts are on the right track or not. As far as is practical at this time that is.

PJ

[PJ_model_trains]

Hi Ray

Have you managed to get a series of signals to work in RailMaster and on the layout?

I have 4@4  aspect signals in RM and they are all programmed at present to R/Y/YY/G in order backwards.

Which ever signal I change in RM all others follow the sequence set. (forget the red for train and last yellow for last carriage for now)

But on the layout it doesn't follow the sequence as it should. At present although I have 11 signals, I only have 2@4 aspect on the layout not , having said  that those two should light correctly but they don't.

I have today ordered another 2@4 aspect signals so that I can set all 4 up on the loop. With the 4@4 aspect set up correctly on the loop and in RM they will show if there is a bug in the system which at this minute is looking that way.

I just wondered if you have a series set and do they do what they should?

PJ

[idlemarvel]

You're right Ray, block occupancy detection is not the same as loco detection.  They both serve difference purposes, in my simple world.  You need block occupancy to provide the input for signalling.  You need loco detection to provide input for automation of loco movements.  Having said that, if your blocks are small enough then a loco detector could be used as a block occupancy detector if you have the detector in the middle of the block, except for light engines (no coaches or wagons).  BTW you can achieve block detection with DC or DCC, see this site for example:

http://www.blocksignalling.co.uk/index.php/block-occupancy-detector-bod1

If this is your interest there are other forums like on rmweb which cover this topic in detail.

[PJ_model_trains]

Hi idlemarvel

Block occupancy should still work with Loco Detection as the sensors define the block, the train entering the block signals red and the last carriage in the block leaves it Red and also changes previous signals down the line.

The red signal should stop any other train from entering the block (subject to speed)

If a steam train has say 3 carriages and that is in a block with space to spare that block is occupied. If I run a train with 6 carriages it will in effect occupy to blocks, as the train has passed the signals turning them red but the last carriage has only passed the sensor of the second block therefore only changing signals from that point back in order.

The way I have set my signals is wrong for actual working and for loco detection, the reason I have done the R/Y/YY/G test for all signals in the loops is to test RM and the signals on the layout to ensure it is doing what it should. I honestly don't think they are and think there is a bug. So it is better to have this sorted out now. Unfortunately I only have two 4 aspect signals and having experienced a problem today have purchased another two, which I will need any way so that I can test all 4 on the layout.

What problem am I experiencing?

I can get all signals in the loop to work in RM, each stepping back in the right colour order.

I have set up and tested signal 1 and signal 4 and they both work alright on their own

They do not work on the layout to match RM in every situation.  The list below shows the 4 signals stepping backwards through the sequence with the (signals not installed in brackets)

Signal 1 is Red RM&Layout (2 is yellow, 3 is double yellow) 4 is Green in RM & Red on the layout

Signal 1 is Yellow RM&Layout (2 is double yellow, 3 is green) 4 is Red in RM but is Green on the layout

Signal 1 is Dble Yellow RM&Layout (2 is Green, 3 is Red) 3 is Yellow RM&Layout which is correct

Signal 1 is Green RM&Layout (2 is Red, 3 is Yellow) 4 is Dble Yellow RM&Layout which is correct

The Red and the Green are wrong way on the 4th signal, reverse polarity is clear on all signal settings and all signals are clockwise around the loop.

Tomorrow I will be able to add signals 2 & 3 and set the address etc and test all signals in the loop for consistency between RM and Layout. Each signal installed and set up are individually tested to ensure they are working before comparing in the loop.

I welcome any comments, I will wait till the set of signals in the loop are all setup and tested before submitting it to HRMS.

PJ

[St1ngr4y]

Hi PJ,

I still have a help request being dealt with by HRMS at the moment. An earlier post of mine (the last item on page 4 of this thread) explains it.

Ray

[PJ_model_trains]

Hi Ray

As you say they are so close...

Yesterday I programmed a double 2 aspect, with only one learn switch I followed the instrudctions to the letter.

e.g set first address 80 and second address 75. I had problems with colour sequences.

Once I knew the way to set it up I started again and gave it a 3 number code, I think 120 & 125, you guessed it, it worked.

All of my signals, including those in the example submitted earlier are codes with 3 digits. First I tried 131,136,141,146  late I did it again as 102, 104, 106 & 108 it was the same with both.

Although I can see the red and green error with signal 1 & 4 in the example, it makes me wonder what 2 & 3 will show.

Hopefully the 2@4 aspect signals will arrive tomorrow, they have set off. Once I receive them I can install and set them up and check them. It will be interesting, and important I think, to be able to confirm if they work correctly or what errors show.

Your little test changing the colours was interesting, hopefully all this little things will help HRMS pin point the problems.

PJ

[Fishmanoz]

PJ, can I just go briefly back to loco detection and say that you seem to think it is a much bigger mystery than it actually is at the moment. To a certain extent it is like signals, or points, in that you are able to do a number of things when a detection occurs. We know exactly what these things are as they are already in RM and can be seen by putting a detector on your layout and going into its setup.  We can see that we can have universal actions take place and things that will only happen depending on what is detected (if/then/else actions). These have all been listed out by you in the old Loco Detection thread.

To me, the only thing we don't know is just how clever the detector will be. Obviously it will tell us that a particular tag relating to a particular loco has been detected. And to me the only other things it could possibly tell us are speed and/or direction at detection.  On that we'll have to wait and see. 

[St1ngr4y]

It doesn't need to tell us speed - RM and the controller should already know the speed of any particular loco at the moment of its detection.

Ray

[PJ_model_trains]

Hi Fishy

Thanks for the reminder of old Loco Detection discussions.

A detector in itself is not clever, all it does is detect and send a code to RM to process. RM is the clever bit as it processes all the messages received and sends a message for each to be carried out.

Regarding speed, I don't feel Loco Detection will tell us that. To calculate speed it would need more than one sensor, plus distance travelled etc. I would think we are left to drive out trains, the sensors send messages for RM to process to aid us to do it more efficiently, or take some of the manual controls away from us to automate them. e.g. Train passes red signal, last carriage passes change previous signals, etc.

I can see here the difference in our thinking. Speed is not down to loco detection to confirm it is for us to control, manually or using loco detection.

I may be wrong but, this is how I see it. A train or last carriage passes a sensor signals are controlled. RM is informed. I expect we can also say reduce speed to 50mph, or another speed we may choose.

Now this is where my additional sensor comments come in.

If you have 4 sensors, equally spaced, creating 4 blocks, your train is running at 65mph, it passes a sensor, among other requests we may choose to add, we request the train to reduce speed to say 50mph. You are relying on the train slowing down enough to stop if the next signal/sensor is stop. This slowing down distance is different for every train.

So you block sensors are in effect your master sensors but you would add additional sensors between the master ones, for other instructions and to control speed. For example train is told at the block sensor to reduce speed to 50mph, we may have for example two more sensors between the main block sensors. Train passes intermediate sensor 1 which assess' the situation. e.g. Next signal sensor is still red reduce speed to 30mph or next signal is now green go back to cruise speed say 65mph. Let's say intermediate sensor 1 requests reduce speed to 30mph as main block signal & sensor is still red. Train slows down and reassesses the situation at intermediate sensor 2, If next sensor, the main block sensor signal is red a command is given to reduce the speed to say 15mph, but if it is green or yellow we could say increase the speed to say 50 or 65mph. These intermediate sensors allow us to control speed and also stopping before the red signal. If not the train reaches the sensor to say stop and could over run into the next 'occupied' block.

Intermediate sensors can be used for other things also, they can be used for setting off various sounds, whistles, hoots, or maybe two hoots, you might have one that doesn't give two hoot.    ;o)

As I said in a previous comment, there are things we don't know and probably won't know till Loco Detection is available. Thank you for confirming this also... On that we'll have to wait and see. 

We are getting nearer now we have RM Pro and signalling but, here is another frustration, TO CONTROL SIGNALS AS THEY SHOULD BE CONTROLLED manually is not possible without Loco Detection. One train may be/almost, a train passes click signal to red, last carriage click previous signal yellow. As I said not possible as we may have to toggle through sequences to get to the colour signal we require. And all whilst the train is running on to another signal.

For those reading this and thinking signalling is to complicated, it isn't, for 2 aspect signals manual control is very easy, it is just that in our example currently being discussed we are using the more complex 4 aspect signals

PJ 

[PJ_model_trains]

Hi Ray

Just read your message, I agree. 

As I see it, Loco Detection doesn't take control away from us, it gives us another tool to help us control things better or easier.

After all our chats Ray, I have only just realised your user name is stingray

Today is another 'Train-ing' day.  Or just another day at the office.   ;o)    Enjoy!

PJ

[PJ_model_trains]

HRMS  --- 4 x 4 Aspect signals Errors confirmed

I have set 4 x 4 Aspect signals in a loop, I have given each 16 commands to control the sequence R / Y / YY / G backwards down the line. 

I am aware of signal procedure with the trains and carriages the object of this is to help HRMS find and fix the sequence problems.

Signal-1 Track signals order of each preceeding signal colours

R  Y  YY R     Y  YY R  G     YY R  G  Y     G  G  Y  YY

Signal-1 as seen in RM

R   Y  YY G    Y  YY G  R     YY G  R  Y     G  R  Y  YY

Signal-2 Track signal order 

R  Y  YY R     Y  YY R  G     YY R  G  Y     G  G  Y  YY

Signal-2 as seen in RM

R  Y  YY G     Y  YY G  R     YY G  R  Y     G  R  Y  YY

Signal-3 Track signal order

R  Y  YY R     Y  YY R  G     YY R  G  Y     G  G  Y  YY

Signal-3 as seen in RM

R  Y  YY G     Y YY G  R     YY G  R  Y    G  R  Y  YY

Signal-4 Track signal order

R  Y  YY R     Y  YY Y  R     YY R  G  Y     G  G  Y  YY

Signal-4 as seen in RM

R  Y  YY G     Y  YY G  R     YY G  R  Y     G  R  Y  YY

From the above you can see the signals in RM are correct R Y YY G but when passing the instruction to the signal is correct for some and not others, mainly red or green incorrect.

Each signal has been individually programmed correctly and when controlled on it's own 

follows the correct pattern R  Y  YY  G.

Hopefully this will help find the problem.

PJ

[St1ngr4y]

Hi PJ,

While waiting for the solution to the Traintech signal problem (which I think you have confirmed in your detailed post above), I have been trying out something else which I hadn't intended to use viz. setting other points when switching one point. 

At one end of my layout I have 8 'hidden' sidings, and at each end of these the tracks merge together into one track. So, entering the 'complex' there is the first point A. On each of its branches there is another point, lets call them B & C. These in turn have a point of each branch, D & E, and F & G. These then give the final 8 tracks, and there is a similar configuration at the other end to bring them all back together.

It occurred to me that, for each track, three points need to be changed at one end, and three more at the other end. If points D E F & G were configured to operate the other points, then one click of the red/green button on any of these would trigger all three at one end of the sidings, or if I wanted to I could configure them to do the necessary changes at the other end as well.

So I tried it out on the D E F G points at one end of the sidings, and they all worked fine when operated by clicking the red/green buttons on the layout diagram. I thought, this is great, all of my programs which bring trains in and out of these sidings can be shortened because they only need one command to change the necessary points instead of three. To my dismay, I found that when, for example, point D is switched in a program, only that point switched, the other two didn't. Now I think this is a bug which should be reported. I don't think you use programs yet, do you? I wonder if anyone else has come across this. 

Ray

[HornbyRailMasterSupport]

This is not a bug.  This is by design.

Programs give you complete control over points and signals and there are times when you don't want to have relays switching, which is why the program addresses only the point in question.  Similarly, only within programs can you specify directly a multi-aspect signal setting, whereas on the track plan you have to cycle through them by touching them (although there will be a helpful facility in the next update to set red directly).

We can look at ways of extending the point firing in program to include or exclude switching other points/signals but we cannot force that at this time.  Much safer to switch only the point in question.

[St1ngr4y]

OK, HRMS, thanks for the information.

Ray

[PJ_model_trains]

Hello Ray

You are correct, I haven't touched programs yet. 

At present I am systematically working my way through other things, namely signals.

We need to know signalling is working correctly to have 'confidence' to delve deeper. I hate to move on, especially when things are of a complex nature without a fix to the initial issue. Don't get me wrong, I am playing with setting points but don't have confidence in programming signals to set points when signals are not yet working correctly. One problem can hide another and come to light when the first problem is fixed.

Setting points is powerful, as you have demonstrated Ray but it only works in some situations and not all, something's will work for some layouts but not for all. I tried this earlier, altering a point that goes to three different platforms, points 1 & 2 can be controlled for both but point three branches into platform 1 & 2. Point 1 can change but point 2 and 4 are different although 2 & 4 can be programmed in a program.  If you get my point  ;o)

I guess it is similar with signals, I can program 4 signals to work together for Y, YY, G but if I have a branch coming into a loop a red light on the main line and green or yellow to branch to the main line may be all that is needed. Having said that the red on the mainline has already changed the order of the signals on the main loop, but red is the most important colour to program.

I must get to a point I can play with programming but, think HRMS will find the bug in the light sequences soon. We are working out our loops Ray, but their heads must be almost spinning at times following program data loop after loop in search of the problem.

PJ

[PJ_model_trains]

Thank you HRMS

We look forward to the fix in sigalling and the helpful facility for the red button in the next update.

Keep up the good work, we are grateful.

PJ

[PJ_model_trains]

Just an update guys

HRMS have very kindly emailed me to confirm they are working on this issue, they confirm...

There is quite a bit to look at here and we will need a little while to investigate.

It is very good of them to keep us updated like this, first class service I think

PJ

[St1ngr4y]

Earlier in this thread, I mentioned that I had reported a problem to HRMS through the help system, which concerned other signals changing when two other signals were operated from within a program. The signals are TrainTech 4-aspect signals of which I have six, numbered 109, 111, 113, 115, 117, and 119.

The initial reply I received from HRMS suggested that these signals may require more than two addresses, so they suggested renumbering them with at least 5 between each address. In reply to this I pointed out that I have dozens of Railmaster programs which reference these signals by the addresses above. To this they replied by telling me to hold off the renumbering while they looked at the RM programming side. This was on 21st September.

I have just sent the following reply to that email...

"I had some spare time today, so I decided to renumber my six Traintech 4-aspect signals. Until today, their addresses were 109, 111, 113, 115, 117 & 119. I decided to renumber them as 200, 210, 220, 230, 300 and 310 (although not one-to-one with the list of original addresses).

I re-programmed all six using the "learn" technique. On the layout diagram, instead of amending the existing signals, I simply moved these to a corner of the diagram, and I inserted and configured six new signals with the addresses shown. No routes or "other point/signal" parameters were used.

All six of the new signal icons work brilliantly, the signal steps through the change sequence correctly, and the layout icon reflects the actual aspect being shown by the signal.

HOWEVER, when the signals are operated from within a program, three of them work fine, but the other three have the same problem. Whenever a program tries to switch one of these signals to yellow, double yellow or green, the signal changes briefly to that aspect, but then immediately back to red."

Has anyone seen anything like this? I have asked HRMS if they would like me to re-report this through the help system. Hopefully, it might help them to sort things out.

Ray

[PJ_model_trains]

I Ray

See PM on RM

PJ

[St1ngr4y]

Hi PJ,

I give in - can you explain this message please ? :-)

Ray

[PJ_model_trains]

Hi Ray

You give in to easy  ;o)  Just joking

I have sent you a personal message (PM) in RMWeb (RM) something I wanted to discuss but not on the forum. Most forums allow this, Hornby's doesn't.  

Go to your account on the RM Web forum and click on the envelope, top right, near where you sign in and out.  You can reply to me the same way, feel free to do so anytime.

PJ

[St1ngr4y]

Have done

Ray