Thames Trent Signalling

There is a query on the Elvas Tower forums as to whether Thames Trent signalling still has a problem in Open Rails.  Has it?

No idea sorry i removed OR, when it became obvious that UK semaphore signalling was not a high priority.

I visit Elvas Tower daily but don't remember reading anything about any changes being made, to rectify the incorrect functionality of same.

Mike.

Re-installed OR earlier today, to have a look at the Potteries Loop Line route.

Same problem with the combined semaphore signals exists on the PLL.

So i am assuming both routes use the same semaphores.

So nothing changed, fixed in OR.

Mike.

IsambardKingdomBrunel wrote:Re-installed OR earlier today, to have a look at the Potteries Loop Line route.

Same problem with the combined semaphore signals exists on the PLL.

So i am assuming both routes use the same semaphores.

So nothing changed, fixed in OR.

Mike.

Mike, could you please provide details of the signal problems on Potteries Loop Line.

David,

I have only briefly run the PLL, but there seems to be the same problems as Thames - Trent.

Where the combined Home\Distant semaphores only function correctly in regards the "Home" arm.

Distant never comes off, regardless of the next signals indication.

That is what i was seeing on Thames - Trent and seems to be the same in regards the PLL.

Mike.

Just to add, I'm running the latest version of ORTS and it still seems to not quite work with UK semaphores. On TTv2 I'm currently doing a run from Bedford to Market Harboro' via N'pton - on approaching Turvey the distant was "off" but the home signal on the end of the platform was "on" until my train came to a stand (that was on the second try, on the first attempt I had a SPAD due to wrestling with the vacuum brakes ). It appears to me as if it's not seeing the distant as an "approach" (to use American terminology) while simultaneously not clearing the route more than one section ahead.

Are you saying the distants never come off or only at certain locations? When Pat Dalton created his S & C route it was noted that at certain locations the distant never cleared. This was due to what I referred to at the time as the blue tile syndrome. The sig.dat files for semaphores are set so that a distant looks for the next distant in advance and if the distant in advance is on the next tile the first distant will not clear. Stop signals with an invisible distant dummy were created, these were used in the S & C route to get around the problem. Whether or not the authors of the two routes in this thread used these in their routes I would not know (I don't have the routes in question), but if they didn't then that wouldn't help matters when running under OR.

John

It does seem to be certain locations, I didn't get the problem at Olney but it manifested again at the subsequent stops - Northampton (Bridge Street and Castle) then Pitsford. However as soon as the train comes to a stand in the platform the signal clears, so whether it's somehow timetable related I couldn't say.

Hi Vern
To prevent the station exit signals from being at stop as you approach, make sure that "Forced red at station stops" is not selected - this is in the "Experimental" tab in "Options".

Cheers,
Ged

Excellent, have now unticked that along with superelevation.

Edit: Well despite having unticked the forced red at station stops, still occurring along the Northampton to Market Harborough line with another SPAD for yours truly at Lamport. (If I was a real driver, I would be shuffling off down the dole office by now!). As a control, I'll try next a run on the semaphore part of London South East, either down the Oxted line or across from Tonbridge to Redhill.

Not been able to test on LSE as on starting the Cannon Street Parcels run, I can't get the train to budge! Brakes (including loco) released, throttle on the Class 33 revs up but no movement from the train. I'll try another trainset.

I always seemed to get the opposite with any UK route that has semaphore signals in use. Distant is always on, particularly in a combined Home\Distant configuration.

But the next Home would be off. I have been back and fore with OR, but nothing ever seems to get done.

Please correct me if i am being over critical. But there seems to be a US bias in regards OR and Elvas Tower.

Hi,
I think you are correct!
There have been the occasional posts regarding distant signals, but as you say, nothing seems to get done about it! It could be that there are no programmers with the appropriate expertise currently on the team.
I would also like to see vacuum brakes correctly implemented.

Cheers,
Ged

I was a bit unsure about posting my thoughts on the signalling.

I did the same over on Elvas Tower about 2 years ago and was told it's easy enough to mod the scripts yourself.

I know how they work in the real world, but do not have a clue about MSTS signal scripts.

Completely agree with you on vacuum brake implimentation.

If these two things were sorted out. I would quite happily remove, TS2017 and TANE from the pc and only run OR.

Mike.

Dear sirs,
as an Open Rails developer I am obviously sorry when I read that OR is not used because of problems with UK routes.
After a further mention about such problems by David Forrest in the ET forum I had a first investigation, to see if there are solvable problems. I asked support by a swiss OR and MSTS signal expert (eugenR in the ET forum), and got from him an excellent help.
I started with OldVern's case described in his post of October 10th, 2016, because it is precisely described.
I downloaded the TT2 route (about 30 hours without Premium account...) and created a test activity from Bedford towards N'pton, putting a static consist after the Turvey platform.
Using OR release 1.1 (corresponding to x.3487) in fact the distant stays green, which is not correct, see picture Occupied_line_1_1.jpg.
However with x.3538 a correction has been inserted referring to distant signals, which was triggered by a report of a UK content developer.
So I tested the actual OR "experimental" version x.3667. This version works correctly, see picture Occupied_line.jpg with jellow distant (sorry to speak about colours and not states).
As a further proof I modified the activity by removing the static consist. The state of the distant (again with x.3667) can be seen in picture Free_line.jpg: it is green, which is correct.
These tests were made with option "Forced red at station stops" unchecked. If the option is checked, you will get a red at the station starting signal and therefore the distant must be yellow. I tested als this with version x.3667, and it works.
So, this case reported by OldVern has been corrected in actual "experimental" OR versions accordingly to my tests.

Now to the opposite case: accordingly to other posts in the forum there are also cases where the distant stays yellow ("on") even if it shouldn't.
I would be happy if also here a test case in TT2 could be identified by someone of the  forum members, as OldVern did with the above case, so that I could check it. There is already a first hypothesis also for the origin of this problem. I'll describe it shortly here, however people not interested in signal files can stop reading here for the time being.

Looking at the sigcfg.dat file, there are some NORMAL signals that have SignalNumClearAhead ( 1 ). Accordingly to tests made by another OR developer, it seems that, independently from the SignalNumClearAhead parameter of a specific signal, MSTS applies to all signals the highest value of SignalNumClearAhead it finds in the sigcfg.dat file for the NORMAL signals used in the route. OR istead obeys literally to such lines. So, if e.g. the distant is followed by some NORMAL signals, and if the first one after the distant has SignalNumClearAhead ( 1 ), it may occur that when the train reaches the distant, the last NORMAL is not yet cleared (it will be cleared only when the train will pass the first NORMAL), and in this case the distant will always be "on".
To avoid this OR offers a solution: a subfolder Openrails must be created within the route's folder (in this case Thames_Trent_Version_2). Within such folder the signal files must be copied, that for such route are  sigcfg.dat, sigscr.dat,and sigscr-UK-RI.dat. Then within sigcfg.dat the SignalNumClearAhead parameters for the NORMAL signals must be increased. For first trials I created a version where all SignalNumClearAhead instances are set to 4, that is the maximum value found in the sigcfg.dat file. This file is attached there for first tests. OR will consider the signal files present in the Openrails subfolder, while MSTS will continue using the standard signal files present in the route's folder.

I hope to get positive feedback

Carlo

21/11/2016: corrected wrong reference to sigscr.dat instead of to sigcfg.dat

Hi Carlo,
Thank you for your very detailed reply

I am, unfortunately, not able to help currently, due to having another project "on the stocks". I'm sure you'll get plenty of help/feedback on this problem, but, if not, I'll be able to look at Thames Trent in a few weeks.

Thanks, also, for the great work you and the team are doing with Open Rails!

Cheers,
Ged

Hi Carlo,

Many thanks for your detailed post and sigscr.dat file. I am currently working on modifying one or two of my activities to work better with Open Rails and, like Ged, will try your solution soon. I presume that this will work with other routes as well? I am well used to inserting an Openrails folder within engine folders to enable the engine to work better with Open Rails whilst retaining the original when using MSTS.

Regards,

Stephen

Ged and Stephen, thank you for your replies.
Stephen, nice to read that you are adapting activities for Open Rails. Later maybe you will also take profit of the additional features OR allows in activities.
Yes, modifying NumSignalsClearAhead within the sigcfg.dat file to get better matching with MSTS interpretation of such parameter can be performed also for sigcfg.dat files of other routes.

Carlo

Hi Carlo,

Sorry, I should have mentioned that I do use the additional functions available in OR - these activities when uploaded are placed in the UKTS Open Rails category.

Regards,

Stephen

Hi Carlo,

I had already applied the fix above for making Home signals look further ahead (ie. SignalNumClearAhead ( 4 )) having seen the correspondence on the ET forum.  It works well enough.  

However, I have looked at the whole issue of semaphore signals afresh since seeing this thread, and it seems to me that there remains a problem when Distant signals are present, particularly when there are both Home and Distant on the same signal post.  Like you, I have used Thames-Trent v2 to test, and initially I am using a simple activity with no AI, so no part of the track is 'blocked'.  When a combined Home/Distant signal (Signal 1) is encountered, the Home arm (Head 1) is shown as Off (clear), but the next Home (Signal 2) is shown as On (Stop), so the Distant arm of the combined signal (Head 2) is shown as On (Caution).  When the combined signal is passed, the next signal (Signal 2) comes Off and the route is clear.  It responds as if the value of SignalNumClearAhead for Signal 1/Head 1 is read as '1' (or perhaps not being read at all).  I have studied the sigcfg.dat file to see whether an edit can solve the problem, but Head 1 seems to 'point' to SigSubSType ( "BR_M_TubHome" ), which has SignalNumClearAhead ( 4 ).  So I can't see an easy way to fix it with an OR sigcfg.dat file.  This seems to be true of combined signals on either a post or a gantry.

In addition, it would be good if Distant signals were to be shown in Track Monitor (key: [F4]), so that the Monitor can show a Caution (as it can with colour light signals).  So a combined signal could show as Clear (green = both heads Off), Caution (amber = Home head Off, Distant head On), or Stop (red = both heads On).  In the example above, the Track Monitor shows green = Clear as defined by the state of the Home head, and taking no account of the state of the Distant head. A Single Distant could be shown in the Monitor as Clear (green = Off) or Caution (amber = On).

I hope first that this makes sense, and second that a fix can be found.

Regards

Martin

Hi Martin,
thank you for clarifying the remaining problem.
Can you please point me to a place in the TT2 route where this can be seen? So I'm sure I will see the issue.

Thank you and regards

Carlo

Hi Carlo

I can't recall if the standard TT2 download included activities, but if so the activity Leicester to Clay Cross MML with DMU Class 127 will show the problem just about a mile after leaving Leicester London Road, at the end of the platform at Leicester Humberstone Road. If not, any short route North from Leicester London Road will do.

Hope this helps

Regards

Martin

Yes, it helped, thank you. I could reproduce the problem. Now let's hope to get something out of the analysis of the case.

Regards

Carlo

Thanks for this, Carlo. I also hope you can get to the bottom of the problem.

I wish I knew enough (ie. anything) about the programming behind OR so that I could look under the bonnet myself.

Regards

Martin

As a long-standing creator/builder/author, what-you-will, of freeware semaphore signal kits I have resurrected my old signal test route to carry out a few tests. The test route is very basic, just track, no scenery or otherwise installed and was used in the past to test all my signals.

I installed signals, as follows; distant, home, starter, outer starter and distant with stop signal set to SignalNumClear ( ? ) varying values 1 thru 4, such that they can all be seen from the same viewpoint.

The test activity, a locomotive run past the signals, for MSTS was run with settings of 1, 2, 3, and 4 respectively with the following results:

( 1 ) Distant ON, Home OFF, Starter ON, Outer Starter ON
( 2 ) Distant OFF, Home OFF, Starter OFF, Outer Starter ON
( 3 ) Distant OFF, Home OFF, Starter Off, Outer Starter OFF
( 4 ) Distant OFF, Home OFF, Starter ON, Outer Starter OFF

A similar test activity was run in OR without an Openrail folder, and repeated with an Openrail folder (no changes made to .dat file).

In all three cases, MSTS and two OR tests, the results were identical.  

It would seem that there is something in a route that has scenery, built in MSTS, that screws up the signalling, TT2 is not the only route. I could be totally wrong but can only report what one finds.

John

Hi John, that's quite interesting, and that's the way we wanted to check too. I wonder whether the problem is the tile boundary (in the faulty case the starter+distant is just before a tile boundary, and next signal is in the subsequent tile. Checks and hypotheses are going on.

Carlo

Carlo,

If that's the case, does the fault manifest itself in MSTS as well as OR? It was the first thing I thought of at the beginning of this thread. My test route needs to be extended across a tile boundary and further tests carried out with/without dummy distants installed.

John

John,
in the meantime my swiss "helper" has also built a test route, which I attach here (I haven't tested it yet, I just received it). There are two small test activities: with one (Testzug) the train runs on the left track, where things are OK. With the other one (Fehlertestzug) the train runs on the right track and the problem appears. The problem appears only if the distant signal head is together with a NORMAL signal head (on the same signal) and at the same time such signal distant uses the multi_dist function. If the distant is alone, the problem does not occur. So now the reason for that has to be investigated. Tile boundaries seem not to play a role.
The test route can be downloaded from here http://www.interazioni-educative.it/Varie/CHTest.zip .

Carlo

Carlo,

Single distants can be affected as I found on a commercial route (BATS Stapleford Vale) which I originally signalled. The home signal in this case is a stop with siding i.e. a junction signal with respective arms set by links.

I have created a similar set up in my test route and similar happens, distant firmly ON, it would seem that OR doesn't like jct signals. I also installed a similar layout as in the original test, but with the last distant the other side of a blue tile boundary, MSTS was as expected displaying first distant ON, but in OR it was OFF, so it would seem that blue tile syndrome doesn't affect distants in OR, but I did find that if the train is stopped either before the distant or at one of the stop signals all signals go ON.

John

Hi all,
with the support of Eugen I have prepared a beta version containing some patches for the problems with the distant signals. At least the test cases work correctly now.
You are welcome at replacing in release x.3674 simulator.dll with the attached one, and to test its operation in the TT2 route or other ones, so that it can be decided whether the new version is worth uploading or not.
The tests have to be performed using the modified sigcfg.dat (see my post dated November 19th) together with the here attached file.

Carlo

5/12/16: runtime file removed because patch uploaded

Hi Carlo

Thanks to you (and Eugen) for this. So far, so good. It appears to work as required. I will continue testing other scenarios, but it's looking good (apart, perhaps, from having distant/caution indication in the track monitor window - but I can live without this).

Regards

Martin

Thanks very much Carlo & Eugen,

so far i find the distant and combined home\distant signals are all working as i would expect them to do.

Huge improvement on how the Thames Trent v2 signals worked before.

Excellent work guys.

Mike.

Martin and Mike, thanks for having tested this.
The fix has now been uploaded in release x.3679.

Hi Carlo

I believe a recent update may have disabled the experimental "forced red at station stops" feature, but only for semaphore signals. This may be connected with this fix, since the feature still seems to be present as normal in colour light signal routes (eg MEP). I will continue testing, but in the meantime does anyone else have any observations?

Martin

Hi Martin,
I'm quite busy now updating the manual in view of the official release 1.2, that should come within not too long time, so I have hardly time to cope with other issues.
However, even if with software you never know, I don't see connections between last OR modifications and the behavior of the feature you mention. Are you performing testings with various OR versions, to see whether you find out that the problem effectively appeared after a specific version?

Carlo

Hi Carlo

Thanks for your reply. No, I haven't yet tested different OR versions to try to see when the problem crept in (if at all), but that is next on my agenda. I posted to give a 'heads-up' and to invite others to comment on their experiences.

Martin

PS - looking forward to 1.2 - grewat work by all the dev's.

Csantucci wrote:Martin and Mike, thanks for having tested this.
The fix has now been uploaded in release x.3679.

Noticed it was now included thanks Carlo.

Much appreciate your time and effort to get it sorted.

For me the forced red is not realistic so i never use the option.

Many thanks,
Mike.

Hi

I can now confirm that the "forced red" feature has not been adversely affected by a recent update. I have tested using (very) old versions of OR and they respond in the same way as the current experimental version. In the old versions the feature, however, is somewhat disguised by the distant/home problem that this thread refers to. The problems I am experiencing must be a function of the route, eg the placement of the signals relative to points (switches) or platform markers, or perhaps the construction of the signals themselves.

Anyway, thanks for your comments. Merry Christmas to everyone

Regards

Martin