Dienstregeling versie 23 december 2011

[Hobbyman]

Raymond, Ik denk dat je gelijk hebt.

Misschien is het voor dit moment verstandig om te kiezen voor de eenvoudigste oplossing:

De EntrypointTime van de trein wordt gewijzigd in 00.00.

De trein is dan altijd ca 8 minuten "te laat" in de simulatie.

Maar alle problemen zijn dan ook verdwenen.

[Dre]

55441 en het vertrek van 80182 zijn tot nog toe als luxe problemen op de plank blijven liggen.

Het stoort de werking van de sim niet.

Dat trein 55441 op spoor 307 wordt gereedgemaakt stoort de simulatie in zoverre dat de meldingslampjes van 307a én 307b blijven branden als trein 55441 spoor 307 eenmaal verlaten heeft. Vervolgens kunnen er alleen met ROZ treinen naartoe gestuurd worden.

Trein 80182 vertrekt er iets later door, maar daarnaast wordt de simulatie er inderdaad niet door gestoord.

Mochten de industrie locs van Akzo eigenlijk op de NS sporen komen?

Of het mocht weet ik niet (voor emplacementen kunnen immers andere regels gelden dan voor de vrije baan), Akzo had tot 2006 [toen de chloorproductie in Hengelo beëindigd werd] haar eigen locje (een O&K MB5-N, nummer 3, genaamd "Dirk"). Die kwam echter nooit buiten de poort, Het Akzo-terrein beschikte zelf over een omloopspoor en de treinen werden door locs van NS (vanaf 1999 NS Cargo) opgehaald. Tot eind jaren '80 was daarvoor een loc 500/600 in Hengelo gestationeerd, later nam een 2200 dat werk over. Ten tijde van de simulatie was de serie 2200 al van het hoofdrailnet verdwenen (in Nederland deden ze alleen nog dienst in Zeeuws-Vlaanderen). Aannemelijk is dat een 6400 voor de aanvoer van/naar het Akzo-terrein zorgde.

[Hobbyman]

Dat 55441 altijd een storing achterlaat op spoor 7 is mij nog niet opgevallen.

Dat ga ik even controleren.

nader: Na vertrek van 55441 doven de lampjes in spoor 7 bij mij wel.

Ik neem dus aan dat het een spontane storing is.

Dat lijkt er inderdaad op dat alle bewegingen naar Akzo door de rangeerploeg (met 6400) uit Aml moeten worden uitgevoerd.

Voor trein 7981 geldt dat er (even niet opgelet) en nieuw probleem bijkomt.

Als de aankomst in Wdn na middernacht ligt gaat de trein staan wachten op zijn oorspronkelijke vertrektijd (23.58 of zo).

Dus moeten aankomst en vertrek in Wdn ook opschuiven tot na middernacht.

En voor de echte trdl: 1781 rijdt er pal achter. Die zou 7981 in Aml kunnen in halen, of je kunt 1781 over het spoor Aml-Wdn laten rijden.

[Dre]

Dat 55441 altijd een storing achterlaat op spoor 7 is mij nog niet opgevallen.

Dat ga ik even controleren.

nader: Na vertrek van 55441 doven de lampjes in spoor 7 bij mij wel.

Ik neem dus aan dat het een spontane storing is.

Hoe heb je dat gecontroleerd? Heb je daadwerkelijk trein 95108 naar spoor 307 geleid, de vrijgave voor spoor 8-19 gegeven, waarna trein 95108 vervolgens op spoor 8-19 trein 55441 gaat aanhaken en zich later terugmeld als trein 55441 om de vrijgave terug te geven óf heb je eenvoudigweg de simulatie geladen op het moment dat trein 55441 reeds terug is op spoor 307?

Dat lijkt er inderdaad op dat alle bewegingen naar Akzo door de rangeerploeg (met 6400) uit Aml moeten worden uitgevoerd.

Anno 2000 waren er geen hippels meer gestationeerd in Hengelo. Hengelo heeft tot 2006 nog de beschikking gehad over een locomotor serie 200/300 (nr. 357), die vervangen is door een Niteq 4000-U. Het is dus ook niet geheel realistisch dat je Tc1 om een Loc 600+koppelwagen kunt vragen voor het geval je materieel wil verslepen. In de praktijk was er een sik, waar als dat nodig was een scharfenbergkoppeling op de schroefkoppeling geplaatst werd (in de simulatie kun je dat aangeven door bij in de tabel Vehicles in de kolom VehicleCoupleType het nummer 0 aan te geven).

[Hobbyman]

Ai, dat vergde dus een test van 1,5 uur.

maar in de 4e versnelling is dat nog geen 30 minuten.

Maar dan blijkt dat Dre gelijk heeft.

Als losse loc 95108 binnen komt op spoor 7 en via vrijgave rangeren de vertrekkende trein formeert, blijven de bezetspoorlampjes branden.

De fout moet dus ergens schuilen in de uitvoering van rangeeropdracht 14 in combinatie

met FreeShuntSequence 1.

Daarna bijven de bezetspoorlampjes altijd aan, ook na het vertrek van de trein.

Dat is dus werk voor Richard en zijn mannen.

[Hobbyman]

Ook een aardige ontdekking:

Op zondag behoort trein 80114 de hele dag in Hengelo opgesteld te zijn.

Daartoe is in de Timetable een aparte regel ingevoerd waarbij de EntrypointTime op 00.00 is gesteld en ExtraordinaryTrack is ingevuld.

Toen ik die regel maakte was dat voldoende om de trein de hele dag op het spoor te zetten.

Nu niet meer.

Is ondertussen de logica van de software gewijzigd ?

Zo dat de trein door het ontbreken van een vertrektijd niet meer op het spoor wordt gezet ?

De oplossing is natuurlijk eenvoudig:

80114 zal dus ook een regel moeten krijgen in de tabel StabledTrains.

En dus komt er over enige tijd onvermijdelijk weer een nieuwe versie van de dienstregeling.

Groetjes,

Leo

[TjoeTjoe]

Op zondag behoort trein 80114 de hele dag in Hengelo opgesteld te zijn.

Daartoe is in de Timetable een aparte regel ingevoerd waarbij de EntrypointTime op 00.00 is gesteld en ExtraordinaryTrack is ingevuld.

Hmm, ik weet niet beter dan dat als je dit doet, de trein opgesteld wordt tussen EntrypointTime + 1 en de gedefinieerde vertrektijd (PlatformStop)

Als er, en dat zal in dit geval waarschijnlijk wel zo geweest zijn, er geen PlatformStops aanwezig zijn, zal de simulatie deze trein de simulatie "uitrekenen"

Is ondertussen de logica van de software gewijzigd ?

Het afgelopen jaar in ieder geval niet (althans voor de eindgebruiker)

Erwin

[Hobbyman]

Maar ik weet dus 100 % zeker dat dat voldoende was om de trein op te kunnen stellen.

Het ontbreken van de vertrektijd betekent dan dat er geen eindtijd is en dus wordt de trein nu de gehele dag op het spoor geladen.

Als intussen de aanwezigheid van een vertrektijd een absolute voorwaarde is geworden dan zal de oorspronkelijke datainvoer van 80114 niet meer correct werken !

En dus moet 80114 nu wel in StabledTrains worden opgenomen.

Wijzigingen in de logica van de software kunnen dus gevolgen hebben voor de wijze waarop in de Timetable de data moet worden aangeboden aan de sim.

Eerlijk gezegd: ik houd mijn hart vast voor de grote update van de software.

Hoeveel fouten ontstaan daardoor in de datainvoer via de Timetable ?

Leo

[TjoeTjoe]

Maar ik weet dus 100 % zeker dat dat voldoende was om de trein op te kunnen stellen.

Ooo sorry, het was niet mijn intentie om je voor gek oid te verklaren hoor. Excuses als dit zo overkwam.

Had het meer over mijn persoonlijke kennis op dit vlak

Wijzigingen in de logica van de software kunnen dus gevolgen hebben voor de wijze waarop in de Timetable de data moet worden aangeboden aan de sim.

Dat is en zal altijd een risico blijven, ook als dit onbedoeld is.

Ik heb dit zelf een tijdje terug mogen ervaren met een scenario dat ineens helemaal niet meer liep.

Oorzaak, welke inmiddels verholpen is, was een ogenschijnlijk onschuldige wijziging in de logica, met onbedoelde grote gevolgen.

Eerlijk gezegd: ik houd mijn hart vast voor de grote update van de software.

Hoeveel fouten ontstaan daardoor in de datainvoer via de Timetable ?

Ik ga er stiekum een beetje vanuit dat Richard en zijn team, o.a. jou en mijzelf, in een kleine Beta-test betrekken alvorens dit grote evenement plaats zal vinden.

Afgaande op de aangekondige wijzigingen zullen er sowieso wijzigingen plaats moeten vinden in de huidige Timetable, voornamelijk geconcentreerd rondom het lijntje Marienberg-Almelo, de donkere gebieden bij Hengelo, Pathtemplates etc etc

Maar er zullen initieel geen fouten ontstaan in de datainvoer hoor. Eerder andersom (doordenkertje)

Erwin

[signalsoftRC]

we lezen dit alles mee.. geen zorgen...

[Hobbyman]

Dat geeft de burger weer moed en vertrouwen in de toekomst.

En dat was bij mij hard nodig.

Groetjes,

Leo (ziek te bed)