Train-Tech signals and set up in RailMaster

[PJ_model_trains]

Hi Ray

Time to pack in I think, should be green.

I think I can safely say the decoder is set up right, so I will set up the second one and then the shunt sidings signal decoder. I can then start to think about getting someone to lift my layout so I can connect the point motor to the one I replaced and finalise the lighting. I should then be able to concentrate on signals and lighting above the layout and have time to play with my trains again and get more in to programming.  Hopefully HRMS will have answers for the various signal problems they are dealing with for me and others soon.

I have decided to cut the fingers off every Train-Tech signal and wire/solder them in, connecting to the track with wires under the cork so I will have lots to do. They look to much 'model train' slot into the track, at least cut off I can position them exactly where I want them and where they will look best.

Must make time to play though  ;o)

PJ

[St1ngr4y]

So bit 1 is 1. What about commonalities in other bits or are they all different across the group?

 

 

 

And I have no idea why that might be significant, none at all.

 

 

Hi Fishy,

Having downloaded v1.57, and found that this Traintech signal problem still exists, I decided to do some more experimentation. Shortly after 1.56 was released I reported that I was having problems with Traintech 2-aspect signals. HRMS advised me to re-configure them as R8247 decoders, which I did and they have operated satisfactorily like that. This morning I reconfigured all 13 of my 2-aspect signals back to Traintech Colour light instead of R8247, and I created a mini- test program for each one. The addresses of these 2-aspect signals are 102 103 104 105 106 107 108 121 122 123 124 125 126. Three of them didn't work - they behaved in a similar way to the 4-aspects which weren't working - when switched to clear by a program, the signal briefly flashes green, then immediately back to red.

 

Guess which three aren't working....

 

Yes, you go it - the three whose addresses are exactly divisible by four - 104 108 and 124.

 

I've passed this information on to HRMS by email, and hopefully it may help them to resolve the issue.

Ray

[PJ_model_trains]

Although I have added these details in RM 1.57 I feel it is better to have them here as well as they are the set up for Train-Tech signals.....

 

/media/tinymce_upload/Signal_set_up_box1.jpg

 

My signals were coded 100, 102, 104 & 106, train going forward, signals backwards down the line.

 

But I had an conflict in programming yesterday between 100 changing when I set 102 so reset 100 to 238.

 

The above therefore is based on 238, 102, 104 & 106

238 is the signal being programmed here.

 

The above shows, when the first signal, 238, is Red (train just passed lets say small train no carriages for easiness).

 

Therefore the previous signal 102 is Y, the one before that 104 is YY and the one before that is G

Then we say if the first signal 238 is Y then 102 is YY, 104 is G, 106 is G

Then we program if first signal 238 is YY

Then we program if first signal 238 is G

 

As detailed above and is now very clear to see.

 

We would then follow this pattern for each other signal down the line.

 

This is how HRMS recommend setting up 4x 4 aspect signals, each in turn.

 

The sequence problem I am experiencing is that all Green signals down the line in sequence are all showing Red but, the Yellow and double Yellow are all correct. The sequence is RIGHT from RM to screen, it is only WRONG from RM to signal although each signal works perfectly on their own. R,Y,YY,G

 

Hornby are still working on this issue.

 

This message here is to show the new boxes (also same for points) and to show the set up as recommended by Hornby which hopefully will help others starting out with signals.

 

These are set for Train-Tech signals.

 

We just have to be patient, a little longer, for the fix. Meanwhile to get round the problem I have to make all G signals in the sequence YY

 

PJ

[St1ngr4y]

Hi PJ,

I notice you have left the startup position for signal 238 blank. Does this cause RM NOT to set this signal on startup? I have set my TRAINTRONICS signal startup position to zero, because I don't want it to be set on startup, but RM still sets it. I have reported this to HRMS. Also, in the dropdown box for startup position, it only caters for stop or clear. I asked HRMS (by email) whether single yellow and double yellow could be added to this list, but they said they had no plans to do so.

Quote "In most cases a signal will start either red or green (mostly the latter until trains start moving)."

 

I thought I would not pursue this at this time.

Ray

[PJ_model_trains]

The above refers to setting up the first of 4 @ 4 aspect Train signals

 

BUT, it is AN EXAMPLE and may not be actual.

 

What do I mean by the above statement?

 

This example is to ensure the signals are set in sequence and working correctly.

They are from RM to screen but not yet from RM to signal. HRMS are working to fix this error/bug.

 

Putting that to one side for now, in reality you may not program your signals exactly as above, although would follow the sequence subject to the number of signal aspects.

 

Reason.....

The Red signal would not be in the sequence as shown. Red means STOP, as we know, a train has just passed the signal going into the next block. The sequence above shows the previous signal to go to Y and the one before to YY and the one before to YY. Although the sequence is correct the timing is WRONG!

 

The signal turns RED as the train passes it, the block it has come from does not change, it remains RED, because the train may be running slowly or may be in two blocks. The one before the signal and the one after it. But, more than likely the tender of a longer train or its carriages are in the previous block so although the signal turned RED as the train passes it, the previous signal remains RED due to the carriages in it.

 

So as I see it, the RED signal is a stand alone signal colour protecting the grid the train enters into, whilst the previous RED signal protect the block the carriages are in.

 

Now this is where the sequence should start. Once the last carriage passes the first signal, the previous block is clear, so the previous signal can change to YELLOW.

 

So to be correct signal 1 changes RED as the train passes it, signal 2 (last signal back down the line) turns to YELLOW when the last carriage passes signal '1'. and on doing so signal 3, then next one back down the line changes DOUBLE YELLOW, and the one before that changes to GREEN.

 

I have run a program (train program) in RM to simulate this, it is worth trying but, is time consuming getting the timings just right. Each block, the distance between two signals, is either protected because it is occupied or clear (Y,YY or G) because it is vacant or clear, clear proceed witth caution.

 

But, when we get Loco Detection, this is where the fun starts. ;o) All the codes put in the program now to simulate this will be in Loco Detection Sensor information. Train passes sensor, signal changes RED. Last carriage passes same sensor, previous signals change in order Y, next down line YY, next down line G and all done Automatically for us.

 

This will be the power of LD in RM. Trains will run and stop as we command from sensor information to trains, signals, points and a lot more.

Now is frustrating... what is coming is exciting ;o)

HRMS just have to iron out these bugs then, when available, can release Loco Detection for us.

 

ADDITIONAL Note

If you are using 3 aspect signals you will have one step less e.g. instead of Y,YY,G back down the line you will only have Y,G

If you are using 2 aspect signals you will either have Red to stop of Green which will be clear.

 

Hopefully what we have learnt so far and shared will help others, please feel free to comment, and raise any points for discussion that you may see differently.

 

PJ

[PJ_model_trains]

Hi PJ,

I notice you have left the startup position for signal 238 blank. Does this cause RM NOT to set this signal on startup? I have set my TRAINTRONICS signal startup position to zero, because I don't want it to be set on startup, but RM still sets it. I have reported this to HRMS. Also, in the dropdown box for startup position, it only caters for stop or clear. I asked HRMS (by email) whether single yellow and double yellow could be added to this list, but they said they had no plans to do so.

Quote "In most cases a signal will start either red or green (mostly the latter until trains start moving)."

 

I thought I would not pursue this at this time.

Ray

 

Hello Ray

 

Nice to chat again. I have the cell left blank. I also have the System Settings - Set points box unticked.

 

REASONS

1 - Every time you start up every point goes click, click which is a lot of wear and tear on the points. (and no trains run at that point)

2 - Train-Tech signals open up in their last set up position

3 - I am running and testing programs and letting them set the relevant points and signals before setting off

4 - I believe what we do now will be different when we have Loco Detection

 

I did set programs for points and signals in the points and signals but have removed these when testing and running programs. I think it is going to be different for everyone subject to our layouts and I guess we will all try different ways then think of another as we learn. The software is slowly coming into its own and becoming more and more powerful with the various tools we have to use.

 

Going back to item 1 above. If you tick the box to set points at start up it also sets signals. I have asked for HRMS to supply two options in System settings. Set ponts on start up, set signals on start up.

 

Whast I also found was RM would set every point at start up but then I would change then when I tried running routes. So now I have them off. Less wear and tear on the points. Disadvantage there is no grey directional arrow on any points at start up but, If I run train 1 from station A to station B via this or that the program sets the points for the route, or part route before the train sets off and sets the signals on route.

 

Taking this.... Quote "In most cases a signal will start either red or green (mostly the latter until trains start moving)." I agree. No matter what situation when you start up, (I think, these are my thoughts) are that all unoccupied blocks should be green but, if a train or carriages are in a block or two blocks or sidings they should be Red.

 

I may load RM and have a train in a station and lots of others in sidings, all occupied blocks are RED (Sidings are also blocks a section of track between two points controlled by a signal), all unoccupied blocks are Green. That is how I choose to start. So for now Y or YY at start up doesn't matter (I think) But, I am open to suggestions and other peoples thoughts, we are all learning here.

 

PJ

[St1ngr4y]

Hi PJ,

I have a station with 6 platforms on my layout, and platforms 3 and 4 are on the "main" line i.e. those used by non-stop trains. Now this is where I need advice about actual railway practice. Approching the station from the east, I have three 4-aspect signals in a row. I have assumed (rightly or wrongly) that the nearest of these to the station should show red, even if there are no trains on any platform of the station. So, I wanted the other two to show Y & YY respectively. I also have a 4-aspect at the west end of the main line platform, which is set to red for most of the time. If it were green, it would mean that each time a train left the station from one of the other "non-main line" platforms, I would have to set this signal from green to red anyway.

Ray

[PJ_model_trains]

Hi PJ,

I have a station with 6 platforms on my layout, and platforms 3 and 4 are on the "main" line i.e. those used by non-stop trains. Now this is where I need advice about actual railway practice. Approching the station from the east, I have three 4-aspect signals in a row. I have assumed (rightly or wrongly) that the nearest of these to the station should show red, even if there are no trains on any platform of the station. So, I wanted the other two to show Y & YY respectively. I also have a 4-aspect at the west end of the main line platform, which is set to red for most of the time. If it were green, it would mean that each time a train left the station from one of the other "non-main line" platforms, I would have to set this signal from green to red anyway.

Ray

 

Hello Ray

 

It is hard to picture, without a picture.

 

I cannot give you advice on 'actual railway practice' but base my thoughts on the block occupancy principle.

 

If occupied signal RED

If unoccupied signal GREEN unless just before a RED then they would follow the RED with Y, then YY then G

 

If you had 4 blocks including 2 stations and all were vacant, block occupancy says, all should be green.

If a train was in block 2 then signals would be G, R (block 2 occupied), Y, YY

 

Float it on here and see what replies you get, if not sufficient, float it on RM web there are some good guys on there also. Marcus is a train driver, he (and others) helped me when planning signalling.

 

PJ

[PJ_model_trains]

Hello Ray

 

To re-word this a little to make it clearer.

 

The example is based on blocks 1,2,3,4 from left to right

 

and is based on a train going from right to left

 

',' being the signal

 

If a train was in block 2 then signals would be

 

G, (block 2 occupied) R, Y, YY,

 

PJ

[Fishmanoz]

So bit 1 is 1. What about commonalities in other bits or are they all different across the group?

 

 

 

And I have no idea why that might be significant, none at all.

 

 

 

Hi Fishy,

Having downloaded v1.57, and found that this Traintech signal problem still exists, I decided to do some more experimentation. Shortly after 1.56 was released I reported that I was having problems with Traintech 2-aspect signals. HRMS advised me to re-configure them as R8247 decoders, which I did and they have operated satisfactorily like that. This morning I reconfigured all 13 of my 2-aspect signals back to Traintech Colour light instead of R8247, and I created a mini- test program for each one. The addresses of these 2-aspect signals are 102 103 104 105 106 107 108 121 122 123 124 125 126. Three of them didn't work - they behaved in a similar way to the 4-aspects which weren't working - when switched to clear by a program, the signal briefly flashes green, then immediately back to red.

 

Guess which three aren't working....

 

Yes, you go it - the three whose addresses are exactly divisible by four - 104 108 and 124.

 

I've passed this information on to HRMS by email, and hopefully it may help them to resolve the issue.

Ray

 

If divisible by 4, then I think both bits 0 and 1 are 0. Bit 7 is also 0, bits 5 and 6 are 1 and 2, 3 and 4 vary. Again, no idea why this should be significant.

[St1ngr4y]

@Fishy

If it is an 8 bit byte and bit 7 isn't being used as a sign bit, then your first sentence is spot on. However, ALL of bits 2-7 can vary, giving 64 of the 256 values of a byte which are exactly divisible by 4. After all, to divide a binary number by 4, all you do is take a pair of scissors and cut off the last two digits, and what you are left with is the answer. In the old old days of machine code level programming, such an operation would be called a "shift right logical" of 2 bits.

What I can't understand is that these signals work ok when a signal icon is clicked on the layout diagram. The only problem arises when they are operated from within a program. Surely it is the same piece of RM program code which carries out the operation. It has to be a subroutine which is called with two parameters - the address of the signal, and the required aspect.

Ray

[St1ngr4y]

Last night I had a Eureka moment (quiet Graskie!) and I tested out a new theory this morning. What I have discovered is that when a signal, defined as having a Traintech decoder, is operated from within a program, as well as the intended command being sent to the intended signal, RM carries out a second, superfluous action. It zeroises the last two bits of the target address, then sends a signal stop command to that address. This zeroisation of the last two bits of the address effectively changes it to the next lowest exact multiple of 4. If the address is already a multiple of 4, then it explains why I was seeing signals with those addresses briefly changing to the required aspect then immediately back to red. So, I have a signal 104. If I set that to green using the icon on the layout diagram, then run a program which changes any of signals 105 106 or 107, then as soon as that command is obeyed, the target signal changes correctly, but signal 104 is also incorrectly changed to red.

There is an obvious workaround for this problem - ensure you do not have any Traintech signals which have addresses which are an exact multiple of 4 :-)

Ray

[PJ_model_trains]

Hello Ray

 

I have never bothered to look into the binary values, I look at i a bit like my car. I don't need to know how things work under the bonnet, if they work leave well alone. If something goes wrong then go to a garage!

 

Everything you are saying here reflects the same problem I am having and HRMS are, as they say, looking into. But this morning request me to set everything as they have as their system works (divide by 4 I will come back to)

 

My situation is,

- all signals work correctly on their own

- in a sequence the first signal works correctly then down the line all Green aspect are showing Red

 

They have introduced a double click sound when a signal changes which I assume is what you are saying above, zeroisation.

 

My settings were 100, 102, 104, 106 due to a conflict I between 100 & 102 in programming I changed 100 to 238. They are suggesting..... Can you program your signals to 30, 25, 20 and 15 so that we are doing exactly the same thing. Ours work perfectly on this basis using the plan we sent you.

 

100 & 104 are dividable by 4 but if their work 20 is also dividable by 4?

 

I am going to re set my signals as theirs are set and see what happens.

 

I am starting to feel a little pressure here. HRMS say their setup is working so they feel our system (my system) is not set correctly. It is a common senario, they think we are doing something wrong, we feel there is possibly a problem with coding, a small bug and if we are not careful 'blinkers' cause the issue to run on.

 

Because I said I had soldered mine in position, they said, I may have wired them differently! I haven't. I told them, firstly all signals are on the left of the track, secondly when cutting off the signal fingers the short finger became the short wire and the longer to the opposite rail maintaining correct connections. I was asked to change polarity but, they work correctly on theri own, it is obvious that is/was not the issue. They suggested I change the Seq which sets automatically when you choose Train Tech signals and 4 aspect. Naturally as they were correct before changing them everything, including Y & YY were incorrect after the changes.

 

The facts, which have been given to HRMS are clear...

- They are all on the left of the track

- They are all wired in as the finger contacts would be

- The signals work correctly on their own

- the signals didn't work correctly down the line when slotted in to the track, it is the same soldered in situ

- When a signal is changed that works correctly the ones that don't are the sequence changes.

- The issue does not affect the Y & YY only the G being R on subsequent signals

- My set up for the signals is as recommended by HRMS and as detailed on this forum and sent to them

- It is nothing to do with polarity, the signals work correctly on their own

- It is nothing to do with Seq set up the signals work fine on their own

 

The only difference between HRMS settings for 4x 4 aspect Train Tech signals and mine are the settings, CV of each signal, 30, 25, 20 and 15.

 

Although I am happy to try the setting HRMS suggest, I must request HRMS look further in to the issue than just their 4 CV settings. I did wonder about the divide by 4 but have not looked into this and learnt more at this stage, to be honest, like all of us, I want to run my trains and accessories not start studying binary code.

 

Not totally understanding what you are saying, forgive me therefore if I am wrong. As mentioned above setting a CV to 100 and 104 are divisable by 4 but so is 20 in HRMS example?

 

I am now getting frustrated. I am very patient and expect a few small issues but are now starting to feel HRMS are more or less saying, without saying it, our code is right, the signals work for us, it must be your system. I will try your recommendation HRMS, please also try my set up using 100, 102, 104 & 106. You may prefer to wait for my reply before you do but don't just think one set of 4 CV codes works so all CV setting should work.

 

PJ

[St1ngr4y]

Hi PJ,

Don't let my "multiple of 4" scenario cloud your issue. Bear in mind that I only have a problem when the signals are set by a program. They work fine when the icon is clicked, even the new feature introduced at 1.57. If a 4-aspect signal is showing single yellow, a long click on the icon, after a second or two a noise is sounded, and when you then release the click, the signal changes straight to red.

Also, I am not using the "set other point/signal" facility which you are finding troublesome.

Ray

[PJ_model_trains]

Hi PJ,

Don't let my "multiple of 4" scenario cloud your issue. Bear in mind that I only have a problem when the signals are set by a program. They work fine when the icon is clicked, even the new feature introduced at 1.57. If a 4-aspect signal is showing single yellow, a long click on the icon, after a second or two a noise is sounded, and when you then release the click, the signal changes straight to red.

Also, I am not using the "set other point/signal" facility which you are finding troublesome.

Ray

 

Hello Ray

 

You say the signals work fine when the icon is clicked. I say the same for every signal.

 

I have come away from the set point signal to concentrate only on signals, minimising problems.

 

If you take a rake of signals in a row, each programmed individaully to change previous signals the issue is always the same. The signal you click works fine. The Red and Green in previous signals are reversed. But, the Yellow and Double Yellow are not affected.

 

It is correct from RM to the screen but incorrect from RM to the signals (on previous signals not the one clicked)

 

PJ

[PJ_model_trains]

Here are the results of today's test using a layout and signal set file supplied HRMS

 

 

 

I list it for others to see, maybe someone may see something no one else has or comment on one of the following.

 

 

 

1 - problem of Green Aspect signal shows Red for all subsequent signals (see below)

 

 

 

2 - some points click on my full layout when a signal is changed, it only happens if signals are set with two digit code, it doesn't happen if Points are set up to 99 and signals over this as three digit codes?

 

 

 

Signal 15 fires Point 15, but only on Y or YY not on R or G??? Neither have any other programming for signal or points?

 

 

 

Signal 20 fires Point 20, but only on R or G not on Y or YY? Neither have reverse polarity set or have any other programming for signal or points?

 

 

 

Signal 25 doesn't fire a point but there isn't a Point set at 25

 

 

 

Signal 30 fires Point 30 but only on Y not on R, YY or G???

 

 

 

RESULT OF SIGNALS TEST TODAY

 

 

 

RM to SCREEN

 

30 --- 25 --- 20 --- 15

 

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

 

 

 

RM to SIGNAL

 

R ----- Y ----- YY ---- R (same error G is Red?)

 

 

 

Click Signal 30 once

 

RM to SCREEN

 

30 --- 25 --- 20 --- 15

 

Y ----- YY ---- G ---- G

 

 

 

RM to SIGNAL

 

Y ----- YY ----- R ---- R (same error both G's are Red?)

 

 

 

Click Signal 30 once

 

RM to SCREEN

 

30 --- 25 --- 20 --- 15

 

YY ---- G ---- G ---- G

 

 

 

RM to SIGNAL

 

Y ------ R ----- R ---- R (same error ALL G's are Red?)

 

 

 

Click Signal 30 once

 

RM to SCREEN

 

30 --- 25 --- 20 --- 15

 

G ---- G ---- G ---- G

 

 

 

RM to SIGNAL

 

G ---- R ----- R ---- R (same error ALL G's after the one changed are Red?)

 

 

 

Click Signal 30 once

 

Returns to first stage.

 

 

 

There is another problem using the numbers you have used, this was mentioned in the early stages. When changing a signal sometimes points click even though a point may not have the same number. I have noticed it again this afternoon after making the changes you requested.

 

 

 

This was why I used up to 99 for points and over 100 for signals.

 

 

 

Report sent to HRMS

 

 

 

Frustrating for us all

[PJ_model_trains]

Reconsidering my comments above...

 

... maybe someone may see something no one else has

 

I guess there are many sitting on the fence here until everything is sorted out, there are probably not many members with Train Tech 4 aspect signals

 

I have just had a thought... I have a load of 3 aspect signals on the layout as well, I will test them, the difference should be the same with the exception of the YY

 

PJ

[PJ_model_trains]

L@@k at this!!!

 

 

 

After setting the 4 aspect signals to your plan and your settings, I then though try the 3 aspect signals but, kept the row of 4 signals.

 

 

 

Very Interesting

 

 

 

Here are the results

 

SIGNALS

 

 

 

RM to SCREEN

 

195 --- 185 --- 138 --- 132

 

R ------ Y ------- G ----- G

 

 

 

RM to SIGNAL

 

R ------ Y ------- G ----- G

 

 

 

 

 

RM to SCREEN

 

195 --- 185 --- 138 --- 132

 

Y ------ G ------- G ----- G

 

 

 

RM to SIGNAL

 

Y ------ G ------- G ----- G

 

 

 

 

 

RM to SCREEN

 

195 --- 185 --- 138 --- 132

 

G ------ G ------- G ----- G

 

 

 

RM to SIGNAL

 

G ------ G ------- G ----- G

 

 

 

Every one works perfectly ;o)

 

 

 

This is good news for 3 aspect, I still feel there is a minor bug in the code for RM to signal for 4 Aspect signals changing the Red and the Green only, and only on subsequent signals down the line

 

 

 

HRMS informed.

 

 

 

PJ

[St1ngr4y]

Hi PJ,

Going back 3 posts....

 

"Signal 15 fires Point 15, but only on Y or YY not on R or G??? Neither have any other programming for signal or points?

 

Signal 20 fires Point 20, but only on R or G not on Y or YY? Neither have reverse polarity set or have any other programming for signal or points?"

 

Are you saying at this point that you had some points with the same addresses as signals? If so, I can explain signal 20 but not signal 15.

To operate R G it will use address 20, but to operate Y YY it will use address 21.

Are you sure its the other way around with signal 15?

Ray

[PJ_model_trains]

Hi PJ,

Going back 3 posts....

 

"Signal 15 fires Point 15, but only on Y or YY not on R or G??? Neither have any other programming for signal or points?

 

Signal 20 fires Point 20, but only on R or G not on Y or YY? Neither have reverse polarity set or have any other programming for signal or points?"

 

Are you saying at this point that you had some points with the same addresses as signals? If so, I can explain signal 20 but not signal 15.

To operate R G it will use address 20, but to operate Y YY it will use address 21.

Are you sure its the other way around with signal 15?

Ray

 

Hello Ray

 

Firstly to confirm... the ONLY reason I have used 30, 25, 20 & 15 ID for signals is because HRMS requested I changed mine to match theirs, for the testing the R & G sequence problem so we both are testing with the same settings.

 

Up until then I have set points under <=99 and signals >99 so as not to have any chance of a conflict.

 

It was only after altering then to check is they worked (4 aspect) that I realised the points were changing or trying to change as well.

 

Once HRMS are finished I will alter them back again.

 

I have just pressed the signal icons

 

> Signal 15 fires Point 15, but only on Y or YY not on R or G???

 

So this will be correct as 14 would work on R or G and 15 on Y or YY (If I am understanding you correctly)

 

> Signal 20 fires Point 20, but only on R or G not on Y or YY?

 

So that is correct Signal 20 fires point 20 when R & G is pressed

 

The above I was not aware of until now, thank you. Having said that, the points firing with the signal is probably not an issue as it was only done at HRMS request to carry out the test and I will change them again later.

 

PJ

[PJ_model_trains]

The interesting thing (I think)

 

Is the problem with signals is only, R & G crossing over, showing the opposite, with 4 aspect signals on the layout (RM to signal)

 

But 3 aspect signals work perfectly. (RM to screen and RM to signal)

 

PJ

[Fishmanoz]

Ray, the reason only those few bits changed was the very restricted range of signal numbers you had. Overall, you are right of course. And yes, I know about shift registers, although I learnt it nearly a lifetime ago now. I even learnt about the hardware to implement them, not just what they did. It's a pity we are stuck with 10 fingers and toes, two would have been much simpler by the time we got to computer programming and hardware.

 

Will be be interesting to see the resolution. Your workaround is fine but seems HRMS has a coding bug to find and fix. Otherwise, more are going to have this problem and have no idea why or how to fix it.

[PJ_model_trains]

Ray, the reason only those few bits changed was the very restricted range of signal numbers you had. Overall, you are right of course. And yes, I know about shift registers, although I learnt it nearly a lifetime ago now. I even learnt about the hardware to implement them, not just what they did. It's a pity we are stuck with 10 fingers and toes, two would have been much simpler by the time we got to computer programming and hardware.

 

Will be be interesting to see the resolution. Your workaround is fine but seems HRMS has a coding bug to find and fix. Otherwise, more are going to have this problem and have no idea why or how to fix it.

Hi Fishy

 

That is my real concern. HRMS seem so convinced my set up is not right, if they do not find the bug and fix it the problem will escalate. After Christmas there will no doubt be new members to the forum, all coming with problems. We are sympathetic and helping try sort the issues, often new comers are not as patient. It would be sad to see so many people come in to the hobby and get off to a bad start. The other side of the coin for us is, if they don't fix these issues Loco Detection will continue to be delayed.

 

PJ

[PJ_model_trains]

 UPDATE of TRAIN-TECH SIGNALS IN RM  

 

The following message has just been sent to HRMS in reply to their email to me Christmas Eve and after installing RM v1.59 and testing the signals. They hoped the problem was fixed!  

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 

NOT GOOD NEWS - THINGS ARE NOW WORSE!!!  

 

I have so far only checked 4 aspect signals, 3 aspect were working correctly (I have not checked these yet)  

 

Signal 1 - a 4 aspect Train Tech signal  

 

Set up from within RM using pre-set settings when choosing 4 aspect signal from drop down list  

 

Seq 1 - Port 253 - Red

Seq 2 - Port 253 - Green

Seq 3 - Port 254 - Red

Seq 4 - Port 254 - Green  

 

RESULT >>>>> Signal Changes as follows  

 

RM - Red ------------ Signal - Green

RM - Yellow -------- Signal - Yellow

RM - Dble Yellow - Signal - Dble Yellow

RM - Green --------- Signal - Red    

 

I TRIED reversing the settings as follows on another 4 aspect signal  

 

Seq 1 - Port 251 - Green

Seq 2 - Port 251 - Red

Seq 3 - Port 252 - Green

Seq 4 - Port 252 - Red  

 

RESULT >>>>> Signal Changes as follows  

 

RM - Red ------------ Signal - Red

RM - Yellow -------- Signal - Dble Yellow

RM - Dble Yellow - Signal - Yellow

RM - Green --------- Signal - Green  

 

So where are we now with 4 aspect signals?  

 

- They were working correctly on their own but not in sequence

- Now they are not working correctly on their own???  

 

There is a fault reversing the Red and Green OR the Yellow and Double yellow   This is now much worse, they were working individually but not in sequence, now they are not working individually correctly  

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 

Oh dear, this has really dashed my hopes for LD, they were confident the update would fix the problem but it is now worse.  I have not given up hope ut can see why it was not put in the 2015 new products list. These problems must be sorted first, I have confidence they will be.    

 

PJ

[PJ_model_trains]

I have carried out further tests using programming and have written to HRMS as follows  

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 

Hi  

 

ADDITIONAL INFORMATION  

 

I have carried out another test using 4 aspect signals, this time using a program that calls each signal aspect colour as a train or last carriage pass.  

 

This method still works correctly  

 

The software needs reverting to how it was prior to these changes being made, the signals will then work on their own in the right sequence, but not in sequence down the line.  

 

The yellow and double yellow worked correctly down the line in sequence but the red and green were showing opposite colour aspects on the signals on the layout although correct on the screen in RM  

 

This tells me, you almost had it right before this update, there is a bug, a cross over in code for the red and the green, not in RM on the screen, not for the individual signal but when the code is changing signals down the line.  

 

I know it sounds simple but, I believe that is all it is. Finding the problem in the code and the loops and loops of code is another matter but we have, I think, narrowed it down to the path of code for subsequent signals and it is only the red and green that is called for wrongly in the code  

 

Please keep me informed, if there is anything you want me to test please feel free to ask  

 

Kind regards  

 

PJ