[Coolhand101]

I've been resignalling parts of a route that use color and semaphore distant signals.

I've scripted a "repeater" signal ( coming from absolute block to 3 or 4 aspect T.C.B ), to show one yellow if the next stop signal is red or green, if the next stop signal is showing a proceed signal, just like a banner repeater.

I seem to be having a slight problem with the colour light and semaphore distant signals.

Example one.

Distant off --- home off ---- starter off :
Works as intended.

Example two.

Distant off --- home off ---- starter off ---- advance starter on :

Distant should be on but is off!

Example Three.

Distant off --- home1 off ---- home2 off --- starter off ---- advance starter on :

Distant should be on but is off!

Example Four.

Distant on ---- Main Home(CLR2)off +Branch home( CLR1)on --- starter off :

Distant should be OFF but is on!

Example Five.

Distant on ---- Main Home(CLR2)off +Siding shunt( CLR1 or RESTRICTIVE)on --- starter off

Distant should be OFF but is on!

Any ideals ?

Thanks

[Jovet]

You're referring to the behavior of Open Rails? Or MSTS?

[Coolhand101]

jovet, on 12 February 2016 - 07:45 PM, said:

You're referring to the behavior of Open Rails? Or MSTS?

Open Rails.
In MSTS, the distant would not clear unless all the stop signals were clear up until the next distant signal.
I know OR will not clear the distant if the route is signalled to a dead end bay, i assume this should also be the case if under restricted signals as well.
Thanks

[emufarmer]

Hi, It looks like there are to many miles between the Advance Starter and the Distant Signals, I had my Sig scrip rewrote with a Dummy Distant added and placed it in the long gap, it seems to be the same as the Point nods to far apart, I think the MEP route has these Dummies in it.

Frank

[Coolhand101]

emufarmer, on 13 February 2016 - 08:55 PM, said:

Hi, It looks like there are to many miles between the Advance Starter and the Distant Signals, I had my Sig scrip rewrote with a Dummy Distant added and placed it in the long gap, it seems to be the same as the Point nods to far apart, I think the MEP route has these Dummies in it.

Frank

Hi

The distance between the advance starter and the next distant is fairly short.

I had to add a dummy distant just past one of the advance starters, as the next signals was a 2-CL aspect 'repeater' and a 3-CL aspect signal. Without the dummy distant, the distant for the signals before would remain 'ON' as per MSTS. I knew in advance of that problem.

I shall continue testing on this matter.

Edit
I should add that in examples 4 and 5. The distant will clear if I replace the home+branch and home+sidings signals with a standard home semaphore signal.

Thanks

[Jovet]

emufarmer, on 13 February 2016 - 08:55 PM, said:

Hi, It looks like there are to many miles between the Advance Starter and the Distant Signals, I had my Sig scrip rewrote with a Dummy Distant added and placed it in the long gap, it seems to be the same as the Point nods to far apart, I think the MEP route has these Dummies in it.

The MSTS distance limit is 20 km. OR's is considerably shorter (I think 8, but don't quote me). You guys have routes with distant signals 8 km from the first home signal...?

[Jovet]

Coolhand101, on 13 February 2016 - 02:53 AM, said:

In MSTS, the distant would not clear unless all the stop signals were clear up until the next distant signal.

That is the way the dist_multi_sig_mr() function is supposed to work.

Once faucet of that function which I've confirmed does not work correctly in OR is that, in MSTS, any signal head/arm which is linked to a track route beyond it is supposed to be ignored if said route is not traverse-able. But such signal heads are not ignored in OR's processing.

Coolhand101, on 13 February 2016 - 02:53 AM, said:

I know OR will not clear the distant if the route is signalled to a dead end bay, i assume this should also be the case if under restricted signals as well.

This would be a mimic of MSTS behavior, where a non-existent signal head is treated as if one is showing STOP. Since there are no more signals on a dead-end track, for example, the Distant looking down that track sees a "Stop" indication from a signal that is not really there. Not that you'd want to, but this could be changed by putting a real signal on that dead-end track.

[Coolhand101]

jovet, on 14 February 2016 - 09:43 AM, said:

You guys have routes with distant signals 8 km from the first home signal...?

I believe thats 8 km between the starter and the distant for the next block. The distance between the Distant signal and the first home signal, should be based on line speed and braking distance.

Does OR count back facing signals ? I have a few ground shunt signals that are placed like this.

I have also notice the 'SignalNumClearAhead' also have an impact. Some of my home signals had this set at 1 and 3. After reading on here about this parameter i'm still unsure what to set this to for semaphore signals. I have also seen this parameter used on a semaphore and colour light distant signals, adding to more confusing about this parameter.

As to why the distant will not clear for a main signal that has an associated shunt signal with a 'CR_1' or 'Restrictive' function, even though this signal has a 'clear_2' for the main line is another mystery. Clear_2 is what the distant signal should see and should be 'off'. If i replace that signal with a normal semaphore with just a 'stop' and 'clear_2', the distant is 'off'.

I'm hoping the distant is not confused by having two heads for the same home signal, ie

HEAD1 for mainline
HEAD2 for the branch or sidings.

Thanks

[Jovet]

Coolhand101, on 14 February 2016 - 11:04 AM, said:

I believe thats 8 km between the starter and the distant for the next block. The distance between the Distant signal and the first home signal, should be based on line speed and braking distance.

Ahh, I guess I could see how a long distance from Starter to Distant could be a problem, as far as detecting occupancy. I do not know if OR stops checking occupancy after 8km also, or if that 8km is limited to the signal LR/MR functions. I assume that a Starter signal does not care what the aspect of the subsequent signal is, though.

Coolhand101, on 14 February 2016 - 11:04 AM, said:

Does OR count back facing signals ? I have a few ground shunt signals that are placed like this.

I wish I were more familiar with the source code, but I've never seen this behavior occurring myself.

Coolhand101, on 14 February 2016 - 11:04 AM, said:

I have also notice the 'SignalNumClearAhead' also have an impact. Some of my home signals had this set at 1 and 3. After reading on here about this parameter I'm still unsure what to set this to for semaphore signals. I have also seen this parameter used on a semaphore and colour light distant signals, adding to more confusing about this parameter.

I would set it to 2 or 3, myself. But I use 5 for everything. Even on the absolute-block-style signaling I've programmed, I kept it at 5 and haven't noted any problems. But that's probably not the most efficient for junction contention, either.

Coolhand101, on 14 February 2016 - 11:04 AM, said:

As to why the distant will not clear for a main signal that has an associated shunt signal with a 'CR_1' or 'Restrictive' function, even though this signal has a 'clear_2' for the main line is another mystery. Clear_2 is what the distant signal should see and should be 'off'. If i replace that signal with a normal semaphore with just a 'stop' and 'clear_2', the distant is 'off'.
I'm hoping the distant is not confused by having two heads for the same home signal...

Splitting signals would be subject to the same problem I outlined above, where OR doesn't disregard signal heads/arms linked to a track that isn't drivable, assuming all of the heads/arms are of the NORMAL type. Since the (NORMAL) Shunting signal isn't being ignored, and presumably is set to Stop, the Distant signal still sees that and acts accordingly. A possible test or workaround might be to make the Shunting signal actually a SHUNTING type and see if that helps. The dist_multi_sig_mr() function still needs to get fixed, though.

[Coolhand101]

jovet, on 14 February 2016 - 11:31 AM, said:

I would set it to 2 or 3, myself. But I use 5 for everything. Even on the absolute-block-style signaling I've programmed, I kept it at 5 and haven't noted any problems. But that's probably not the most efficient for junction contention, either.

Okay i will set A.B home signals to 3 or above!

jovet, on 14 February 2016 - 11:31 AM, said:

Splitting signals would be subject to the same problem I outlined above, where OR doesn't disregard signal heads/arms linked to a track that isn't drivable, assuming all of the heads/arms are of the NORMAL type. Since the (NORMAL) Shunting signal isn't being ignored, and presumably is set to Stop, the Distant signal still sees that and acts accordingly. A possible test or workaround might be to make the Shunting signal actually a SHUNTING type and see if that helps. The dist_multi_sig_mr() function still needs to get fixed, though.

I never thought about using the 'SHUNTING' type. I test that later.

Thanks

[Coolhand101]

Adding the sidings signal arm on the main signal to type 'shunting' allowed the distant to be 'off', when all the main signals are cleared. But when the shunt arm is off, the main signal shows on, which is correct, but also red on the track monitor and the train emergency brake applies when the signal is passed.

If it's a script problem, this should also apply to the distant when the siding signal type is 'normal' under MSTS. I will try this on MSTS next.

All works 100% in MSTS, distant off with sidings arm as type 'normal'. Also with signals that have Home and branch heads as well.

Thanks

[Jovet]

Coolhand101, on 18 February 2016 - 04:08 AM, said:

Adding the sidings signal arm on the main signal to type 'shunting' allowed the distant to be 'off', when all the main signals are cleared. But when the shunt arm is off, the main signal shows on, which is correct, but also red on the track monitor and the train emergency brake applies when the signal is passed.

Yeah, I guess that could be a problem. LOL My suggestion wasn't a very good one. Well, it half-worked. That behavior is exactly as it should be, and doesn't solve your problem.

Coolhand101, on 18 February 2016 - 04:08 AM, said:

All works 100% in MSTS, distant off with sidings arm as type 'normal'. Also with signals that have Home and branch heads as well.

I've created a formal bug report about this issue. http://bugs.launchpa...or/+bug/1547013
I've known about it for a while, so I probably should have sooner. One of these days I'll get around to some more rigorous testing to see if anything else not quite right is lurking. I know it would sure be nice to have my signals working at 100% in OR. It's close—OR has certainly come a long way on that front already.

[Coolhand101]

jovet, on 18 February 2016 - 05:13 AM, said:

I've created a formal bug report about this issue. http://bugs.launchpa...or/+bug/1547013
I've known about it for a while, so I probably should have sooner. One of these days I'll get around to some more rigorous testing to see if anything else not quite right is lurking. I know it would sure be nice to have my signals working at 100% in OR. It's close—OR has certainly come a long way on that front already.

Many thanks for the formal bug report!

My next goal is to use the new 'approach control' scripts. I had no ideal that waitpoints now only clear the signal, once the train has stopped, like the double reverse point in MSTS.

Thanks

[Jovet]

Coolhand101, on 18 February 2016 - 05:52 AM, said:

Many thanks for the formal bug report!

You're welcome.

The irony is, of course, that earlier today I observed a situation which I believe should have been affected by that "bug" but didn't appear to be. I was going to go check it in the RE and MSTS formally but haven't yet. Go figure.

[Coolhand101]

Are there any more updates on this matter? I've starting using the cambrian coast 1 in OR. This route is all semaphore signals.

I have notice that the distant signals are behaving much better in this route. The only problem is junction signals, regardless if the mainline home signal is 'off', along with the following home signals, that distant will not clear. Or if the there are two main line junction signals along with two distant junction signals, the latter will not clear.

Also, if there is a home(starter)+distant combined, the distant is 'on' even if the following home signals are clear.

I would assume, that if there is a home signal with a shunt(switch)signal and that signal is set for the mainline, that distant will also not clear.

This all still seems to point to a signal with more than one HEAD in the sigCFG, causes the distant to stay 'ON'.

There is bug report already filed but maybe this post should be moved to the bug section ?

Thanks