Train-Tech signals and set up in RailMaster

[Fishmanoz]

Let me cover a few points:

 

trainlover, I beg to differ, not drivel at all.  Also largely not speculation leading to its being drivel, but based on known capabilities of RM and LD.  That's not to say it should be of interest to you, you decide that.

 

john, some basics on published info about BlueRail, which we'll abbreviate to BR. First, DCC is a system whereby train control info is sent down the tracks to decoders in locos which decide, based on the signals, what each train should do, using the power sent down the tracks to do so.  BR is very similar except the train control signals are sent via Bluetooth (a sort of short range wifi) to decoders in the locos.  The locos still get their power from the track and it could be DC, DCC and probably AC.  If the power is DCC, you could run BR and DCC locos independently on the same track, but not DC or AC with BR.

 

There is also an Implication in the BR info that you can run programs like you can in RM, but no detail. There is no suggestion that BR will include LD.  So BR is an alternative to DCC, possibly RM in the longer term but not LD at this stage.  So if you are running DC, you could upgrade to BR by adding point clips and putting BR decoders in your locos and on your points etc.  You don't have to buy a controller, just use an app on your phone or tablet.  If you already have DCC, I see no point in swapping to BR but you could swap some locos and run both systems together.

 

Now back to RM and LD.  This combination is just what it says it is - a programmable DCC system that can tell when your locos pass sensors - not a block control system.  But you can write block control programs for it.  To what extent these can emulate fully real train operation is yet to be determined.

 

PJ, let's  just look at one aspect of your 4 aspect signalling as just discussed.  You say that, when a tender passes a signal, no action will be taken if there are carriages behind it, but if the loco is on its own with its tender, the tender passing will trigger actions resulting from the block having now been cleared. The problem here is that, at that detector, it will not know if carriages are coming or not given the way you have described your system.  Ray has suggested it would need  to read a variable which I'll call carriage/no carriage to find out.  But then you'd have to write that variable elsewhere in the system and store it so the detector program can read it. You won't be able to put it in the programming for the detector itself as you can't easily go around changing this in the detector setup in layout design.  

 

You can do it another way though but it will cost you another tag.  The extra tag would be in the lead carriage.  Now the tender can always be allowed to notify the block is clear but immediately the lead carriage tag will countermand that and put it back to occupied.

 

But I still can't see how you can control things when you have 2 trains in the same 4 blocks. You say red will always have priority but trains leaving blocks have to be able to clear red to Y.  But if the signal is set to red by train 2, then train 1 within 4 blocks in front of it can issue a clear prematurely and I can't see how you are going to stop it, At least not just with detector programming.  

[PJ_model_trains]

stingr4y, Hi ray, happy new year. I can find nothing on any post or from Hornby that ever said that LR, would cater for, or be able to be a  block Signalling system, and surely RM, would have to be a much more state of the art. product, to even conteplate such a thing, particularly bearing in mind the comparative costs of other sytems. If thats right, then in no way, will its inception, bear any comparison, to a real life Railway. Is that how you understand it, and if so its release, whenever, is going to come as a massive disappointment,to any of us who saw it as  a revolutionary step. if you look at Blue train/rail, for example wont that do, exactly, what you want to do.  it occurs to me that whichever  scheme is launched first, is going to grab a lot of  business, but neither will bring to the table, a satisfactory result, in the short term. john

 

Hello John

 

See my previous message. We are not creating block occupancy with LD, it is not designed that way.

 

But 'what we are doing is in effect creating a block' between two signals/sensors. These are two different things.

 

It could be a disappointment John you are right but, until we know what it will do and understand the concept we will not know.

 

PJ

[PJ_model_trains]

PJ, let's  just look at one aspect of your 4 aspect signalling as just discussed.  You say that, when a tender passes a signal, no action will be taken if there are carriages behind it, but if the loco is on its own with its tender, the tender passing will trigger actions resulting from the block having now been cleared. The problem here is that, at that detector, it will not know if carriages are coming or not given the way you have described your system.  Ray has suggested it would need  to read a variable which I'll call carriage/no carriage to find out.  But then you'd have to write that variable elsewhere in the system and store it so the detector program can read it. You won't be able to put it in the programming for the detector itself as you can't easily go around changing this in the detector setup in layout design.  

 

 My thoughts...

Train A passes over LD sensor say ID1030, the tag near the front of the train is read by the sensor say TAG#1005 and information sent to the LD controller and back to RM. RM processed that command and turns Signal #30 to Red. The train at this stage is only front end past the signal so the back half is still protected by a red signal at the previous signal, thus protecting that block and the front end as moved in to the next block hence the request for the Red signal to protect the block it is moving in to.

 Lets say train A has two tags, one at the front of the engine and one at the tender, the one on the tender could be TAG1006 as it goes over the sensor the tag is read, that  data goes back as mentioned above to LD and then RM for processing. RM looks at TAG1006 there are no instructions for this tag so it carries on it's journey.  This is how I think it will work because there are going to be lots or trains and lots of carriages passing over sensors, some will have commands relating to them, some will relate to others and have no interest to that train or it's carraiges. All that happens is the system knows train A, passed over Sensor ID1030 and told LD to tell RM that TAG#1005 has passed over it. Rm will them relay the commands programmed that relate to to that sequence of codes. If nothing relates it will not send a command.

 

You can do it another way though but it will cost you another tag.  The extra tag would be in the lead carriage.  Now the tender can always be allowed to notify the block is clear but immediately the lead carriage tag will countermand that and put it back to occupied.

 

Another tag would therefore not be needed

 

But I still can't see how you can control things when you have 2 trains in the same 4 blocks. You say red will always have priority but trains leaving blocks have to be able to clear red to Y.  But if the signal is set to red by train 2, then train 1 within 4 blocks in front of it can issue a clear prematurely and I can't see how you are going to stop it, At least not just with detector programming.  

 

You can have more trains on the track providing the blocks (gaps between signals sensors) is vacant.  The signals themselves say that by there aspect, Y proceed with extra caution, YY proceed with caution, G clear to continue.

 

The problem is, as I see it, will LD be able to cope with priorities for example, it is alright to set Y, YY or G for previous blocks but not if a Red has been brought up by another train on the track further back. We are back to IF, THEN, ELSE when the software  is requesting the signal change If signal number ###  is Red then do nothing else Y, YY, G as applicable 

Replies in bold in your message Fishy

[Fishmanoz]

Let me just concentrate on the tender with or without carriages problem for now PJ.

 

Remember again, all of your LD programming is written into the setup for each detector. And once programmed, it can't be changed on the fly as it is done in layout design mode.  We know it can do things to everything that passes, to a class of locos as they pass or to an individual loco.  We know it can do if then else commands.  Some moons ago, you even listed all of the possible programming commands, but that got lost in duplicated threads when the forum was updated.  But the info is still there in the detector setup window.

 

Now back to a tender passing a tag: you say it may do nothing and that because it has carriages behind it.  If there are no carriages though, you want the tag to signal the block is now clear (yes I know it doesn't say the block is clear, it just says I saw the tender just now going this way at this speed, you program that to have the consequences of the block being clear).  The problem is how does it know if carriages are coming or not.  Answer me that and we can go on.

[PJ_model_trains]

Let me just concentrate on the tender with or without carriages problem for now PJ.

 

Remember again, all of your LD programming is written into the setup for each detector. And once programmed, it can't be changed on the fly as it is done in layout design mode.  We know it can do things to everything that passes, to a class of locos as they pass or to an individual loco.  We know it can do if then else commands.  Some moons ago, you even listed all of the possible programming commands, but that got lost in duplicated threads when the forum was updated.  But the info is still there in the detector setup window.

 

Now back to a tender passing a tag: you say it may do nothing and that because it has carriages behind it.  If there are no carriages though, you want the tag to signal the block is now clear (yes I know it doesn't say the block is clear, it just says I saw the tender just now going this way at this speed, you program that to have the consequences of the block being clear).  The problem is how does it know if carriages are coming or not.  Answer me that and we can go on.

 

Hi Fishy

As my message in LD, just seen this, will reply later

PJ

[PJ_model_trains]

Let me just concentrate on the tender with or without carriages problem for now PJ.

 

Remember again, all of your LD programming is written into the setup for each detector. And once programmed, it can't be changed on the fly as it is done in layout design mode.  We know it can do things to everything that passes, to a class of locos as they pass or to an individual loco.  We know it can do if then else commands.  Some moons ago, you even listed all of the possible programming commands, but that got lost in duplicated threads when the forum was updated.  But the info is still there in the detector setup window.

 

Now back to a tender passing a tag: you say it may do nothing and that because it has carriages behind it.  If there are no carriages though, you want the tag to signal the block is now clear (yes I know it doesn't say the block is clear, it just says I saw the tender just now going this way at this speed, you program that to have the consequences of the block being clear).  The problem is how does it know if carriages are coming or not.  Answer me that and we can go on.

Here are the LD commands, I will reply to your comments shortly

 

For reference

 

Some new commands were added and this was the revised list of LD commands....

 

Hornby have picked up on the comments made earlier regarding signal options and have included more Loco Detection commands

 

The NEW list of commands is now.....

 

On signal green

On signal red

On signal yellow

On signal double yellow

On signal Flash Yellow

On signal Flash double

On signal Flash Green

For loco(s)

For train types(s)

For forward direction

For reverse direction

For any direction

Stop loco

Stop loco on signal

Resume loco on signal

Reduce loco speed to

Increase loco speed to

Set to cruise speed

Switch right point

Switch left point

Set clear signal

Set danger signal

Activate loco function

Play sound file

Run program file

 

I do think there should be commands for

 

Set proceed caution

Set proceed extra caution

 

Red and Green (bold) is include above but not Y proceed with caution or YY proceed with extra caution

 

PJ

[PJ_model_trains]

Let me just concentrate on the tender with or without carriages problem for now PJ.

 

Remember again, all of your LD programming is written into the setup for each detector. And once programmed, it can't be changed on the fly as it is done in layout design mode.  (Yes I am aware of this)

We know it can do things to everything that passes, to a class of locos as they pass or to an individual loco.  We know it can do if then else commands.  Some moons ago, you even listed all of the possible programming commands, but that got lost in duplicated threads when the forum was updated.  But the info is still there in the detector setup window.  (This information has been added above and includes new commands)

 

Now back to a tender passing a tag: you say it may do nothing and that because it has carriages behind it.  If there are no carriages though, you want the tag to signal the block is now clear (yes I know it doesn't say the block is clear, it just says I saw the tender just now going this way at this speed, you program that to have the consequences of the block being clear).  The problem is how does it know if carriages are coming or not.  Answer me that and we can go on.

 

Hi Fishy

 

CONSIDERING TRAIN & TENDER & TRAIN WITH CARRIAGES

 

Let us just discuss one train with tender and the same train with carriages

Tabs are fitted to the train, the tender and the last carriage

Lets us number the tags TRAIN001, TENDER01 and LAST001

The signal they pass over is  SIG30

The sensor near the signal SENS30

(I appreciate these will no doubt be numbers I am using codes we can follow clearly.

 

Our TRAIN001 has just passed signal SIG25 and is coming towards our example at SIG30

 

TRAIN001 passes over Sensor SENS30, Information is sent to the LD controller with two codes TRAIN001 & SENS30. LD controller sends this information to RM, RM looks up SENS30 for any instructions relating to it or ANY.

There may be no instructions, there may be 1 instruction there may be many instructions. One instruction is certain at this stage, we will have programmed if ANY TRAIN passes this sensor change the signal adjacent it to RED to protect the block it is moving into. I am sure we both agree to here.

 

Now back to the 'do nothing' question...

 

Lets say TRAIN001 passes sensor SENS30

 

SENS30 has the following commands programmed in to it.

- Set danger signal SIG30 - RED    (TRAIN001 has just passed it)

- Set clear signal SIG25 - GREEN  (LAST001 last carriage passes it)

 

This is why I have suggested the two new commands

Set proceed caution          YY

Set proceed extra caution  Y

 

We would want to say for example, last carriage (or tender) has passed sensor do the following

SIG25 - Y

SIG20 - YY

SIG15 - G

 

Note there is no command for the following but there was a tag on the tender

 

- Set clear signal SIG25 - GREEN  (TENDER001 last carriage passes it)

 

The sensor picked up the following 4 codes, 3 relating to SEN30

SENS30

*TRAIN001

- TENDER001

* LAST001

 

But RM only has commands for the items I have marked * so for sensor 30 it only carries out tasks programmed in advance marked for this example * and no other so although it knew TENDER001 passed over SENS30 there is no programmed instruction for this so it ignores it.

 

I could be totally wrong but this is how I see it now.

 

PJ

[PJ_model_trains]

Let me just concentrate on the tender with or without carriages problem for now PJ.

 

Remember again, all of your LD programming is written into the setup for each detector. And once programmed, it can't be changed on the fly as it is done in layout design mode.  (Yes I am aware of this)

We know it can do things to everything that passes, to a class of locos as they pass or to an individual loco.  We know it can do if then else commands.  Some moons ago, you even listed all of the possible programming commands, but that got lost in duplicated threads when the forum was updated.  But the info is still there in the detector setup window.  (This information has been added above and includes new commands)

 

Now back to a tender passing a tag: you say it may do nothing and that because it has carriages behind it.  If there are no carriages though, you want the tag to signal the block is now clear (yes I know it doesn't say the block is clear, it just says I saw the tender just now going this way at this speed, you program that to have the consequences of the block being clear).  The problem is how does it know if carriages are coming or not.  Answer me that and we can go on.

 

Hi Fishy

 

CONSIDERING TRAIN & TENDER & TRAIN WITH CARRIAGES

 

Let us just discuss one train with tender and the same train with carriages

Tabs are fitted to the train, the tender and the last carriage

Lets us number the tags TRAIN001, TENDER01 and LAST001

The signal they pass by is  SIG30

The sensor near the signal SENS30

(I appreciate these will no doubt be numbers I am using codes we can follow clearly.

 

Our TRAIN001 has just passed signal SIG25 and is coming towards our example at SIG30

 

TRAIN001 passes over Sensor SENS30, Information is sent to the LD controller with two codes TRAIN001 & SENS30. LD controller sends this information to RM, RM looks up SENS30 for any instructions relating to it or ANY.

There may be no instructions, there may be 1 instruction there may be many instructions. One instruction is certain at this stage, we will have programmed if ANY TRAIN passes this sensor change the signal adjacent it to RED to protect the block it is moving into. I am sure we both agree to here.

 

Now back to the 'do nothing' question...

 

Lets say TRAIN001 passes sensor SENS30

 

SENS30 has the following commands programmed in to it.

- Set danger signal SIG30 - RED    (TRAIN001 has just passed it)

- Set clear signal SIG25 - GREEN  (LAST001 last carriage passes it)

 

This is why I have suggested the two new commands

Set proceed caution          YY

Set proceed extra caution  Y

 

We would want to say for example, last carriage (or tender) has passed sensor do the following

SIG25 - Y

SIG20 - YY

SIG15 - G

 

Note there is no command for the following but there was a tag on the tender

 

- Set clear signal SIG25 - GREEN  (TENDER001 last carriage passes it)

 

The sensor picked up the following 4 codes, 3 relating to SEN30

SENS30

*TRAIN001

- TENDER001

* LAST001

 

But RM only has commands for the items I have marked * so for sensor 30 it only carries out tasks programmed in advance marked for this example * and no other so although it knew TENDER001 passed over SENS30 there is no programmed instruction for this so it ignores it.

 

I could be totally wrong but this is how I see it now.

 

PJ

[Fishmanoz]

PJ, if there is no programmed instruction for the tender, what can happen up the line if there are no carriages?  Nothing.  So the up line signals never go through the Y YY G sequence, they stay red.

 

In order to do this, there must be programmed instructions for the tender.  You can't have it both ways, there must be instructions there for the tender and for the last carriage, but you can't tell which is the back of the train, tender or carriages?

[PJ_model_trains]

PJ, if there is no programmed instruction for the tender, what can happen up the line if there are no carriages?  Nothing.  So the up line signals never go through the Y YY G sequence, they stay red.

 

In order to do this, there must be programmed instructions for the tender.  You can't have it both ways, there must be instructions there for the tender and for the last carriage, but you can't tell which is the back of the train, tender or carriages?

 

Hi Fishy

 

There must be a program instruction for  > either <  the tender or the last carriage.

 

The LD programming instruction has to be placed before the train can be run and cannot be done on the fly.

.

Let me put it another way

 

Let's say CoN01 passed SIG30

Sensor - SENS30 sends two items back to LD controller and RM

SEN30 to tell RM which sensor it is

CoN01 to tell it which train it is

RM has an instruction programmed to request SIG30 to change to R as train passes

There were no other instructions to carry out.

Job done.

 

As the train proceeds the tender goes over the SEN30

Sensor - SENS30 sends back two items of data to the LD controller and RM

SEN30 to tell RM which sensor it is

CoNTend1 to tell it the CoN tender has passed over the sensor

RM checks and doesn't have an instruction to carry out so every thing continues

Job done.

 .

As the train proceeds the last of 7 carriages goes over the SEN30

Sensor - SENS30 sends back two items of data back to LD controller and RM

SEN30 to tell RM which sensor it is

CARR07 to tell it last carriage has gone over the sensor

RM has an instructions programmed to request the following when CARR07 passes SEN30

SIG25 to show Y

SIG20 to show YY and

SIG15 to show G

Job done.

.

If we ran the train only we would give commands in the LD blocks in RM for the CoN train (CoN01) and the tender (CoNTend1) only but have to know and program before we run the train.

.

We do not need to know which is the back of the train, RM knows that by knowning what the codes stand for, we are running trains, LD & RM haven't a clue, they just process numbers to work as we program them.

 

Please continue with the discussion, I am only saying as I see it, and welcome others views.

 .

With regard a 'none command' I believe there will be loads of them.

.

We will ask this train to hoot hoot, which means other trains won't make the sound as the programmed instruction is not for them but... A train will go over a sensor, RM will be told which sensor and that train ID, RM will check what has been programmed if it is the right train, there will be a command for it and it will hoot hoot, if it is another train, a different ID so no instruction for this train, it won't give a hoot.

.

PJ

[Fishmanoz]

But in this instance PJ, it is the same loco, first time only with tender and second time with carriages. And when the tender passes, it can't tell if there are carriages or not, so it doesn't know whether to process the tender instruction or not.

[Fishmanoz]

Put simply, it will not be possible to program such a contingency into the instructions in the detector setup.  

 

However, if you are going to run CoN with or without carriages, what you can do is to tell the detector, if it detects CoN, run CoN program.  Then you are going to have to change that program dependent on whether CoN is running with or without carriages. That was discussed earlier under setting of variables.

 

Or you can put a tag at the head of the rake as well as at the tail.

[PJ_model_trains]

But in this instance PJ, it is the same loco, first time only with tender and second time with carriages. And when the tender passes, it can't tell if there are carriages or not, so it doesn't know whether to process the tender instruction or not.

 

Hi Fishy

 

As I said, you have to decide if you are running with or without carriages and program first.

 

A freight yard would know before hand what was being run on a certain day, A diesel engine would know what routes it was doing and how many carraiges on a certain day.

 

It would be up to us how much we vary our train journeys and program accordingly. We could run 7 trains on 7 different days and program them all in, only the trains run would read and obey commands but, they would have to be run as previously planned and programmed with or without carraiges or wagons.

 

We could add more carriages or wagons (providing they are not the last one with the tag on it)

 

How much we vary things and program sendors is down to us. I could imagine someone with say 20 trains programming all in to the sensors and just choose different trains on different days. They wouldn't need to do any other programming and DMU's are even easier. Swings and roundabouts.

 

PJ

[PJ_model_trains]

Put simply, it will not be possible to program such a contingency into the instructions in the detector setup.  

 

However, if you are going to run CoN with or without carriages, what you can do is to tell the detector, if it detects CoN, run CoN program.  Then you are going to have to change that program dependent on whether CoN is running with or without carriages. That was discussed earlier under setting of variables.

 

Or you can put a tag at the head of the rake as well as at the tail.

 

This is the bit I am trying to get over.

You have to decide beforehand, are you running a train on it's own or with carriages and which carriages.

If you have carriages or wagons you can have as many or as few as you like so long as LD sensor knows it is a train with carriages/wagons and the last one has the tag on it.

 

PJ

[Fishmanoz]

Yes, it will have to know beforehand.  But it is not feasible that knowing beforehand involves going into layout design and changing the instructions you have programmed into one or many detectors.  It is reasonable that you change the content of the program you have called up in all the detectors down your line.  Or that you set a variable in the CoN program called up in the detector programming, dependent on whether CoN has a rake behind it or not.

 

And from what you've said, I think you get it now.  I wasn't convinced of that before.  

[PJ_model_trains]

Yes, it will have to know beforehand.  But it is not feasible that knowing beforehand involves going into layout design and changing the instructions you have programmed into one or many detectors.  It is reasonable that you change the content of the program you have called up in all the detectors down your line.  Or that you set a variable in the CoN program called up in the detector programming, dependent on whether CoN has a rake behind it or not.

 

And from what you've said, I think you get it now.  I wasn't convinced of that before.  

 

Hi Fishy

 

Sometimes some things are hard to explain, with so many variables, often it is easy to focus on a specific issue and try explain that but, another person has something on there mind that blocks the line of thought. To be honest, I think you got it now, I too wasn't convinced of that before.

 

But then we get back to the very important issue that is programming Y, YY, G when another train can turn any one of those R as it passes and it's last carriage want to process Y, YY, G back down the line that may have a R aspect signal in that combination, R must have priority not to be changed by the signal requests mention above i the sequence.

 

The second issue in discussion is how LD identifies a train with tender or a train with tender and rake of carriages/wagons from pre-programmed sensor(s).

 

PJ

[Fishmanoz]

There's a hole in the bucket!  You just said at the end what I said at the start?

 

You may even be able to write a program at the first sensor saying:

 

If carriage detected,

Set carriage/no carriage to carriage (you may have to call up a program to do it)

Else continue as no carriage

QED

[Fishmanoz]

Oh, and do please go back and read my long post, it says more than all of my other long posts put together.

[PJ_model_trains]

There's a hole in the bucket!  You just said at the end what I said at the start?

 

You may even be able to write a program at the first sensor saying:

 

If carriage detected,

Set carriage/no carriage to carriage (you may have to call up a program to do it)

Else continue as no carriage

QED

 

Fishy

 

The next to last statement was, 'getting back to issue 1'

 

The final one was 'listing issue 2'

 

PJ

[PJ_model_trains]

Hi All

 

I have been wondering, there are a lot more people interested in, or enquiring about LD.  Could this be a good opportunity to go back to grass roots in a new thread?

 

Start with the basics, even the very basics, may be, call the thread something like

Loco Detection / Signals - Getting started discussion.

 

Signalling needs to be included but after the basics we could then discuss using LD without signals. This could start off with a few basic questions and an image and ask a simple question to encourage members to take part, but also help those reading now or in the future. Adding an image will help so much.

 

This will be good from the point of view that so many see things from a different position, and instead of a couple of members discussing an issue or item more people can have a say. During the discussions someone might say what about discussing this or that issue and that can be raised as a seperate discussion all in the one thread.

 

Three-Six months down the line a new member can be referred to the thread and read from the start, starting with the baasic items to understand and gradually getting more involved as the thread grows.

 

Just a thought, comments welcome guys

 

PJ

[Fishmanoz]

Might be useful PJ but I don't believe basic discussion includes signalling at all.

 

Basic LD might be:

 

If loco 1 is detected at detector 1 set loco 1 speed to Shunt

 

Then:

 

If loco 1 is detected at detector 2, set point 1 left

If loco 2 is detected at detector 2, set point 1 right

 

Only then might you add:

 

If any loco is detected at detector 3, set signal 1 red and set loco speed to Stop

 

I certainly wouldn't include any setup programming of points and signals into initial discussion.

[PJ_model_trains]

Might be useful PJ but I don't believe basic discussion includes signalling at all.

 

Basic LD might be:

 

If loco 1 is detected at detector 1 set loco 1 speed to Shunt

 

Then:

 

If loco 1 is detected at detector 2, set point 1 left

If loco 2 is detected at detector 2, set point 1 right

 

Only then might you add:

 

If any loco is detected at detector 3, set signal 1 red and set loco speed to Stop

 

I certainly wouldn't include any setup programming of points and signals into initial discussion.

 

Fishy

The Topic is... Train-Tech signals and set up in RailMaster

Which evolved to include LD as there is a definate link.

So I do believe basic discussion includes signalling.

PJ

[Fishmanoz]

My mistake, I took you to be emphasising LD not signalling.

 

In that case, I change my answer to no.  LD and signalling is not basic.  It is a specialised discussion for those intending extensive signalling.

[PJ_model_trains]

My mistake, I took you to be emphasising LD not signalling.

 

In that case, I change my answer to no.  LD and signalling is not basic.  It is a specialised discussion for those intending extensive signalling.

 

Train-Tech signals and set up in RailMaster

is the topic title.

 

LD was mentioned and the discussion went further, common in most threads, a little drifting off topic, having said that the issues being discussed were related.

 

Hornby like Train-Tech signals, they are the only ones they know of with a built in decoder which makes them much easier to program and install on any layout.

 

Extensive signalling in my mine is the CR Signals, Train-Tronic and other makes of signals with separate decoder which Hornby, in most cases, are not ready for yet. These are more specialised.

 

4 signals in an oval loop is not extensive. Full credit to HRMS, they have now fixed all but one small bug and are working on this as we speak.

 

PJ

[PJ_model_trains]

UPDATE

 

HRMS have spent a lot of time helping sort the issue with Train-Tech, 4 aspect signals, which I am most grateful for. The problem initially was the last signal back down the line R, Y, YY, G the G was firing RED. This was improved and narrowed down to just one signal where the Green aspect was showing Red. It was always signal ID:30 of the set up ID's 15, 20, 25  and 30.

 

My view at that time was it had to be a software issue, HRMS on the other hand said they had 4x Train-Tech 4 aspect signals working correctly on their layout.  A lot more discussions were held and HRMS kindly logged in to my computer to hopefully find what I was doing wrong.  During our long discussion I was able to show I wasn't doing anything wrong and HRMS were able to see the fault that was occurring. Following this HRMS set up my situation on their layout and were able to replicate the problem. This was good news; an issue had been found and replicated so now hopefully a fix will be found. 

 

HRMS decided to purchase more 4x 4 aspect Train-Tech signals and having done so, just prior to v1.60 being launched confirm they felt it was a faulty signal having changed a signal it worked.

 

What doesn't make sense to me is why I would have a faulty signal in the same location as HRMS had. What also doesn't make sense to me is that HRMS say there are no software issues and Train-Tech confirm their signals are all the same, same circuit board, same wiring etc. So we are left with two companies saying their products are right but there was a problem on HRMS layout, which they replicated from my layout/signal setup, HRMS say they no longer have a problem but I do.  The next stage for me then has to be purchase another 4x 4 aspect Train-Tech signal, or request an exchange from Train-Tech, then when I receive the new one put it in the place of the one causing the issue and hope it fixes the problem. 

 

This message is an update regarding Train-Tech 4 aspect signals and a fault in the down the line sequence; it no way is it criticism of HRMS who have been so helpful, particularly the gentleman who spent 2 hours last week as we each discussed the set up and the fault. I purchased my signals in September last year, the fault being reported to HRMS at the end of September, early October, I have been very patient and will remain so to the end. Hopefully a new signal for me will also stop the problem occurring but, I have to wait and see. I put it to HRMS that I have to wonder how two rights can make a wrong. Two companies saying their products are (now) working error free, but there was a fault, on my system and on HRMS layout when they replicated the setup.  If a new signal does not solve the issue HRMS feel it could may then be a timing issue. 

 

I remain open minded and patient. May be it would have been better for Hornby to make a two, a three and a four aspect signal to work with RM. Even if it cost a little more I am sure they would sell as customers would purchase from Hornby items designed by Hornby to be compatible with their system. I do understand with the period they have come through it was not possible then but, maybe in the future.

 

PJ