Upcoming Games

(UTC times)


Full list
Add a game

Upcoming Events

No events to display

Who's Online

DriverCurran, 442s3, andi, jem771, Intercity_225, Person82, Andrew G, Zecs (8 users seen recently)

ACOA right before passing the signal goes undetected

You are here: Home > Forum > General > General questions, comments, and issues > Loader V5 > ACOA right before passing the signal goes undetected

Page 1 of 2

ACOA right before passing the signal goes undetected 22/01/2021 at 14:39 #136676
Dionysusnu
Avatar
577 posts
If you revert a signal (green to yellow) just before the train passes it, the ACOA will go unnoticed, at both that signal and the next, even though the train driver would see at least one of the two signals being unexpectedly restrictive. Save attached from right after. Train is 8X01. I cancelled S664 just before it passed S668, which made 668 revert from green to yellow, and S664 revert from green to red.
The train would either
- not notice S668 changing, then get ACOA with green-red at S664
- notice S668 changing and get ACOA there
However, it does neither of those and continues happily on its way.

Post has attachments. Log in to view them.
Log in to reply
ACOA right before passing the signal goes undetected 22/01/2021 at 20:58 #136689
Stephen Fulcher
Avatar
2078 posts
Your save doesn't show much as the incident has already occurred before it was taken.

I can recreate this though. Logged on Mantis as 32878.

Log in to reply
The following user said thank you: Dionysusnu
ACOA right before passing the signal goes undetected 22/01/2021 at 20:58 #136690
Stephen Fulcher
Avatar
2078 posts
Your save doesn't show much as the incident has already occurred before it was taken.

I can recreate this though. Logged on Mantis as 32878.

Log in to reply
ACOA right before passing the signal goes undetected 22/01/2021 at 21:43 #136691
Peter Bennet
Avatar
5402 posts
I've reproduced on another sim (Aston- simply because it was the quickest to load).

If you have the train approaching S1 with S2 next after that.
If the train is far enough away from S1 when you pull S2 then you get no report (It appears to be till the train is about 300m from the signal - which makes sense as that's the default sighting distance). It also does not report when the train is very close to the signal (as per report).

If the train stops then it stops about 20m before S1 and that appears to be the point at which the report otherwise ceases.
I.e. once the train has passed the place it would stop it can't "see" the signal.

Peter

I identify as half man half biscuit - crumbs!
Last edited: 22/01/2021 at 21:44 by Peter Bennet
Reason: None given

Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 08:11 #136695
Stephen Fulcher
Avatar
2078 posts
I had overlooked the sighting distance Peter, when I repeated the test pulling the signal with the train closer it did get an ACOA report.

Dionysusnu, in this instance there is no problem with the sim. Whilst the signal being replaced did cause a change of aspect in advance so the interlocking times the routes out, a developer can set a distance for which a signal can be seen. Testers can use a debug tool to see how far into each subroute a train is. If I pull signal 664 when the train just passes onto T397 then there is no ACOA message, but if I wait until it is only 200m from signal 668 before I pull 664 then the message is generated.

In the first case whilst the signal will have reverted, the driver would not have seen it so encountering either yellow or green when he does see 668 is a legitimate aspect (Green 674, Yellow 668) so he would not report anything.

I have closed my ticket in Mantis as no change required on that basis.

Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 08:44 #136696
Albert
Avatar
1315 posts
Not the case for this specific signal, but there are also signals which don't have a separate overlap track circuit meaning a train can have passed the signal before you see it on the panel. This mostly applies to automatic signals.
AJP in games
Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 13:14 #136702
Dionysusnu
Avatar
577 posts
The train passed the reverting signal about 1 second after it changed. It wasn't outside the sighting distance like in your first test attempt.
As I said in original post, it would either
- not notice S1 changing before passing it, then get ACOA with green-red at S2
- notice S1 changing and get ACOA there
either way should still be an ACOA.

Last edited: 23/01/2021 at 13:22 by Dionysusnu
Reason: None given

Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 13:31 #136703
Stephen Fulcher
Avatar
2078 posts
In that case, I cannot reproduce it
Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 14:17 #136706
bill_gensheet
Avatar
1413 posts
If it is as little as ~1 second, is that not near the cycle time for SimSig to recalculate things ?
Might expose something like this:

12:00:00 train behind signal SIG1 at green, SIG2 also green
revert SIG2 signal command
12:00:01 locking reverts SIG2 G to R
train <20m from SIG1 still G so no ACOA
12:00:02 aspect change propagated to SIG1 G to Y (sim/location dependent ?)
train has memory that SIG1 was a Y so no ACOA at SIG2

Will try some experiments looking around the 20m Peter has suggested.

Can anyone check if the signals in question are using default sighting distances ?

Bill

Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 14:19 #136707
Dionysusnu
Avatar
577 posts
Yes, that theory from bill also came up in my mind, seems like that's close to what happened.
Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 15:19 #136714
bill_gensheet
Avatar
1413 posts
Replicated as below, used Motherwell as that has a nice clear bit of plain line.
Train movement text is from tester debug information. Timetable attached, I used 6S67.

If the timestep following the signal reversion takes the train past the signal, no ACOA reported.

Working OK:

25 MOV 485/864 U793AB occ=57s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.50km
...
29 MOV 824/864 U793AB occ=85s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.84km
29 MOV 837/864 U793AB occ=86s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.85km
29 MOV 850/864 U793AB occ=87s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.86km
>>> Now at 14m from TC end MC713
>>> Cancel next sig MC711 while paused
>>> MC713 G to Y immediate
>>> ACOA results for MC713, crash stops as expected.
29 received 863/864 U793AB occ=88s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.88km
0 MOV 863/864 U793AB occ=89s SUMMIT cursig=MC713 nxtsig=MC713 Down 0.88km
0 TEL 863/864 U793AB occ=91s SUMMIT cursig=MC713 nxtsig=MC713 Down 0.88km

Rerun showing bug

6 MOV 869/872 U795AB occ=6s SUMMIT cursig=MC629 nxtsig=MC715 Down 0.01km
>>>> Next step should take train past MC715 as it is 3m per tick
>>>> Cancel MC711 while paused
>>>> MC715 G to YY
7 MOV 0/864 U793AB occ=0s SUMMIT cursig=nil nxtsig=MC715 Down 0.02km
8 MOV 4/864 U793AB occ=1s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.02km
....
25 MOV 451/864 U793AB occ=54s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.47km
....
28 MOV 723/864 U793AB occ=77s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.74km
....
29 MOV 25/863 U789AB occ=1s SUMMIT cursig=MC711 nxtsig=MC711 Down 0.90km

No ACOA reported at either signal



Bill

Post has attachments. Log in to view them.
Log in to reply
The following user said thank you: Dionysusnu
ACOA right before passing the signal goes undetected 23/01/2021 at 21:15 #136721
Peter Bennet
Avatar
5402 posts
bill_gensheet in post 136714 said:
Replicated as below, used Motherwell as that has a nice clear bit of plain line.
Train movement text is from tester debug information. Timetable attached, I used 6S67.

If the timestep following the signal reversion takes the train past the signal, no ACOA reported.

Working OK:

25 MOV 485/864 U793AB occ=57s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.50km
...
29 MOV 824/864 U793AB occ=85s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.84km
29 MOV 837/864 U793AB occ=86s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.85km
29 MOV 850/864 U793AB occ=87s SUMMIT cursig=MC627 nxtsig=MC713 Down 0.86km
>>> Now at 14m from TC end MC713
>>> Cancel next sig MC711 while paused
>>> MC713 G to Y immediate
>>> ACOA results for MC713, crash stops as expected.
29 received 863/864 U793AB occ=88s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.88km
0 MOV 863/864 U793AB occ=89s SUMMIT cursig=MC713 nxtsig=MC713 Down 0.88km
0 TEL 863/864 U793AB occ=91s SUMMIT cursig=MC713 nxtsig=MC713 Down 0.88km

Rerun showing bug

6 MOV 869/872 U795AB occ=6s SUMMIT cursig=MC629 nxtsig=MC715 Down 0.01km
>>>> Next step should take train past MC715 as it is 3m per tick
>>>> Cancel MC711 while paused
>>>> MC715 G to YY
7 MOV 0/864 U793AB occ=0s SUMMIT cursig=nil nxtsig=MC715 Down 0.02km
8 MOV 4/864 U793AB occ=1s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.02km
....
25 MOV 451/864 U793AB occ=54s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.47km
....
28 MOV 723/864 U793AB occ=77s SUMMIT cursig=MC711 nxtsig=MC713 Down 0.74km
....
29 MOV 25/863 U789AB occ=1s SUMMIT cursig=MC711 nxtsig=MC711 Down 0.90km

No ACOA reported at either signal



Bill
Yes, that's what I found but better explained.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 22:01 #136722
clive
Avatar
2789 posts
bill_gensheet in post 136706 said:
If it is as little as ~1 second, is that not near the cycle time for SimSig to recalculate things ?
Most of the SimSig logic, except that triggered by the user doing something, is done either every "major cycle", which is half a second, or every second. From memory, signal aspects are computed every major cycle but train motion is done once a second. Things involving timers expiring are almost all once a second.

The ACOA detection logic is definitely run once a second.

Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 22:18 #136723
clive
Avatar
2789 posts
Okay, I've dug out the ACOA logic. As far as I can tell, it works like this.

If there's a train hiding the next signal, nothing happens and the "put back" timer is set to 5 seconds.

An ACOA can only be detected if:
* The put back timer has stopped.
* There is a "next signal" (look for "nxtsig" in Bill's log), it's the same one as a second ago, it's alight, and it's not pretending to be something else (developers, see SIG-PNS).
* The next signal is showing a more restrictive aspect than a second ago.
* There is no train in front and no train hiding the next signal.
* This train is powered.
* This train is not in the process of transferring to a chained simulation.
* The signal hasn't just lit (if it has, the put back timer is set to 5 seconds to give time for all the aspects to untangle themselves).
* The train is not sitting at a station stop with at least 10 minutes before it will depart.
* Either the train is within sighting distance of the signal *OR* the new aspect is not one that can follow the last aspect seen in a valid sequence (e.g. on a four-aspect line, only YY, FYY, and G can follow G, and only FY can follow FYY). You can tell which applied because the message is "received" for the first and "will receive" for the second.

Once an ACOA has been reported, the put back timer is set to 15 seconds and the "not one that can follow" logic is disabled for this signal (by setting the memory of the last aspect seen to red).

Log in to reply
ACOA right before passing the signal goes undetected 23/01/2021 at 22:53 #136724
clive
Avatar
2789 posts
bill_gensheet in post 136714 said:
Replicated as below, used Motherwell as that has a nice clear bit of plain line.
Train movement text is from tester debug information. Timetable attached, I used 6S67.
[...]
Rerun showing bug
6 MOV 869/872 U795AB occ=6s SUMMIT cursig=MC629 nxtsig=MC715 Down 0.01km
>>>> Next step should take train past MC715 as it is 3m per tick
>>>> Cancel MC711 while paused
>>>> MC715 G to YY
7 MOV 0/864 U793AB occ=0s SUMMIT cursig=nil nxtsig=MC715 Down 0.02km
[...]
No ACOA reported at either signal
I added some debugging code and just tried that for myself. No, no ACOA was reported.

Because, when a train seeds, the "put back" timer (see previous post) is set to 10 seconds to prevent spurious warnings when another train seeds at the next signal. So that wasn't a valid test!

When working round that (a short TCF to hold 715 red for 10 seconds) my logging still sees the aspect change being detected but no report. I need to figure out why.

Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 10:49 #136730
Albert
Avatar
1315 posts
I've found another case in which ACOAs aren't reported: if you start a game with the 'start paused' box ticked. The signals are showing all red until you unpause and cancelling one of them at that time doesn't generate an ACOA even if a train is nearby.
AJP in games
Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 11:00 #136731
Steamer
Avatar
3984 posts
Albert in post 136730 said:
I've found another case in which ACOAs aren't reported: if you start a game with the 'start paused' box ticked. The signals are showing all red until you unpause and cancelling one of them at that time doesn't generate an ACOA even if a train is nearby.
I'm assuming this is covered under this bullet point:

Quote:
The signal hasn't just lit (if it has, the put back timer is set to 5 seconds to give time for all the aspects to untangle themselves).

"Don't stress/ relax/ let life roll off your backs./ Except for death and paying taxes/ everything in life.../ is only for now." (Avenue Q)
Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 13:06 #136732
Dionysusnu
Avatar
577 posts
clive in post 136723 said:
* The train is not sitting at a station stop with at least 10 minutes before it will depart.

Finally, I know what the exact value of this is! I've often wondered if it was just random or some internal reason that decides whether or not stopped at a station will count ACOAs. Thanks, clive.

Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 13:08 #136733
Peter Bennet
Avatar
5402 posts
Dionysusnu in post 136732 said:
clive in post 136723 said:
* The train is not sitting at a station stop with at least 10 minutes before it will depart.

Finally, I know what the exact value of this is! I've often wondered if it was just random or some internal reason that decides whether or not stopped at a station will count ACOAs. Thanks, clive.
The presumption being that the driver is still in the messroom so no ACOA can be seen.

Peter

I identify as half man half biscuit - crumbs!
Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 14:47 #136735
bill_gensheet
Avatar
1413 posts
Ok tried a few more letting things settle from startup.
First two up trains:

(1M97) 00:03:15
85 MOV 1080/1263 U796BA occ=30s BEATTOCK cursig=MC714 nxtsig=MC626 Up 4.27km
85 MOV 1118/1263 U796BA occ=31s BEATTOCK cursig=MC714 nxtsig=MC626 Up 4.31km
85 MOV 1156/1263 U796BA occ=32s BEATTOCK cursig=MC714 nxtsig=MC626 Up 4.35km
86 MOV 1194/1263 U796BA occ=33s BEATTOCK cursig=MC714 nxtsig=MC626 Up 4.39kmp
86 MOV 1233/1263 U796BA occ=34s BEATTOCK cursig=MC714 nxtsig=MC626 Up 4.43km
39 m per second, so now hit E button for MC630
85 MOV 8/1677 U798BA occ=0s BEATTOCK cursig=nil nxtsig=MC626 Up 4.46km
MC626 Y
1M97: unexpected aspect 2 at SMC626 after seeing 6 at SMC618
...
67 MOV 720/1677 U798BA occ=21s BEATTOCK cursig=MC630 nxtsig=MC630 Up 5.18km
00:04:50, Stops MC630
67 MOV 720/1677 U798BA occ=21s BEATTOCK cursig=MC630 nxtsig=MC630 Up 5.18km
Release E and train continues, no ACOA call.

(1M97 again) 00:18:33
90 MOV 657/670 U912BA occ=16s KIRTLEBRIDGE cursig=nil nxtsig=MC826 Up 41.19km
~50m per tick, hit E button for MC828
MC828 red on half tick
MC826 still G
89 MOV 26/180 U916CA occ=0s KIRTLEBRIDGE cursig=nil nxtsig=MC826 Up 41.23km
MC826 now Y
Message:
1M97: unexpected aspect 2 at SMC826 after seeing 6 at SMC822
88 MOV 66/180 U916CA occ=1s KIRTLEBRIDGE cursig=MC828 nxtsig=MC828 Up 41.27km
...slows for red...
00:19:27 1M97 waiting at red signal MC828 (Lockerbie RR area)
0 RED 457/665 U918BBA occ=38s KIRTLEBRIDGE cursig=MC828 nxtsig=MC828 Up 42.60km
00:21:58 1M97 waiting at red signal MC828 (Lockerbie RR area)
Calls for red signal
Remove E
Train moves off


and two down trains


(new train 6S69) 00:09:28
60 MOV 790/821 U889AB occ=29s WAMPHRAY cursig=MC747 nxtsig=MC815 Down 12.37km
60 MOV 817/821 U889AB occ=30s WAMPHRAY cursig=MC747 nxtsig=MC815 Down 12.39km
E on MC813
G to Y on MC815 (in half tick) <<<<<<< !
60 MOV 817/821 U889AB occ=30s WAMPHRAY cursig=MC747 nxtsig=MC815 Down 12.39km
60 MOV 23/194 U887AB occ=0s WAMPHRAY cursig=nil nxtsig=MC815 Down 12.42km
Train begins braking for red
Message:
6S69: unexpected aspect 2 at SMC815 after seeing 6 at SMC817
...
0 RED 1022/1042 U885AB occ=111s WAMPHRAY cursig=MC813 nxtsig=MC813 Down 13.61km
Message
00:10:56 6S69 waiting at red signal MC813 (Lockerbie RR area)
Remove E and signal clears
Train proceeds OK

(6S67) 00:13:50
34 MOV 842/869 U759AB occ=55s SUMMIT cursig=MC533 nxtsig=MC625 Down 12.05km
34 MOV 857/869 U759AB occ=56s SUMMIT cursig=MC533 nxtsig=MC625 Down 12.07km
Cancel MC613
MC625 G to Y (in half tick)
34 MOV 857/869 U759AB occ=56s SUMMIT cursig=MC533 nxtsig=MC625 Down 12.07km
34 MOV 4/215 U757AB occ=0s SUMMIT cursig=nil nxtsig=MC625 Down 12.08km
Message:
6S67: unexpected aspect 2 at SMC625 after seeing 6 at SMC627
34 MOV 19/215 U757AB occ=1s SUMMIT cursig=MC613 nxtsig=MC613 Down 12.10km
0 RED 596/616 U749AB occ=224s SUMMIT cursig=MC613 nxtsig=MC613 Down 13.38km
00:15:35 6S67 waiting at red signal MC613 (Summit RR area)
00:17:49 6S67 waiting at red signal MC613 (Summit RR area)
Normal call from red signal 00:17:49

-----------


Noticed the following while doing those tests, not sure if it might be relevant.

Some 'E' replacements are immediate on all related signals (MC633, MC711),
while some others (MC638, MC710) have propagation time of one sim cycle to show Y and YY on the rear signals.

The latter case does generate transient bad/odd aspect sequences such as
G-G-R and G-YY-Y-G, but from the real railway is probably correct.

Similar E behaviour on other sims too:
Three Bridges T323 propagates, T322 is immediate on T326 and T322.
Wembley 125 and 149 propagate, 116 and 344 are immediate

Something to do with direction ?

regards
Bill

Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 18:10 #136743
clive
Avatar
2789 posts
clive in post 136724 said:

When working round that (a short TCF to hold 715 red for 10 seconds) my logging still sees the aspect change being detected but no report. I need to figure out why.
Simple! The train is 1 cm beyond the signal and, even though the report you see shows it on U795AB, by the time we get to the ACOA logic it's been moved on to U793AB and so the driver can't see 715.

Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 18:16 #136745
Dionysusnu
Avatar
577 posts
But then shouldn't the "not an aspect that can follow" logic kick in there?
Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 18:17 #136746
clive
Avatar
2789 posts
bill_gensheet in post 136735 said:

Noticed the following while doing those tests, not sure if it might be relevant.

Some 'E' replacements are immediate on all related signals (MC633, MC711),
while some others (MC638, MC710) have propagation time of one sim cycle to show Y and YY on the rear signals.

The latter case does generate transient bad/odd aspect sequences such as
G-G-R and G-YY-Y-G, but from the real railway is probably correct.

Similar E behaviour on other sims too:
Three Bridges T323 propagates, T322 is immediate on T326 and T322.
Wembley 125 and 149 propagate, 116 and 344 are immediate

Something to do with direction ?
Not quite, no. You'll see this for all propagation, not just on replacement to red.

Each major cycle involves doing the aspect calculation (and lots more work) for each signal in turn. So it depends on the order the signals are processed. If the aspect of S1 affects the aspect of S3, then if S1 is processed before S3 in the major cycle you'll see immediate propagation while if S3 is before S1 you'll see a delay. The same thing happens with real SSI interlockings and probably also other types.

The order that is used is not specified and may change because of loader changes, possibly unintentionally.

Log in to reply
The following user said thank you: bill_gensheet
ACOA right before passing the signal goes undetected 24/01/2021 at 18:18 #136747
GeoffM
Avatar
6376 posts
Steamer in post 136731 said:
Albert in post 136730 said:
I've found another case in which ACOAs aren't reported: if you start a game with the 'start paused' box ticked. The signals are showing all red until you unpause and cancelling one of them at that time doesn't generate an ACOA even if a train is nearby.
I'm assuming this is covered under this bullet point:

Quote:
The signal hasn't just lit (if it has, the put back timer is set to 5 seconds to give time for all the aspects to untangle themselves).
Correct. IIRC there is a short timer immediately after a reload as well, just in case.

SimSig Boss
Log in to reply
ACOA right before passing the signal goes undetected 24/01/2021 at 18:18 #136748
clive
Avatar
2789 posts
Dionysusnu in post 136732 said:
clive in post 136723 said:
* The train is not sitting at a station stop with at least 10 minutes before it will depart.

Finally, I know what the exact value of this is! I've often wondered if it was just random or some internal reason that decides whether or not stopped at a station will count ACOAs. Thanks, clive.
This number is not guaranteed and Geoff and I reserve the right to alter it without warning, including adding a random variation to allow for how eager the driver is.

Log in to reply