Dienstregeling versie 23 december 2011

[Dre]

Na even het nieuwe dienstregelingsbestand erbij gehad te hebben, en even gespeeld te hebben (overigens ontzettende dank voor het verzetten van al dit werk Leo!):

- 408200/82700 rijdt met 2x Plan U? Die had Oostnet/Connexxion toen helemaal niet... als ze als trein 31011 en 31013 eenmaal in Mariënberg zijn geweest komt er ook netjes een DE-II voor terug in trein 31020/31022.

- 55440 blijft in Almelo-Goederen maar bellen dat 'ie "graag naar ... voor de ...", terwijl er geen rangeeropdracht is voor de locatie Almelo-Goederen.

[broodje]

Idd dank voor de nieuwe versie. Ik ben nu eens om middernacht begonnen (oke, om precies te zijn 1 over 12) om te zien hoe de nacht verloopt. Het extra rangeren van de reizigersstellen bevalt me wel. Ik blijf het enigszins spannend vinden om allemaal materieel in de weg te hebben staan zonder personeel. Ik vraag me elke keer weer af of er wel op tijd een machinist is .

Ik merkte alleen wel dat er ergens in de nacht stel 1722 wordt gevormd op spoor 406, dit stel heeft netjes een machinist klaar zitten en geen rangeer opdrachten. Terwijl de trein pas een uur of 5 later vertrekt van Esd en dan vanaf het perron, niet vanaf het opstel terrein.

Verder komt 52140 binnen op Almelo spoor 207, dit past echter niet omdat hier ook twee rangeerdelen staan van 59418 en 59414. Spoor 209 is echter wel vrij. Zowel de drgl als de rangeeropdrachten kloppen dan overigens niet. Overigens vroeg ik mij af of het voor dit soort rangerende treinen niet makkelijker als ze met de rangeer opdrachten op ieder spoor vrijgave rangeren kunnen nemen? dan heb je als tdrl ook iets meer ruimte als er problemen zijn. (in mijn 4(!) extra goederen treinen direct achter elkaar naar Bentheim)

[Dre]

De 'NewDriverPrepTime' van trein 407924 moet even gewijzigd worden, die staat nu op 23:35:00, maar dat is voor een trein die om 07:05 vertrekt reikelijk laat. 6:45 lijkt me een prima tijdstip om de omhaalactie via 412a naar 402b te beginnen.

[TjoeTjoe]

Ik merkte alleen wel dat er ergens in de nacht stel 1722 wordt gevormd op spoor 406, dit stel heeft netjes een machinist klaar zitten en geen rangeer opdrachten. Terwijl de trein pas een uur of 5 later vertrekt van Esd en dan vanaf het perron, niet vanaf het opstel terrein.

Als mijn geheugen me niet al teveel in de steek laat, is dit een bekend oud probleem. Een probleem dat niet door de timetable wordt veroorzaakt, maar een hiaat in de simulatie.

Erwin

[broodje]

Ah, nu je het zegt, je hebt gelijk, trein 1722 was al lang besproken: http://www.signalsoft.info/forum/index.php?showtopic=428&view=findpost&p=2215 . Ik twijfelde ook al een beetje of er niet al eens wat over gezegd was. Uiteindelijk had ik natuurlijk gewoon even moeten zoeken...

[Dre]

Bij de rangeeropdrachten voor de 401726 mag de keeropdracht op Enschede-Kap zowel bij de ma-do trein als vr-trein verwijderd worden, aangezien trein 411726 (waar 401726 na het keren in omnummert) deze opdracht ook heeft en het ertoe leidt dat trein 1726 vertrekgereed staat richting Gronau. [Overigens zie ik de noodzaak niet zo om van 401726 eerst om te nummeren naar 411726 [een treinnummer waar bovendien geen TimeTable-entry voor is, waardoor het keren onnodig lang duurt] en vervolgens naar 1726 i.p.v. direct van 401726 naar 1726.

Edit: Voor trein 1617 geldt vrijwel hetzelfde. Die heeft alleen een opdracht om in Enschede-Kap om te nummeren tot 1628. Vanwege het ontbreken van een keeropdracht staat die vervolgens weer vertrekgereed in de richting Gronau.

Edit2: De rangeerdelen 401644 en 407921 willen tegelijk naar Enschede-Opstel spoor 401b. Op zich is dat natuurlijk geen probleem, ware het niet dat beiden enkel de rangeeropdracht hebben om te nummeren in een ander treinnummer (411644/417924), waardoor ze oprijden tot vlak voor het sein (trein 401644 rijdt door tot vlak voor sein 352, trein 407921 rijdt vlak voor sein 344). Eén van beiden moet dus de opdracht krijgen om afstand te houden van het sein op Enschede-Kap 401b. Óf trein 401644 moet in Enschede-Opstel op 401b ongeveer 60/70 meter stoppen vóór het sein, óf trein 407921 moet ongeveer 90 meter vóór het sein in Enschede-Opstel op 401b stoppen. Dan past het met z'n tweeën.

Daarnaast heeft trein 1625 een verkeerde doorkomsttijd in Enschede Drienerlo, die staat op 8:58 (doorkomsttijd van de 1621), dat moet een uur later zijn.

Edited December 26, 2011 by Dre

[Hobbyman]

Na even het nieuwe dienstregelingsbestand erbij gehad te hebben, en even gespeeld te hebben (overigens ontzettende dank voor het verzetten van al dit werk Leo!):

- 408200/82700 rijdt met 2x Plan U? Die had Oostnet/Connexxion toen helemaal niet... als ze als trein 31011 en 31013 eenmaal in Mariënberg zijn geweest komt er ook netjes een DE-II voor terug in trein 31020/31022.

- 55440 blijft in Almelo-Goederen maar bellen dat 'ie "graag naar ... voor de ...", terwijl er geen rangeeropdracht is voor de locatie Almelo-Goederen.

Tja, dat er na zoveel wijzigingen ergens nog een foutje zou zijn blijven hangen, had ik wel verwacht.

De snelheid waarmee jullie die foutjes ontdekken is echt verbazingwekkend.

Complimenten voor de nauwkeurigheid waarmee je de simulatie bekijkt.

82700 was een speciaal treintje, reed met ConsistTemplate 16 maar bestond toch uit 2x DE-II.

De ConsistTemplate werd overruled door de samenstelling die vermeld stond in de tabel Consists.

Bij het toepassen van de PathTemplate Hgl-Aml ontdekte ik dat de trein ook de binding met zijn Pathtemplate kwijtraakte.

Het werkte gewoon niet op de juiste wijze. Het enige verschil wat de oorzaak zou kunnen zijn werd gevormd door de afwijkende Consist.

Dus fluks een eigen ConsistTemplate 121 aangemaakt en de 2 regels uit Consists verwijderd.

En alles werkte weer zoals het behoort te werken.

82700 wel voorzien van ConsistTemplate 121, maar 408200 dus vergeten.

Na deze analyse kom ik tot de conclusie dat de tabel Consists geen recht van bestaan heeft.

Het maakt immers niet uit of je 2 records in de tabel Consists moet aanmaken of dat je de tabel ConsistTemplates van dezelfde 2 records voorziet.

Voor de mensen die zelf de database kunnen/willen wijzigen:

In de Timetable moet bij record ID 1901 en 1904 de ConsistTemplate gewijzigd worden in 121.

trein 55440 bevat geen fouten.

Sinds de laatste update wordt door ieder treindeel na het uitvoeren van koppelen of splitsen een telerail oproep gegenereerd.

Zelfs als de trein niet bemand is en zelfs als daar geen opdracht voor gegeven is.

Deze bug wordt steeds irritanter: Je weet niet meer of het een valse oproep is of een juiste oproep.

Voorlopig hanteer ik voor mij zelf de regel dat een Telerailoproep na koppelen of splitsen altijd een valse oproep is.

Een RETmachinist zou dat per portofoon doen.

Het wordt natuurlijk nog erger als je weet dat na verloop van tijd de echte oproep ook niet meer wordt geproduceerd.

EEN UPDATE DIE DEZE "EENVOUDIGE" BUGS REPAREERT, IS ZEER GEWENST.

[Hobbyman]

Idd dank voor de nieuwe versie. Ik ben nu eens om middernacht begonnen (oke, om precies te zijn 1 over 12) om te zien hoe de nacht verloopt. Het extra rangeren van de reizigersstellen bevalt me wel. Ik blijf het enigszins spannend vinden om allemaal materieel in de weg te hebben staan zonder personeel. Ik vraag me elke keer weer af of er wel op tijd een machinist is .

Ik merkte alleen wel dat er ergens in de nacht stel 1722 wordt gevormd op spoor 406, dit stel heeft netjes een machinist klaar zitten en geen rangeer opdrachten. Terwijl de trein pas een uur of 5 later vertrekt van Esd en dan vanaf het perron, niet vanaf het opstel terrein.

Dat is inderdaad niet juist.

In deze versie zijn alle treinnummers op het opstelterrein vervangen door rangeernummers.

Er zou dus een 401722 moeten ontstaan.

Voor de mensen die zelf de database kunnen/willen aanpassen:

In de tabel MovementOrders moeten de records met ID 1242 en 1246 gewijzigd worden:

In het veld CoupleNewID "1722" wijzigen in "401722".

[Hobbyman]

Verder komt 52140 binnen op Almelo spoor 207, dit past echter niet omdat hier ook twee rangeerdelen staan van 59418 en 59414. Spoor 209 is echter wel vrij. Zowel de drgl als de rangeeropdrachten kloppen dan overigens niet. Overigens vroeg ik mij af of het voor dit soort rangerende treinen niet makkelijker als ze met de rangeer opdrachten op ieder spoor vrijgave rangeren kunnen nemen? dan heb je als tdrl ook iets meer ruimte als er problemen zijn. (in mijn 4(!) extra goederen treinen direct achter elkaar naar Bentheim)

Hé, merkwaardigerwijze heeft die facultatieve trein mij nog nooit dwars gezeten.

Binnenkomen op spoor 9 is dus de oplossing, Maar ik moet wel even controleren of die vrijgave rangeren daar ook werkt.

Een vrijgave rangeren op ieder spoor werkt helaas niet.

Er is een vaste binding met het spoor en de uit te voeren Sequence in de software.

De trein binnen nemen op een ander spoor betekent dus ook dat je handmatig de rangeeropdracht moet aanpassen.

Voor de mensen die zelf de database kunnen/willen aanpassen:

In de TimetableStops het aankomstspoor in Almelo wijzigen in 9,209,

en niet te vergeten: PathTemplate wijzigen in 21.

In de tabel MovementOrders het record met ID 1935 wijzigen:

Ordertrack moet zijn A72T en FreeShuntSequence moet zijn 5

[Hobbyman]

De 'NewDriverPrepTime' van trein 407924 moet even gewijzigd worden, die staat nu op 23:35:00, maar dat is voor een trein die om 07:05 vertrekt reikelijk laat. 6:45 lijkt me een prima tijdstip om de omhaalactie via 412a naar 402b te beginnen.

Die wijziging had ongedaan gemaakt moeten worden.

De tijd 6.35 wijzigen in 23.35 had te maken met het feit dat ik voor mijzelf die vervelende, onzichtbare mcn, met de naam Bug, tijdelijk tot zwijgen wilde brengen. Dat lukt op die manier heel goed, maar dan moet je die wijziging ook weer ongedaan maken in de hoop dat er ooit eens een update van de software komt.

[Hobbyman]

Daarnaast heeft trein 1625 een verkeerde doorkomsttijd in Enschede Drienerlo, die staat op 8:58 (doorkomsttijd van de 1621), dat moet een uur later zijn.

De database wordt aangepast.

[Hobbyman]

Edit2: De rangeerdelen 401644 en 407921 willen tegelijk naar Enschede-Opstel spoor 401b. Op zich is dat natuurlijk geen probleem, ware het niet dat beiden enkel de rangeeropdracht hebben om te nummeren in een ander treinnummer (411644/417924), waardoor ze oprijden tot vlak voor het sein (trein 401644 rijdt door tot vlak voor sein 352, trein 407921 rijdt vlak voor sein 344). Eén van beiden moet dus de opdracht krijgen om afstand te houden van het sein op Enschede-Kap 401b. Óf trein 401644 moet in Enschede-Opstel op 401b ongeveer 60/70 meter stoppen vóór het sein, óf trein 407921 moet ongeveer 90 meter vóór het sein in Enschede-Opstel op 401b stoppen. Dan past het met z'n tweeën.

Dat is merkwaardig, want bij mij werkt het wel.

Dat komt omdat 407921 reeds is voorzien van een rangeeropdracht 9.

Hij stopt op spoor 1b dus onmiddellijk achter sein 352.

Zodat er voldoende ruimte overblijft voor de 401644 die via spoor 12a naar 1b komt.

Overigens een heel gepuzzel want de rangeeropdrachten 7 en 8 blijken niet te werken op spoor 1b.

Het lijkt wel of ze ingehaald/afgebroken worden door de volgende rangeeropdrachten.

Misschien is het wel handig om 401644 ook van een rangeeropdracht 9 te voorzien.

Iemand die eerst 401644 naar 1b dirigeert komt dan niet in de problemen.

[TjoeTjoe]

Bij het toepassen van de PathTemplate Hgl-Aml ontdekte ik dat de trein ook de binding met zijn Pathtemplate kwijtraakte.

Het werkte gewoon niet op de juiste wijze. Het enige verschil wat de oorzaak zou kunnen zijn werd gevormd door de afwijkende Consist.

Dus fluks een eigen ConsistTemplate 121 aangemaakt en de 2 regels uit Consists verwijderd.

En alles werkte weer zoals het behoort te werken.

82700 wel voorzien van ConsistTemplate 121, maar 408200 dus vergeten.

Ik heb getracht om met eerdere versies van de Hengelo drgl bovenstaande te traceren, maar ik denk zo maar dat dit probleem nooit de release-versies gehaald heeft.

Als ik het dus goed begrijp werkt het gebruiken van "afwijkende" consists, middels de tabel Consists correct. Alleen gebeurt er dan iets vreemds met het PathTemplate.

Dat is wel een onderzoekje waard.

Na deze analyse kom ik tot de conclusie dat de tabel Consists geen recht van bestaan heeft.

Het maakt immers niet uit of je 2 records in de tabel Consists moet aanmaken of dat je de tabel ConsistTemplates van dezelfde 2 records voorziet.

Ik deel deze mening niet. Dat het technisch gezien niet uitmaakt of men de Consists tabel gebruikt voor de afwijkende treinsamenstellingen of de ConsistTemplates tabel is uiteraard correct.

Maar naar mijn weten is het uitgangspunt dat in ConsistTemplates de treinsamenstellingen worden gedefinieerd die veevuldig voor de verschillende treinen benodigd zijn.

De Consists tabel is voor die treinen, die qua-samenstelling afwijken van de regelmaat.

De Timetable tabel verlangt altijd (leo weet dat natuurlijk) een ConsistTemplateID en een PathTemplateID, ook als men in de tabel Consist of Paths een afwijkend iets wil definieren voor een trein

EEN UPDATE DIE DEZE "EENVOUDIGE" BUGS REPAREERT, IS ZEER GEWENST.

Hoe graag dit misschien gewenst is, dit is helaas naar mijn informatie niet zo eenvoudig als het van de buitenaf lijkt.

Tijdens de ontwikkeling van Köln en Amsterdam zijn er in de simulatie-kern enkele zaken ingrijpend gewijzigd.

Even Hgl of Bs updaten is er vanaf dat moment niet meer bij. Daarbij opgeteld de functionaliteit die het Signalsoft-team in het vooruitzicht heeft gesteld voor deze twee sims, is het wellicht concreet van een complete re-release van Hgl. Met al het nodige (her)test-werk erbij. In Jip en Janneke taal: de carrosserie (de buitenkant) nagenoeg hetzelfde met her en der een extra spoiler (de extra's), maar hele nieuwe motor onder de motorkap.

Erwin

[Hobbyman]

Als er een afwijkende consist is moet deze ook in de Timetable een binding hebben met een trein die op de dag waarop de afwijkende consist nodig is rijdt.

Dat betekent om te beginnen dat er een extra regel noodzakelijk is in de Timetable.

Die extra regel met een willekeurige ConsistTemplate haalt dan zijn samenstelling uit de tabel Consists.

Het zou er anders uit zien als ik zonder een extra trein in de Timetable in de tabel Consists niet alleen zou kunnen aangeven wat de afwijkende treinsamenstelling is maar ook op welke dag dat is.

Dan en uitsluitend dan is het nuttig, immers geen extra regel in de tabel Timetable en wel een afwijkende treinsamenstelling op die specifieke dag.

Zoals de zaken nu staan is er op dit punt sprake van een onvoldoende nauwkeurige analyse van de database en is de hele functionaliteit van de tabel Consists overbodig.

82700 is ook geen afwijking van de normale samenstelling van een trein. Op alle dagen dat hij rijdt is de samenstelling 2x DE-II en dus hoort die samenstelling gewoon in de tabel ConsistTemplates te staan.

Hoe heette dat ook alweer in het mbo van zoonlief? De database normaliseren of zoiets ?

Groetjes,

Leo

[Hobbyman]

Hoe graag dit misschien gewenst is, dit is helaas naar mijn informatie niet zo eenvoudig als het van de buitenaf lijkt.

Tijdens de ontwikkeling van Köln en Amsterdam zijn er in de simulatie-kern enkele zaken ingrijpend gewijzigd.

Even Hgl of Bs updaten is er vanaf dat moment niet meer bij. Daarbij opgeteld de functionaliteit die het Signalsoft-team in het vooruitzicht heeft gesteld voor deze twee sims, is het wellicht concreet van een complete re-release van Hgl. Met al het nodige (her)test-werk erbij. In Jip en Janneke taal: de carrosserie (de buitenkant) nagenoeg hetzelfde met her en der een extra spoiler (de extra's), maar hele nieuwe motor onder de motorkap.

Erwin

Dat reealiseer ik mij ook wel, Zie het maar als een uiting van mijn toenemende frustratie.

Het is zo jammer dat deze mooie simulatie door deze foutjes wordt geplaagd.

Enne, mijn excuses voor de hoofdletters.

Leo

[TjoeTjoe]

Als er een afwijkende consist is moet deze ook in de Timetable een binding hebben met een trein die op de dag waarop de afwijkende consist nodig is rijdt.

Dat betekent om te beginnen dat er een extra regel noodzakelijk is in de Timetable.

Die extra regel met een willekeurige ConsistTemplate haalt dan zijn samenstelling uit de tabel Consists. .........

Waar ik meer op doelde, was bijvoorbeeld de samenstelling van de goederentreinen.

In principe hebben deze naar mijn idee allemaal een unieke samenstelling, en zouden deze dus in aanmerking komen voor een unieke Consist-definitie in de Consists tabel, in plaats van voor elke unieke samenstelling hiervoor een ConsistTemplate te definieren. Maar als gesteld, in technische zin maakt het niet uit welke weg men bewandelt.

Overigens: dit is geen op-/aanmerking op de huidige Hgl timetable, maar een (persoonlijk) inzicht over wanneer welke tabel gebruikt zou kunnen worden.

Erwin

[TjoeTjoe]

Dat reealiseer ik mij ook wel, Zie het maar als een uiting van mijn toenemende frustratie.

Het is zo jammer dat deze mooie simulatie door deze foutjes wordt geplaagd.

Enne, mijn excuses voor de hoofdletters.

Ik ben niet boos hoor Eigenlijk was mijn tekst meer bedoeld voor diegenen die meelezen, en wellicht niet begrijpen waarom een update voor Hgl lang op zich laat wachten.

En zeker jij mag van mij, met al dat werk dat je voor de drgl verzet, best zo nu en dan even stoom afblazen

Erwin

[Dre]

Complimenten voor de nauwkeurigheid waarmee je de simulatie bekijkt.

Ik heb momenteel 'iets' meer tijd om een database te testen, speciale gevallen (unieke treinen zoals trein 82700) kijk ik sowieso altijd even na). Daarnaast ken ik van m.n. de database vrijwel alle functies, als iets niet helemaal vlekkeloos verloopt duik ik meteen de database in om daar te kijken wat opvalt wat het euvel veroorzaakt. Net als een 'echte' trdl denk ik altijd enkele stappen vooruit, vooral als twee treinen kort achter elkaar naar hetzelfde spoor willen. Ik geef hier dan wel de oneffenheden door (die overigens inherent zijn aan het verzetten van héél veel werk in een korte tijd), maar in zeker 95% van de gevallen gaat het allemaal perfect zoals het hoort te gaan.

[Dre]

Nog twee kleintjes:

7936 splitst in Hengelo-Kap op 302b in 7936 die verder richting Zl gaat en 407936, die zonder rangeeropdrachten blijft staan. Gezien de omschrijving is het de bedoeling dat deze op de tankplaat z'n dorst gaat lessen en dus naar Tc1 moet. Daar moeten dus drie rangeeropdrachten bij: Breek de trein af in Hengelo-Kap op ieder spoor, geef de trein over aan een RET machinist op diezelfde locatie (met NewDriverPrepTime om 10:20, dan zit 'ie de 7225 niet in de weg) en als laatste de opdracht om de trein af te breken op Hengelo-Oostzijde op spoor Hgl Tc 1.

Rangeerdeel 407964 gaat om 16:40 uur van Enschede-Opstel 401b naar Enschede-Kap 401c, alwaar deze weer wordt afgebroken. Trein 7951 heeft echter niet de opdracht om te combineren met trein 407964 en als trein 7964 richting Hgl/Zl te vertrekken, maar heeft enkel de opdrachten om kop te maken in Enschede-Kap op ieder spoor en aldaar het treinnummer te wijzigen in 7964.

[Hobbyman]

De splitsingsopdracht van 7936 stamt nog uit de oude materieelomloop.

De rangeeropdracht kan dus verwijderd worden.

7951 kijgt zijn opdracht om te combineren met 407964.

Bij 7951vr was de opdracht al aanwezig.

[Hobbyman]

Bij de rangeeropdrachten voor de 401726 mag de keeropdracht op Enschede-Kap zowel bij de ma-do trein als vr-trein verwijderd worden, aangezien trein 411726 (waar 401726 na het keren in omnummert) deze opdracht ook heeft en het ertoe leidt dat trein 1726 vertrekgereed staat richting Gronau. [Overigens zie ik de noodzaak niet zo om van 401726 eerst om te nummeren naar 411726 [een treinnummer waar bovendien geen TimeTable-entry voor is, waardoor het keren onnodig lang duurt] en vervolgens naar 1726 i.p.v. direct van 401726 naar 1726.

Edit: Voor trein 1617 geldt vrijwel hetzelfde. Die heeft alleen een opdracht om in Enschede-Kap om te nummeren tot 1628. Vanwege het ontbreken van een keeropdracht staat die vervolgens weer vertrekgereed in de richting Gronau.

Dat verdient wel enige toelichting van mijn zijde.

Kort samengevat:

Soms gaat het licht uit en soms duurt het wat langer voor ik de lichtschakelaar weer gevonden heb.

Anders gezegd:

Dit is het resultaat van een worsteling met teveel rangeeropdrachten voor de nieuwe rangeernummers op het opstelterrein.

Als gevolg daarvan werd de vraag voor een rijweg van de RET mcn ernstig verminkt.

Herverdelen van de rangeeropdrachten over 2 treinnummers leek de oplossing.

En natuurlijk werkt dat dan ook. Het verdient niet de schoonheidsprijs en ik ben blijven zoeken naar de juiste oplossing.

En toen vond ik de lichtschakelaar weer terug.

Die bevindt zich in een andere trein en ik had 'm al weer meer dan een jaar niet hoeven toepassen.

Zou het herinneringsvermogen op oudere leeftijd dan toch teruglopen ?

Het rangeerdeel krijgt dus toch alle benodigde rangeeropdrachten, maar in een andere volgorde.

Bij de trein die ontstaat op spoor 4b wordt het veld DoNotTakeMOOnRenumber aangevinkt.

En het resultaat is verbluffend:

De vraag voor een rijweg van de RETmcn wordt correct weerggeven.

Alle rangeeropdrachten worden netjes uitgevoerd.

En de IC staat netjes vertrekgereed aan het perron.

Nu nog even alle 19 nieuwe rangeernummers voorzien van de juiste rangeeropdrachten.

En dan volgt in de 1e week van het jaar een nieuwe versie van de dienstregeling.

Naar verwachting zal dat de laatste versie van de drgl zijn, in afwachting van de update van de software.

Voor iedereen een gezond en voorspoedig 2012,

Leo

[Dre]

Weer wat opvallende zaken:

- De nachtovergang (en dan bedoel ik niet doorspelen na 23:59 uur) gaat bij trein 7981 op vrijdag (de nacht van donderdag op vrijdag) niet goed. Als de simulatie om 0:01 uur gestart wordt op een vrijdag dan ontbreekt trein 7981 (die op de overige dagen dan als StabledTrain opgesteld staat op spoor 202b). Dat komt omdat de simulatie trein 7981mado niet laadt (simpelweg omdat het geen maandag, dinsdag, woensdag of donderdag is) en trein 7981vr rijdt pas 's avonds. Voor trein 7981 moet dus een aparte vermelding komen van trein 7981 die op donderdag om 23:50 uur van Wierden komt en over de nachtovergang heen getrokken wordt. Wellicht is het verstandig dat de nachtgrens voor omlopen, analoog aan het grote voorbeeld, naar 2:00 uur getrokken wordt. Of de grens van 4:00 uur, die voor dienstregelingen wordt gebruikt (of de simulatie moet het regeltje "Treinen tussen 0:00 en 4:00 uur rijden in de nacht volgend op de genoemde dag" worden aangeleerd).

- Trein 55441 blijf ik maar een vreemde vinden. 's ochtends gaat trein 55440 naar de Akzo, de loc komt als loc>55407 terug. Gaat vervolgens als 55407 met wat ketelwagens naar de Servo in Delden en eindigt via 55408 Ddnser-Hgl, 55401 Hgl-Aml en 55402 Aml-Emnakz uit beeld. Die wagens die elke ochtend naar de Akzo in de Hengelose haven worden gesleept zien we echter nooit terug. Op de losweg in Hengelo staat ogenschijnlijk een arsenaal aan lege wagens (uit het raam van Post T zie ik echter niets ), want er wordt nooit wat aangevoerd, maar elke middag komt trein 95108 er wel wat weg halen. Moet trein 55441 niet gewoon van spoor 340 komen? (of wellicht een rangeerbeweging van Akzo naar 307, daar de vrijgave rangeren voor 8-19 nemen en daar de trein opstellen, de loc gaat vervolgens naar tractie.

- De rangeerbewegingen die voort komen uit trein 1787 (a. Es om 01:32 uur) en de vertrektijd van trein 80182 (01:52 uur) lijken te suggereren dat 1787 in Enschede-Kap op 404b splitst in 420182, die op 414 met 410182 tot 80182 combineert, en 401787 die via Enschede-Westzijde naar 406 wil om met trein 421685 trein 401722 gaat vormen. Als je de rangeeropdrachten namelijk laat uitvoeren zoals ze gepland zijn, dan haalt trein 80182 z'n vertrektijd niet, omdat trein 411787 nogal wat tijd uittrekt voor de remproef.

[Hobbyman]

Weer wat opvallende zaken:

- De nachtovergang (en dan bedoel ik niet doorspelen na 23:59 uur) gaat bij trein 7981 op vrijdag (de nacht van donderdag op vrijdag) niet goed. Als de simulatie om 0:01 uur gestart wordt op een vrijdag dan ontbreekt trein 7981 (die op de overige dagen dan als StabledTrain opgesteld staat op spoor 202b). Dat komt omdat de simulatie trein 7981mado niet laadt (simpelweg omdat het geen maandag, dinsdag, woensdag of donderdag is) en trein 7981vr rijdt pas 's avonds. Voor trein 7981 moet dus een aparte vermelding komen van trein 7981 die op donderdag om 23:50 uur van Wierden komt en over de nachtovergang heen getrokken wordt. Wellicht is het verstandig dat de nachtgrens voor omlopen, analoog aan het grote voorbeeld, naar 2:00 uur getrokken wordt. Of de grens van 4:00 uur, die voor dienstregelingen wordt gebruikt (of de simulatie moet het regeltje "Treinen tussen 0:00 en 4:00 uur rijden in de nacht volgend op de genoemde dag" worden aangeleerd).

.

Au, au,au,

Je weet de open zenuw van de sim wel erg hard te raken

7981 vormt het ultieme probleem.

De trein start op dag D en de drgl loopt door op D+1.

Als de trein elke dag hetzelfde moet doen is dat geen probleem.

Op dag D+1 (na middernacht) wordt de trein niet meer geladen.

Dat heb ik opgelost door de trein via StabledTrains te laten laden.

Hij laadt dan wel de rangeeropdrachten van dag D+1, terwijl hij de rangeeropdrachten van dag D had moeten uitvoeren !

Wil dat correct gaan dan zou voor elke combinatie D en D+1 een uniek treinnummer benodigd zijn.

Dus in totaal 7 verschillende treinnummers (na normaliseren zijn dat er 3, maar dat terzijde)

Dat is in de presentatie van een drgl natuurlijk onmogelijk.

Na ongeveer 2 jaar (natuurlijk niet voortdurend) overdenken van dit probleem denk ik dat er een oplossing mogelijk is:

Door de verschillen per dag 1 niveau lager te leggen, dus bij een rangeernummer zou ik de volgende situatie moeten krijgen:

De trein heeft elke dag dezelfde opdracht, nl op het eindstation treinnummer wijzigen in een rangeernummer.

Het rangeernummer is daarmee de binding met 2 opeenvolgende dagen kwijt.

En dus kunnen er per dag verschillende opdrachten worden uitgevoerd.

Ook de samenstelling van de trein kan dan per dag verschillen.

(7981 bestaat vr en za uit 2 stellen)

Of het ook zo kan werken, is nog maar de vraag.

Op Ma vroeg na aankomst eerst omnummeren en dan koppelen ? werkt dat eigenlijk wel ?

Als er geen andere werkzaamheden zijn, ben ik toch gauw 4 weken bezig met ontwerp en uittesten.

Als het werkt zou het wel de moeite waard zijn.

Leo

[Hobbyman]

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.

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

[Raymond]

Op Ma vroeg na aankomst eerst omnummeren en dan koppelen ? werkt dat eigenlijk wel ?

Hoewel ik niet de moeite heb genomen om het middels die methode uit te testen heb ik wel een vermoeden dat het niet werkt. Wanneer je op dit moment in de sim een trein op bezet spoor binnenneemt en de rangeeropdracht combineren bent vergeten stopt de trein immers voor het andere treinstel. Als je daarna alsnog de rangeeropdracht combineren toevoegt en aan de machinist geeft, wordt die opdracht niet uitgevoerd, omdat de trein zich al op het betreffende spoor bevindt. In dat geval moet de trein dus eerst kopmaken en naar een ander spoor en middels opnieuw kopmaken alsnog naar het spoor om te combineren. Met andere woorden: de simulatie kent op dit moment geen combineren vanuit stilstand optie (wat in je voorstel wel essentieel is, omdat het omnummeren alleen bij stilstand gebeurt).