Train-Tech signals and set up in RailMaster

[PJ_model_trains]

Hello HRMS

 

Thank you for your email, I will run the tests requested tomorrow and email you the results and settings

 

Thank you for your prompt reply

 

PJ

[Fishmanoz]

Very mysterious PJ, but I don't doubt you will tell us soon.

[St1ngr4y]

Hello HRMS

 

Thank you for your email, I will run the tests requested tomorrow and email you the results and settings

 

Thank you for your prompt reply

 

PJ

Hi PJ,

Very disappointing - do you remember my post about Traintech signals in the 1.59 thread?

Ray

[PJ_model_trains]

Very mysterious PJ, but I don't doubt you will tell us soon.

 

I will Fishy but only briefly I will not be going into to much detail.

 

I have spent all morning with HRMS, few minor bits they are sorting and I have another test shortly.

 

It is looking MUCH better than last night and could help bring LD forward once signals are sorted 

 

That will get John started up again, take his mind off melting points.

Fancy having melting points and being frozen up with -7 degrees of frost!  

He will live in France  ;o)

 

PJ

[PJ_model_trains]

UPDATE - TRAIN -TECH 4 ASPECT SIGNALS

 

HRMS have worked hard today to fix the problem, they felt Christmas Eve they had but yesterday it appeared they hadn't.

 

A few tweaks and a lot of testing today, at last it looks like we are 'on track' and can start to move forward again.

 

ALL 4 aspect Train-Tech signals work independantly and in sequence

 

A brilliant way to end 2014, and less on the 'to do list' for 2015.

 

Thank you HRMS Development Team for all your hard work.

 

They confirmed a new RM version 1.60 update will be available in the New Year with a few more fixes to minor items and corrections to the 4 Aspect signals from the preset drop down menu.

 

HRMS confirm they are building in independent control of feathers for signals but cannot give you a date when this will be available in the software.

 

I didn't dare ask about LD at this time, it is New Years Eve and they have worked so hard

 

HAPPY NEW YEAR Hornby, HRMS and forum Admin

 

PJ

[RDS]

I still can't see the relationship between LD availability and a software issue in RM.

[PJ_model_trains]

Hi RDS

 

As I see it, if the signalling issue are not sorted out, current issues, plus feathers, plus adding additional 3rd party signals and decoders which they say they need to add, then they will not release Loco Detection even if it was available. Why, because they need to make sure all these items work, not just in RM but also in LD before they dare launch it.

 

So, if these issues are sorted out we have to be a step nearer, I think  ;o)

 

PJ

[RDS]

Hi PJ

Sorry, but you will never convince me (what was that saying - never say never!).

As far as I am aware, the software in RailMaster is responsible for changing points, signals etc and operating the Loco's etc.  LD by it's very definition is to detect loco's and when it has done that, the results will be fed into RM and if applicable, the signals and points will be changed, or anything else that the operator has programmed in to RM.

Again in my humble opinion, assuming that the Hardware has been developed, it is the patent process that will hold up LD and that can take years.

 

[PJ_model_trains]

Hi PJ

Sorry, but you will never convince me (what was that saying - never say never!).

As far as I am aware, the software in RailMaster is responsible for changing points, signals etc and operating the Loco's etc.  LD by it's very definition is to detect loco's and when it has done that, the results will be fed into RM and if applicable, the signals and points will be changed, or anything else that the operator has programmed in to RM.

Again in my humble opinion, assuming that the Hardware has been developed, it is the patent process that will hold up LD and that can take years.

 

Hi RDS

So there are the to reasons after all.

What a good point to wish you a Very Happy New Year

For  some it is already 2015, for us  a few hours away, for others well thy will just have to wait like we are waiting for LD?  I know which will come first  ;o)

PJ

[PJ_model_trains]

UPDATE - TRAIN -TECH 4 ASPECT SIGNALS

 

HRMS have worked hard today to fix the problem, they felt Christmas Eve they had but yesterday it appeared they hadn't.

 

A few tweaks and a lot of testing today, at last it looks like we are 'on track' and can start to move forward again.

 

ALL 4 aspect Train-Tech signals work independantly and in sequence

 

A brilliant way to end 2014, and less on the 'to do list' for 2015.

 

Thank you HRMS Development Team for all your hard work.

 

They confirmed a new RM version 1.60 update will be available in the New Year with a few more fixes to minor items and corrections to the 4 Aspect signals from the preset drop down menu.

 

HRMS confirm they are building in independent control of feathers for signals but cannot give you a date when this will be available in the software.

 

I didn't dare ask about LD at this time, it is New Years Eve and they have worked so hard

 

HAPPY NEW YEAR Hornby, HRMS and forum Admin

 

PJ

 

Oh dear!

 

Yesterday HRMS and myself carried out tests on 4 x4 aspect Train Tech signals using the track layout file of that name from the lastest download. We went through every stage together, one at a time, and managed in the sample file to get 4 signals to work correctly on their own and in sequence. Brilliant news!

 

I then changed the port addresses to what I had used previously and problems occurred, how can this be, what have I done wrong, it must be my set up we had it working earlier with HRMS.

 

Today I have gone back to square one and used the test layout file HRMS and myself used yesterday, the result, it worked! So I had to them work out why and what 'I' was doing wrong. Strangely nothing wrong, it was the difference in pattern that causes the problem. In fairness there are two issues not one.

 

RM 1.59 Rev 2 includes the file Train-Tech Signals, for anyone wanting a look open it in RM Mimic layout plan and view the signal settings. 

 

Signal 30 is set in the settings column to G, R, R, G this is the first signal in the line

Signals 25, 20 & 15 settings are R, G, R, G 

 

HRMS say this is ddown to a fault in Train-Tech signal? Strange their first one is also my first one?

 

But when HRMS set up as this shows and I do the same theirs and mine work.

 

So that is one issue what is the other?

 

The example layout with signal set up only allows for a passing train, e.g. a train on a straight track running from A to B, it also reduces the sequence in the length of 4 signals. The chances of this I feel are slim, it may happen with someone with a shelf type layout, a left to right track run. The fact is, I think, that a larger percentage of users will have an oval track, one way or another. 

 

The problem occurs when the signals form a loop, or we look at the loop and for this example have 4 signals, protecting 4 blocks in an oval. For the signals to work in sequence (forget red will be independant this test is looking to set sequences) the signals will run similar to this.

 

30, 25, 20, 15 using the signal ports in the example. But as a train moves round it could be

25, 20, 15, 30 then 20, 15, 30, 25 etc depending which way they are coded and which way the train runs (all signals left of the track)

 

Putting the above into aspects would be

R, Y, YY, G and as the train moves into subsequent blocks ALL 4 setting move with it.

 

When the loop is programmed they do work correctly with one exception signal 30 shows red when it should show green. All other signals work fine in the correct sequence.

 

At this stage it is clear to see the problem is linked with signal 30 set up being different to the other 3 . 

 

I have emailed HRMS Development team and await their reply after the New Year holiday. Although I took on board their comments of having to change signal 30 for a fault or conflict problem, it seems strange to me they asked me to set that first as they did and I get the same result. If a signal had a fault the chances of theirs and mine being in the same position seem to me very slim.I await their reply.

 

NOTE as mentioned above, the procedure used in the sample Train-Tech file was for testing sequence as stated, this would not be true in real life and we would not include the Red in the sequence on our layouts. WHY for those wh arenot sure I confirm, A signal will turn to red (or be changed to red) when a train passes it to protect the next block it is moving into. Nothing else changes at that point. When the last carriage or the tender if no carriages passes the signal that changed Red, the previous ones down the line change in order Y, YY and Green, so if we are putting the sequence into our signals we would not use Red.

 

To be honest, a lot of time as been spent on signals, by many at HRMS and by a few on the forum. I have found that in programs I can change ANY signal using a single command for each when using programming a train, if this is possible in Loco Detection we will be able to change as many signals as we wish using these techniques... train passes signal (30) change Red, and when last carriage or tender passes signal (30)  change signal (25) Y, and signal (20) YY and signal (15) G. With this method the last command will be the last completed so if Train A's last carriage has changed signal (20) to YY and another train passes signal (20) then Train B changes the drop back sequence on this signal to the prioriy red signal (I am hoping LD will have this priority built in so that it cannot be changed the other way) Red must be the priority signal.

 

We will wait to hear HRMS reply to the two faut items mentioned above. 

 

I am sure they will also note the comments regarding Red signal and LD having priorty over the Red as well as the ability to include signal changes as stated above.

 

I welcome anyones comments regarding the above. Ray I am sure you will want to check out the changes in signal settings for 4 aspect Train-Tech signals.

 

PJ

[Fishmanoz]

PJ, you sure are going to be using a lot of ID tags, not just in locos but on tenders and on last carriages/wagons in rakes In order to do as you say.  And already I see a problem: your unconditional changes to red when a loco hits a signal will be fine; but if you want conditional changes back up the line after the train has passed, how are you going to distinguish between a loco with tender on its own and the same loco with its tender and a rake attached for when the conditional changes occur?  The tender will initiate the conditional commands before the last carriage leaves.

 

You talk about priorities for red and I understand.  Ignoring my problem above, you are going to initiate the changes to red when you detect any of your loco IDs, and up line changes to Y YY G when you detect any of your tenders/last-in-rakes at the same detector.  Your problem is going to be a second train entering the 4 blocks before the last carriage leaves the block down the line and the red that was set on entry up the line being overtaken by the last carriage initiated non-red command Down the line.  Am I right?

 

The only solution I thought I could see to this was to ensure that an up line red signal is not changed by a downline command to change from a different train's last carriage.  This is hard enough as you are going to have to link loco and tender/last carriage IDs so you can distinguish different trains, then write commands conditional on which train is issuing them.  But it's not just reds that may be a problem, if trains are closer it could be Ys or even YYs that require such conditional programming. At that point, my brain freezes over and I wish I hadn't even entered this debate. 

 

But I'll leave what I've written here as I think it at least further defines the problem for everyone, even if I can't see a practical way through to a solution.

 

And I can't see making reds have priority over anything else being the solution as, once red, nothing will ever change to anything non-red.

 

Any thoughts HRMS?

[PJ_model_trains]

PJ, you sure are going to be using a lot of ID tags, not just in locos but on tenders and on last carriages/wagons in rakes In order to do as you say.  And already I see a problem: your unconditional changes to red when a loco hits a signal will be fine; but if you want conditional changes back up the line after the train has passed, how are you going to distinguish between a loco with tender on its own and the same loco with its tender and a rake attached for when the conditional changes occur?  The tender will initiate the conditional commands before the last carriage leaves.

 

You talk about priorities for red and I understand.  Ignoring my problem above, you are going to initiate the changes to red when you detect any of your loco IDs, and up line changes to Y YY G when you detect any of your tenders/last-in-rakes at the same detector.  Your problem is going to be a second train entering the 4 blocks before the last carriage leaves the block down the line and the red that was set on entry up the line being overtaken by the last carriage initiated non-red command Down the line.  Am I right?

 

The only solution I thought I could see to this was to ensure that an up line red signal is not changed by a downline command to change from a different train's last carriage.  This is hard enough as you are going to have to link loco and tender/last carriage IDs so you can distinguish different trains, then write commands conditional on which train is issuing them.  But it's not just reds that may be a problem, if trains are closer it could be Ys or even YYs that require such conditional programming. At that point, my brain freezes over and I wish I hadn't even entered this debate. 

 

But I'll leave what I've written here as I think it at least further defines the problem for everyone, even if I can't see a practical way through to a solution.

 

And I can't see making reds have priority over anything else being the solution as, once red, nothing will ever change to anything non-red.

 

Any thoughts HRMS?

 

Hi Fishy

 

Thank you for your input.  I will come back to this when I had more time to go through your comments and explain things in maybe more detail. This is good, as the conversation here will bring out points others members may see, or view differently, HRMS can decide if they have satisfactorily covered the items raised by members in discussion based on their current knowledge and operation of the system they have created.

 

Chat later, I have a few things to sort first.

 

PJ

[PJ_model_trains]

Fishy I will add my reply in your message stage by stage I think it will be clearer that way, hopefully if will show as planned. (replies in bold) so this time everything is in the Yellow area.....

 

PJ, you sure are going to be using a lot of ID tags, not just in locos but on tenders and on last carriages/wagons in rakes In order to do as you say.  

 

One tag per loco, one tag on the end of the tender of larger trains and on the end of a last carriage or guards van. Only two per train and rake.

And already I see a problem: your unconditional changes to red when a loco hits a signal will be fine; but if you want conditional changes back up the line after the train has passed, how are you going to distinguish between a loco with tender on its own and the same loco with its tender and a rake attached for when the conditional changes occur?  The tender will initiate the conditional commands before the last carriage leaves.

 

One tag for the loco let's say #1020, one tag for the tender #1022 or if with carriages or wagons train #1020 and last carriage or wagon/guards van #1111 for example. We would program what each does, Train LD ID #1020 change signal #30 RED. Tender passes sensor sees #1022 but does nothing because there is no command. When final carriage/wagon/guards van passes over sensor we have IF #1111 then signal #25 Y, signal #20 YY and signal #15 G.

 

If ti was just a train and tender the tender code #1022 would be programmed to do what #1111 does. All the system knows for trains and carriages is LD ID's (numbers)

 

So all we have two tags per train and carriages/wagons, or two tags on a large train and tender if running on it's own.

You talk about priorities for red and I understand.  Ignoring my problem above, you are going to initiate the changes to red when you detect any of your loco IDs,

 

Correct

and up line changes to Y YY G when you detect any of your tenders/last-in-rakes at the same detector.  

 

Yes but, Red has priority at all times - STOP. It has to have. So taking the priority as you state previous signals change to Y, YY and G - Providing there is not a Red in that sequence! If there is a Red in that sequence it should only 'change to the Red' as Red is the priority signal.  e.g. ideally as you see it should go  #25, Y, #20 YY, #15 G but, a train has taken priority at one of those signals so the software should only allow instructions 'back to the Red. Priority is Red! e.g. #25 Y, #20 and all previous signals no change as #20 is Red 

 

Your problem is going to be a second train entering the 4 blocks before the last carriage leaves the block down the line and the red that was set on entry up the line being overtaken by the last carriage initiated non-red command Down the line.  Am I right?

 

Not possible IF Red has priority, as I am seeing it this is a very important part of the software working.  If train passes signal #30 it turns Red, basically protecting the block it is in, the previous signal is still Red as the trains carriages are still in that block, so two  blocks are protected at this stage. It is only when the last carriages enters that block, moved into it, that the previous block moves to Y. Train driver proceed with caution.

 

The only solution I thought I could see to this was to ensure that an up line red signal is not changed by a downline command to change from a different train's last carriage.  

 

I am thinking you are moving ahead to fast here fishy, there are three stages.

ONE: let's get one length correct first, train and carriages moving correctly according to signals for at least 4 blocks.

TWO: this is more complicated, if a line is used as an up line and a down line. We must get stage-1 working correctly first.

THREE: here is where the fun starts a train(and carriages) move from an inner oval (or track) to an outer one. Again the system including software must work right at stage one, if it doesn't it will be chaotic and a total nightmare putting many off using the system.

This is hard enough as you are going to have to link loco and tender/last carriage IDs so you can distinguish different trains, then write commands conditional on which train is issuing them.  

 

We would naturally expect this, our trains have a number and carriage rakes have a number, would this not be similar in a goods yard. It is like a wagon taking a consignment of containers, everything is numbers So train #1020 may have a rake #1111 or may have a different rake #1115. But it is not as complicated as it first seems, the train only turns a signal Red, the last carriage of this rake or that rake say turn 'previous signals' Y, YY or G. So there is not an issue code in al trains, code in all rakes of carriages, basically a front command (driver) or a back command (guards person)

But it's not just reds that may be a problem, if trains are closer it could be Ys or even YYs that require such conditional programming. At that point, my brain freezes over and I wish I hadn't even entered this debate. 

 

I understand Fishy but if the Red has priority, not just train turns signal Red but as stated further back, previous signals change Y. YY or G but only back to a Red. That priority is essential and very important or we all put our heads in the freezer and probably leave them there!

 

But I'll leave what I've written here as I think it at least further defines the problem for everyone, even if I can't see a practical way through to a solution.

 

Have a read, have a think and we will chat again (I am sure)

And I can't see making reds have priority over anything else being the solution as, once red, nothing will ever change to anything non-red.

 

Any thoughts HRMS?

 

Comments are very welcome and important, this is why it is good to talk about Loco Detection even against months of criticism. I think so anyway as we have discussed many areas and no doubt will continue to do so. The important thing I think is that LD works with stage one above with more than one train on the 4 blocks. If it doesn't stage two and three will never be reached. 

PJ

 

[St1ngr4y]

Good morning PJ, and a Happy New Year to everyone,

I'm afraid Fishy is absolutely correct. I've said this a few times on the Forum recently that I believe a lot of people will be very disappointed with what LD provides. It isn't the hardware that's wrong, it is the current level of sophistication of the user programming aspects of RM which is deficient. A true "program" has to be capable of carrying out different sets of actions depending on whether a condition is true or false. A program should also be capable of remembering events and for this "variables" are required.

To quote your example, when a last carriage passes a signal, and you want RM to adjust the signals back down the line, the user "program" that YOU will have to provide, must be able to test whether another train has passed any of those signals, and take different actions depending on whether this has happened or not. To have RM work this out for itself is just not on.

Ray

Apologies - I hadn't seen your last reply to Fishy when I posted this. Just one point - I don't think Fishy meant an up line and a down line - I think he meant "further up the track" and "further down the track".

[PJ_model_trains]

Good morning PJ, and a Happy New Year to everyone,

I'm afraid Fishy is absolutely correct. I've said this a few times on the Forum recently that I believe a lot of people will be very disappointed with what LD provides. It isn't the hardware that's wrong, it is the current level of sophistication of the user programming aspects of RM which is deficient. A true "program" has to be capable of carrying out different sets of actions depending on whether a condition is true or false. A program should also be capable of remembering events and for this "variables" are required.

To quote your example, when a last carriage passes a signal, and you want RM to adjust the signals back down the line, the user "program" that YOU will have to provide, must be able to test whether another train has passed any of those signals, and take different actions depending on whether this has happened or not. To have RM work this out for itself is just not on.

Ray

Apologies - I hadn't seen your last reply to Fishy when I posted this. Just one point - I don't think Fishy meant an up line and a down line - I think he meant "further up the track" and "further down the track".

 

Good afternoon Ray, Happy New Year to you also.

 

Thanks for confirming your mesage was before my last one.

 

It is correct regarding remembering variables, one way or another, what I was trying to describe was based on Red must have priority (it is a stop command). I think reading my initial message and Fishy's reply i thought as it could be taken the Red for the train only, as explained further it is what happens to the commands down the line and that Red priority that will make of break this system.

 

It can be absolutely fantastic but if not careful I feel it could be a white elephant, Hornby cannot afford that to happen hence I keep trying to encourage discussion amongst us. I know it hasa been critised but feel discussion is very important.

 

I have another senario to raise yet but, don't feel the discussion is ready today, lets just see where we go with this, hopefully positively and not thrown out as head in the freezer situation.  (Not intented at Fishy mine is been in a few times)

 

PJ

[PJ_model_trains]

Just one point - I don't think Fishy meant an up line and a down line - I think he meant "further up the track" and "further down the track".

 

No problem Ray

 

As we know this is a very complex piece of software, LD and signal procedure can be hard to put into writing at times and often, I find, I focus on a specific situation to try explain a situation and sometimes another situation may be over shadowed. Again another reason to discuss together.  ;o)

 

PJ

[PJ_model_trains]

Just one point - I don't think Fishy meant an up line and a down line - I think he meant "further up the track" and "further down the track".

 

 

Hi

 

Further up the track should not be a problem, a train cannot continue if a signal is Red. 

 

I think, back down the line is the problem as we are giving instructions to multiple Block.

 

This is were technology on the railway AND our models moves forward.

 

Primarily we will be controlling blocks not trains this happen in real life railway. 

 

Once we have done that, we can then drive out trains, but when we do so they are subject to block conditions expressed by signal aspect, which in turn is what an engine driver does  ;o)

 

PJ

[St1ngr4y]

PJ,

I think we have to remember that this system will be called Loco Detection - it will do just that. It was not intended by Hornby, as far as I know, to be a Block Signalling system. LD will provide a limited number of actions which it will take when a "tag" is detected by a particular sensor. If those of us, like yourself, would like to use the system to simulate real-life block working, then good luck. I, myself, if I decide to go for it, will use it simply to bring trains to a stop accurately, in a station or siding for example.

Ray

[trainlover23]

Thank goodness I use gold old reliable DC and do not have to spend hours writing questions on here and an equal amount of hours reading the answers that are posted, some of which are pure drivel

[St1ngr4y]

Thank goodness I use gold old reliable DC and do not have to spend hours writing questions on here and an equal amount of hours reading the answers that are posted, some of which are pure drivel

And a Happy New Year to you...

 

So you must have spent hours on here reading the questions and answers, otherwise how would you be able to call them drivel.

[trainlover23]

No just a few from each section.

[Yelrow]

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

[St1ngr4y]

Hi John,

My thoughts exactly,

Ray

[PJ_model_trains]

 

Primarily we will be controlling blocks not trains this happen in real life railway. 

Once we have done that, we can then drive out trains, but when we do so they are subject to block conditions expressed by signal aspect, which in turn is what an engine driver does  ;o)

PJ

 

Hi  just to clarify the above...

 

I didn't say we were using block occupanct techniques what I said was 

 

Primarily we will be controlling blocks not trains this happen in real life railway. 

What I am referring to is different to block occupancy which controls blocks directly.

 

In the case of RM with LD and signals you achieve a similar affect doing things in a different way. With LD a train will pass a sensor and carry out instructions subject to programming first. One instruction discussed earlier, if Train 'X' passes signal #30 change it to red thus protecting the block it is moving into and occupying. So we are not controlling blocks directly as block occupancy systems do, we are primarily controlling blocks by our actions and by creating a Red signal so that with additional commands programmed in to LD sensor the train will stop.

 

Block Occupancy systems take control of a block, LD doesn't, for me that is the difference, the Hornby system is more real, or can be.

 

A signal controls a block only by the aspect shown. So if the engine driver fails to see the red signal he continues down the line, to get round this we program commands in LD to control the signal, which controls the trains actions and protects the block the train is moving into. Not by block occupancy but with a Red signal.

(I am aware of TPWS's as an additional warning system for the drivers, which can be to stop or more likely demand the driver to reduce speed and confirm he has done so, LD doesn't do this, it is not designed for this but in effect is actually carrying out a command in a 'similar way'...  if Red light stop.) LD will however be used to request trains to slow to certain speeds but will not have or need a TPWS confirmation system.

(A block being defined here as the gap between 2 signals controlled by instructions via sensors) 

I like RM, I like what I see so far with LD but have real concerns it will not do what I hope it will do. A lot will depend what happens between now and the launch. Will I buy it, yes if it does what I want, will I be in the queue to get it at launch, very doubtful, I will see what others say first. I have worked out, to do what with the system, sensors and tags, I would happily spend £400, but not if it is just a basic speed control system with the odd hoot hoot here and there. Time will tell

PJ

[PJ_model_trains]

Thank goodness I use gold old reliable DC and do not have to spend hours writing questions on here and an equal amount of hours reading the answers that are posted, some of which are pure drivel

 

That is your choice trainlover.

 

If you do not want DCC, signals or even LD those are all your choices.

 

For those of us who want to learn more or consider the other systems mentioned, we have a discussion, discuss advantages and disadvantes of a system, what works for one may not work for another, we discuss and learn from each other. 

 

We do not have to reply or take part in topics which may not be of interest to us, but anyone who is interest can join in and take part. That is the way it works, or should work, sharing ideas with like minded people to help us improve the things we really like, our trains and our layouts. The beauty of our hobby is every layout is different so it can give us lots to talk about.

 

PJ