Te vroeg vertrekkende treinen uit KKNW

[Pierre]

Ik heb dit al eerder opgemerkt, maar ik maak er nu maar een thread van. Het is nu 5:59, en op spoor 504 van KKN staat al enkele minuten trein 3-98953 (a. 6:04, v. 6:04 sp504). Deze is naar mijn mening te vroeg (5:56) uit KKNW gekomen, omdat inmiddels trein 9-98713 (a. 6:01, v. 6:01 sp504) staat te wachten op spoor 524. Ik had al gezien dat er een trein aankwam uit de richting Neuss, maar welke dat was werd pas bekend toen trein 3-98953 al KKN was binnengelopen. Ik kan dus alleen maar gokken of deze aankomende trein via sp512, of via de S-bahn het hoofdstation binnen wil.

Is dit een bekend gedrag van de sim, en is dit aan te passen in de dienstregeling, of kan ik als trdl er voor zorgen dat de uitrijder van KKNW niet meer automatisch gaat?

P.S. 3-98950 mist zijn rangeeropdracht om om te nummeren naar 3-98955, 11806 --> 64110 in KKHRW gaat ook niet automatisch.

P.P.S. Hetzelfde verhaal voor de 3-98957 (8:04), en 9-98731 (8:01). Waarschijnlijk was dit ook bij 98955 gebeurd, maar die nummerde niet om, waardoor de automatische seinen niet reageerden.

[TjoeTjoe]

Ik kan dus alleen maar gokken of deze aankomende trein via sp512, of via de S-bahn het hoofdstation binnen wil.

Gokken? Dienstregeling beheersen .

Alleen treinen met stuurcijfer 8 uit de richting KKN gaan over de hoofdsporen (lees: niet S-Bahn) naar KK.

's Nachts een uitzondering met een goederentrein met stuurcijfer 2 en verder wat ritten met stuurcijfer 1, die bij Nippes de Fernbahn gleise 518->512 op moeten

Is dit een bekend gedrag van de sim, en is dit aan te passen in de dienstregeling, of kan ik als trdl er voor zorgen dat de uitrijder van KKNW niet meer automatisch gaat?

Dit gedrag is mij bekend. Maar de exacte oorzaak waarom de AI dispatcher dit doet is slechts gissen.

Een sein in het buitengebied deactiveren gaat niet. Je kan wel de trdl Nippes naar de koffie sturen, maar dan moet je dus dat stukje Nippes ook onder je hoede nemen.

Alsof je niks anders te doen hebt

Heb echter wel een klein vermoeden wat de oorzaak is en hoe op te lossen ... komt straks bij je laatste opmerking

P.S. 3-98950 mist zijn rangeeropdracht om om te nummeren naar 3-98955, 11806 --> 64110 in KKHRW gaat ook niet automatisch.

Je bedoelt hier 11806 --> 74110. Kleine toevoeging hierop. Deze trein heeft op za&zo een andere drgl dan doordeweeks, op za&zo 11806 --> 74133 op ma->vr 11806 --> 74110

In beide gevallen ontbreken inderdaad de omnummer-opdrachten.

Wat betreft de 3-98950: je bevinding kan ik alleen maar bevestigen

P.P.S. Hetzelfde verhaal voor de 3-98957 (8:04), en 9-98731 (8:01). Waarschijnlijk was dit ook bij 98955 gebeurd, maar die nummerde niet om, waardoor de automatische seinen niet reageerden.

... en ik denk dat dit dus een link is met het te vroeg instellen van rijwegen vanuit KKNW.

Ik denk dat de AI dispatcher een zekere tijdsmarge in acht neemt bij het instellen van rijwegen. Afhankelijk van de drukte zullen er (betere) prioriteiten gesteld worden.

Echter als er niet zo veel op de lijn zit, en er "verschijnt" een treinnummer in zijn vizier waar hij wat mee kan, dan gaat onze virtuele collega enthousiast aan de slag.

Het is zeker een test waard om (moet via "hacken" in de drgl database) om een dergelijk trein in KKNW

- te laten arriveren en laten keren

- de mcn gedurende een x minuten naar de koffie te sturen en

- terug te laten keren, zeg 2 minuten voor vertrek of in ieder geval nadat een trein die voor moet al in aantocht is (op het generieke paneel)

- trein laten omnummeren naar nieuwe dienstnummer (dan scheurt Mr. AI door zijn papierwinkel, zegt "Hé daar moet ik wat mee doen" en stelt dan rijweg in)

Heb momenteel zelf niet al te veel tijd om deze procedure te testen, dus als iemand dit wil uitproberen?

Wat betreft de "omnummer"-fouten. Ik zal proberen om in contact te komen met de Chef Ep en vragen of ik de benodigde wijzigingen mag doorvoeren (evt in overleg met de Duitse Fpl-veredelaar)

Er zijn namelijk nog een paar zaken die bekend staan als onjuist, maar nog niet verwerkt zijn in de drgl.

Erwin

[TjoeTjoe]

Heb de dienstregeling database ontvangen en aangepast wat betreft de keeropdrachten

Komt binnenkort online, zal een melding hiervan geven.

Erwin

[Pierre]

Zei ik 64110? Ik bedoel natuurlijk 74110, maar dat had je al door En die dienstregeling beheersen, als ik die snel zou kunnen filteren op wat er aankomt uit de richting Neuss, zou het een stuk makkelijker zijn. Waar ik na enig zoekwerk op uitkom is:

- 11453 Krefeld-Giessen (6:21-6:25 Hbf)

- 11455 Krefeld-Siegen (7:21-7:25 Hbf)

- 11457 Krefeld-Giessen (8:21-8:25 Hbf)

- 11459 Krefeld-Siegen (9:21-9:25 Hbf)

enzovoorts.....

Dit zijn dus de treinen met stuurcijfer 8.

Dus als de trein rond het hele uur komt, wanneer de probleemtrein in KKNW staat, is het vrijwel zeker een stuurcijfer 9:

- 98713 (6:01 KKN(S))

- 98723 (7:01 KKN(S))

- 98731 (8:01 KKN(S))

- 98739 (9:01 KKN(S))

- 98747 (10:01 KKN(S))

- 98755 (11:01 KKN(S))

- 98763 (12:01 KKN(S))

Conclusie: verschijnt er rond het hele uur een groene streep uit Neuss, onmiddelijk naar de S-bahn gooien, zodat de AI van Nippes niet de trein uit KKNW vrijlaat. Wat vervolgens wel gebeurt is nadat de trein van X:04 KKN 504 weer weg is, de handmatige rijweg zich opnieuw instelt, en vervolgens verwijderd moet worden.

[signalsoftRC]

Ik heb gisteren nog 's gezocht naar dat effect van "keren en gelijk rijweg instellen terwijl voor tijd". De situatie op te zetten in de sim en door de code te stappen duurt een goed uurtje. Dan is moment daar, en doet ie 't NIET. en ook zo niet te zien of het "eventueel" kan gebeuren.

Het is dus een "bug in release versie" en die is harder te vinden. (omdat het in de debug versie NIET gebeurt)

Daar hebben we ook een oplossing voor, maar dat duurt wat langer, want veel meer werk. (visual studio koppelen aan een release versie en dan stappen maar... :-())

Het is een vervelend probleempje. Rijweg terugnemen lukt wel.

[TjoeTjoe]

Kon het niet laten of een repro te doen, met uitsluitend de treinen welke hier een rol spelen (3-98902 -> KKNW -> 3-98953, en de 9-98713)

Lekker op de Turbo stand, tot 64x, en alleen de kritische momenten eruit pakken

05:54:07

Onmiddelijk nadat trein 3-98902 op KKNW omnummert en keert 3-98953, wordt de rijweg van S510 naar 504 ingesteld

Trein 9-98713 zit al in de aankondiging (groene lijn) vanuit KKN(S)

Signal Train To Status

S510 - 98953 - 504 - Route Setting

P504 - 98953 - 502 - Too Early

ca 05:58

Trein 9-998713 in aantocht, 3-98953 staat op 504

Signal Train To Status

S510 - 98953 - 504 - Completed

P504 - 98953 - 502 - Too Early

F522 - 98713 - 504 - Waiting For Target Track To Clear

06:00

Trein 9-998713 staat inmiddels voor F522, 3-98953 staat nog altijd op 504

Status wijziging in AI Dispatcher venster

P504 - 98953 - 502 - Lower Priority

F522 - 98713 - 504 - Waiting For Target Track To Clear

De status 'Lower Priority" vind ik hier interessant. Wat bepaald de prioriteit, en waarom was deze status niet voor S510 van toepassing

06:03

Trein 9-998713 staat nog altijd voor F522, 3-98953 staat nog altijd op 504 (1 minuut voor vertrek nu)

Status wijziging in AI Dispatcher venster

P504 - 98953 - 502 - Route Setting

F522 - 98713 - 504 - Waiting For Target Track To Clear

Conclusie hier: een route wordt 1 minuut van te voren ingesteld, indien mogelijk?

AI dispatcher log

05:54:07 98953 S510 [510AT *]

06:03:00 98953 P504 [504AT *]

06:05:23 98713 F522 [524AT *]

06:06:30 98713 P504 [502T 504AT *]

Ik heb verder nog wat gespeeld met de rangeeropdrachten:

1. eerst omnummeren zodat de neus van de 98953 nog de 'verkeerde kant' op staat, hopend dat mr AI heb dan negeert. Geen verschil, gedrag blijft hetzelf

2. omnummeren, machinist van de trein, om 5:59 weer aan boord, dan keren. Trein was al gekeerd (??) waarschijnlijk omdat hij dat automatisch doet op kopspoor. Ook geen succes

Krijg haast de indruk dat doordat op KKNW er zo opeens een verwachte trein staat, mr AI echt schrikt en geen prio-test doet.

SIM saves zijn beschikbaar

Erwin

[signalsoftRC]

De AI kijkt eigenlijk naar de vertrektijd vanaf het spoor. En als 't te vroeg is, stelt ie 'm niet in.

Daarom is 510AT een "perronspoor" (of eigenlijk drgl punt) en heet Köln-Nippes Wendeanlage (KKNW).

Ook ist 504AT en 510AT e e n rangeergebied. Als je een trein binnenneemt op 504, keert ie daar ook. (een trein die normaal op 510 keert)

Wat gebeurt er als er een trein van 510 naar 504 rijdt? AI stelt niet verder in.

Wat gebeurt er als je een trein binnen neemt van KK op 504. Hij keert en stelt niet verder in (tot vertrektijd).

Op 510 gebeurt precies hetzelfde....

heel raar.

[TjoeTjoe]

Wat gebeurt er als er een trein van 510 naar 504 rijdt? AI stelt niet verder in.

Wat gebeurt er als je een trein binnen neemt van KK op 504. Hij keert en stelt niet verder in (tot vertrektijd).

Op 510 gebeurt precies hetzelfde....

heel raar.

Nog wat andere alternatieve testen om de AI dispatcher te misleiden (lees: op te voeden) hadden geen succes

Dan moeten we er voorlopig inderdaad maar vanuit gaan dat het een bug in de release-versie is en bij een volgende update verdwenen zou moeten zijn

Erwin

[signalsoftRC]

nee, het probleem met "release versie bugs" is dat die niet opduiken in een debug versie. Er is dus een codeverschil tussen een debug versie en een release versie. Een release versie testen, stap voor stap is vele malen moeilijker omdat je b.v. waardes niet kunt geven of niet stukken code kunt overslaan, wat je WEL kunt in een debugversie. Het duurt dan langer voordat je het eventueel vindt.

We hebben ook bugs gehad in functies, die uiterst correct werken in debug en heel anders in release. Daar helpt alleen maar een "omweg eromheen bouwen".

Zeer vervelende bugs.