Signal overlap problem, when used with ATLS Inverse Slave

[davidbird]

I am using the ATLS to control level crossings on my real-world based route. I know there is a series of signals with built-in ATLS compatibility, but I need several different types of signals over my level crossings, 4-aspect colour lights to disc semaphore shunting signals, and everything inbetween.

Because of this, I am using the ATLS Inverse Slave - which creates an invisible train, deletes it when activated and re-creates it when deactivated - to hold the protecting signal, of whatever type it is, at red/stop until the crossing is activated.

Previously my testing was almost exculsivly with 3 or 4 aspect colour light signals, and I am used to the way the ATLS system works. Now I am setting up and testing an area which involves semaphore signalling, with this set-up.

-->>-----D1-------C1--X1--------------S2---X2------------------>>------
--<<------------------X----S---------------X--C---------D------<<------

D = distant signal, C = combined distant/stop signal, S = stop signal, X = level crossing. The C and S signals are the ones held at red by the Inverse Slave/Invisible train until the crossing is activated.
I have so far tested in the Down direction, left to right on the sketch above.

I cannot get the C1 signal to clear, it stays at red even though the mini-map view shows the invisible train consists at X1 vanishing when expected.

When mousing over the signal C1 it says "Overlap of block ahead is occupied", even though here https://online.ts2009.com/mediaWiki/index.php/Class_Signal says the "public define int DEFAULT_OVERLAP = 25 Default. Overridden by 'overlap' in the config.txt." and the signal assets I'm using does not have a different overlap specified and the signal S2 is just about 100 meters from the invisible consist on the 2nd crossing . I even tried moving S2 so it was over 500 meters from X2, but still C1 stays at red with the overlap occupied message.

Any ideas what I'm doing wrong?

 

[maruffijd]

From what I have read. I suspect that the inverse slave for X2 is inside the overlap space of S2. If possible, increase the space between S2 and the X2 I-Slave and try again.

 

[davidbird]

From what I have read. I suspect that the inverse slave for X2 is inside the overlap space of S2. If possible, increase the space between S2 and the X2 I-Slave and try again.

Yes, that was my first thought. The signal S2 is placed a prototypical distance of 100m from the crossing, when I increased it to 500m, it still had the same behaviour.

I was using Sig AS UQ 20ft home <kuid2:330374:1151:1> and others from the same range, also similar ones with <kuid2:60850:xxx>, which have a basicsemaphore.gs script

I have tried replacing the signals C1 and S2 with 3A colour light signals, the built-in <kuid2:60850:24195:13>

This time they do all work as they should, as the invisble train of X2 is outside the default 25m overlap of S2.

The question now is what is the overlap of Sig AS UQ 20ft home <kuid2:330374:1151:1>, presumably specified in the basicsemaphore.gs script and can it be altered?

 

[stagecoach]

Don't use version 9 in TRS22, Use version 8 of the inverse slave. There seems to be some sort of scripting issue with 9. I have a level crossing with an inverse slave at the end of my platform which operates just fine with version 8. There are other scripting issues with other scripts like EIT that are not working as expected.

 

[davidbird]

Don't use version 9 in TRS22, Use version 8 of the inverse slave. There seems to be some sort of scripting issue with 9. I have a level crossing with an inverse slave at the end of my platform which operates just fine with version 8. There are other scripting issues with other scripts like EIT that are not working as expected.

I was using V10 of the Inverse Slave. I've tried it with V8, as suggested.
Alas, no difference. Still C1 refuses to clear with a message of "Overlap of next signal occupied".
The only other solution I can think of is to trigger X2 before the train reaches C1. Not strictly prototypical, as the crossing will be closed to road traffic for far longer than is necessary...