Enkele vragen

[Dre]

Dag allen,

Inmiddels begint m'n eigen dienstregeling een beetje vorm te krijgen, maar ik loop toch tegen een aantal zaakjes aan die ik hier even wil voorleggen:

1. Nu is het nog niet zo'n ontzettend probleem, maar als de nachtovergangen van de IC's in de drgl worden gezet worden de StableTrains toch wel een puntje waar ik tegen wat problemen aan ga lopen. Deze tabel kent namelijk niet de mogelijkheid om voor een opgestelde trein een dag te specificeren. In de oorspronkelijke database is dat me ook al opgevallen. Zo wordt de vroege IC's uit Hgl/Es die opgesteld staan (bijv. 1718) ook in het weekend geladen terwijl de 1718 dan helemaal niet rijdt.

Als je nu een trein in de tabel StabledTrains zet, dan wordt deze elke dag tussen de aangegeven tijdstippen. Ik heb bijvoorbeeld de 407954 die op maandag van 10:22 tot 15:30 uur op 412a staat, terwijl deze op dinsdag t/m vrijdag op dezelfde tijd op 401b behoort te staan. In het weekend staat er overdag geen materieel voor de 7900 over in Enschede.

In principe is er een mogelijkheid om dat allemaal te regelen, middels de kolommen PeriodStart en PeriodEnd, maar 't is nogal omslachtig om dat voor elke week dat de dienstregeling geldt te herhalen. Handiger zou 't zijn als 't hetzelfde zou zijn als in de tabel TimeTable kolommen worden gemaakt voor de weekdag waarop deze trein opgesteld behoort te staan, dat dan met een boolean waarde aangegeven kan worden.

2. Een vraagje omtrent diverse kolommen in de tabel TimeTable, waarvan me de functie niet helemaal duidelijk is:

• IsShuntMov: Ik begrijp dat hiermee aangegeven wordt dat het om een rangeerbeweging gaat. Kort gezegd heb ik zelf alle treinnummers in de serie 400000 het vakje aangevinkt, maar wat is eigenlijk de functie hiervan? Wat is het verschil tussen een rangeerbeweging waarin deze kolom aangevinkt is en een rangeerbeweging waar deze kolom niet aangevinkt is?
• Opmerking1 en Opmerking2: De kolom Opmerking wordt weergeven in de tijdtafel (die met F12 opgeroepen wordt) weergegeven, maar de functie van de kolommen die daarachter komen is me niet helemaal duidelijk. Het lijkt aan te geven waar een trein vandaan komt (locatie óf treinnummer) en ook waar deze naar toe gaat, maar belangrijker, heeft het louter een informatieve functie binnen de database of heeft het ook een inhoudelijke functie?
• Communication: In de originele database hebben sommige treinen die in Hengelo beginnen een entry in de kolom Communication. Bijvoorbeeld "#305a" of "#tank". Wat is daarvan de functie?

[TjoeTjoe]

Dag allen,

Inmiddels begint m'n eigen dienstregeling een beetje vorm te krijgen, maar ik loop toch tegen een aantal zaakjes aan die ik hier even wil voorleggen:

1. Nu is het nog niet zo'n ontzettend probleem, maar als de nachtovergangen van de IC's in de drgl worden gezet worden de StableTrains toch wel een puntje waar ik tegen wat problemen aan ga lopen. Deze tabel kent namelijk niet de mogelijkheid om voor een opgestelde trein een dag te specificeren. In de oorspronkelijke database is dat me ook al opgevallen. Zo wordt de vroege IC's uit Hgl/Es die opgesteld staan (bijv. 1718) ook in het weekend geladen terwijl de 1718 dan helemaal niet rijdt.

Als je nu een trein in de tabel StabledTrains zet, dan wordt deze elke dag tussen de aangegeven tijdstippen. Ik heb bijvoorbeeld de 407954 die op maandag van 10:22 tot 15:30 uur op 412a staat, terwijl deze op dinsdag t/m vrijdag op dezelfde tijd op 401b behoort te staan. In het weekend staat er overdag geen materieel voor de 7900 over in Enschede.

In principe is er een mogelijkheid om dat allemaal te regelen, middels de kolommen PeriodStart en PeriodEnd, maar 't is nogal omslachtig om dat voor elke week dat de dienstregeling geldt te herhalen. Handiger zou 't zijn als 't hetzelfde zou zijn als in de tabel TimeTable kolommen worden gemaakt voor de weekdag waarop deze trein opgesteld behoort te staan, dat dan met een boolean waarde aangegeven kan worden.

Dit is een hele goede opmerking en/of wens: ik ga dit als een feature-request aanmelden in Bug Tracker.

Maar zoals je zelf al opmerkt, op dit moment dus alleen op te lossen met PeriodStart resp -End, maar het is ontdoenlijk om dat voor 52 weken per trein in te gaan zitten voeren.

Als het deze uitbreiding op StabledTrains er met Koln en/of een Amsterdam update meekomt, dan zit het gegarandeerd dadelijk ook in Hengelo

2. Een vraagje omtrent diverse kolommen in de tabel TimeTable, waarvan me de functie niet helemaal duidelijk is:

IsShuntMov: Ik begrijp dat hiermee aangegeven wordt dat het om een rangeerbeweging gaat. Kort gezegd heb ik zelf alle treinnummers in de serie 400000 het vakje aangevinkt, maar wat is eigenlijk de functie hiervan? Wat is het verschil tussen een rangeerbeweging waarin deze kolom aangevinkt is en een rangeerbeweging waar deze kolom niet aangevinkt is?

De trein wordt dan bij het laden van/verschijnen in de sim initieel voorzien van een RET-machinist op de bok.

Edit: wat ik hier boven dus stelde is niet juist. Streep erdoor. Ik ga verder zoeken

Opmerking1 en Opmerking2: De kolom Opmerking wordt weergeven in de tijdtafel (die met F12 opgeroepen wordt) weergegeven, maar de functie van de kolommen die daarachter komen is me niet helemaal duidelijk. Het lijkt aan te geven waar een trein vandaan komt (locatie óf treinnummer) en ook waar deze naar toe gaat, maar belangrijker, heeft het louter een informatieve functie binnen de database of heeft het ook een inhoudelijke functie?

Opmerking1 en Opmerking2zijn geen officiele velden voor de Timetable (lees: worden bij het inlezen door de sim genegeerd).

(In de Asd timetable zijn deze ook niet aanwezig

Communication: In de originele database hebben sommige treinen die in Hengelo beginnen een entry in de kolom Communication. Bijvoorbeeld "#305a" of "#tank". Wat is daarvan de functie?

Hier moet ik je het antwoord helaas op schuldig blijven.

Ik vermoed dat een functie biedt om, met name een RET-machinist te laten bellen zodra hij op een bepaald spoor aangekomen is, zonder dat hiervoor een rangeeropdracht voor aangemaakt hoeft te worden.

Misschien dat Hobbyman het anwoord hier op weet. In de Wiki staat hij ook als ongedocumenteerd.

[signalsoftRC]

de stabled trains kunnen worden "opgehangen" aan een verkerende trein. is de verkerende trein er niet, staat ook de stabled train er niet. gebeurd vooral in Arnhem.

pas op als er 2x een 1718 is....

dan moet je voor jezelf een 1718 een techID geven als 1718mavr en de andere als 1718zazo of zo. de techid dient dan als ophanger aan die trein.

isshuntmov : indien aktief -1 wordt ie NIET geprint in de drgl uitdraai. (da's 't enige). nodig indien je een trein wilt laten opkomen van tractie of akzo maar niet in de drgl wil laten zien.

opm 1 en 2 zijn voor interne filters/opmerkingen tijdens het maken van de drgl.

communication is depricated. niet meer gebruikt.

[Dre]

Een entry in de tabel StabledTrains laat zich niet ophangen een aan technisch treinnummer (een entry die voorkomt in de kolom Train_ID_Tech in de tabel TimeTable). Alleen de tabel MovementOrders maakt gebruik van deze kolom. De tabel StabledTrains maakt gebruik van het treinnummer dat in de simulatie aan de gebruiker getoond wordt (zo worden Train_ID_Tech 407954ma en 407954divr in de simulatie beiden getoond als 407954).

In de tabel StabledTrains kunnen treinen alleen worden opgehangen aan het treinnummer dat in de simulatie wordt gebruikt (het nummer dat in de tabel MovementOrders ook wel "Train_ID_SOFT" wordt genoemd). Daarvoor is zelfs een dropdown-menu aanwezig, dus ik kan alleen maar entry's in deze kolom ingeven die ook daadwerkelijk in de tabel TimeTable staan in de daar aanwezige kolom "Train_ID". Probeer ik in de tabel StabledTrains een entry te maken waar 407954ma als "LinkToTrainID" ingegeven staat, dan wordt mij de standaard Access mededeling "The text you entered isn't an item in the list" (in 't Nederlands) weergegeven. Volgens mij moet deze kolom echter een relatie hebben tot de kolom "Train_ID_Tech" in de tabel TimeTable, immers kent de tabel StabledTrains ook een kolom "TrainID" en daar wordt het treinnummer dat in de simulatie getoond wordt ook al gebruikt (daar zit overigens geen controle op of het een item is dat daadwerkelijk in de lijst voorkomt, ik kan daar 1111 invoeren terwijl er geen entry met dat nummer is in de tabel TimeTable).

[Hobbyman]

Dag allen,

Inmiddels begint m'n eigen dienstregeling een beetje vorm te krijgen, maar ik loop toch tegen een aantal zaakjes aan die ik hier even wil voorleggen:

1. Nu is het nog niet zo'n ontzettend probleem, maar als de nachtovergangen van de IC's in de drgl worden gezet worden de StableTrains toch wel een puntje waar ik tegen wat problemen aan ga lopen. Deze tabel kent namelijk niet de mogelijkheid om voor een opgestelde trein een dag te specificeren. In de oorspronkelijke database is dat me ook al opgevallen. Zo wordt de vroege IC's uit Hgl/Es die opgesteld staan (bijv. 1718) ook in het weekend geladen terwijl de 1718 dan helemaal niet rijdt.

Als je nu een trein in de tabel StabledTrains zet, dan wordt deze elke dag tussen de aangegeven tijdstippen. Ik heb bijvoorbeeld de 407954 die op maandag van 10:22 tot 15:30 uur op 412a staat, terwijl deze op dinsdag t/m vrijdag op dezelfde tijd op 401b behoort te staan. In het weekend staat er overdag geen materieel voor de 7900 over in Enschede.

In principe is er een mogelijkheid om dat allemaal te regelen, middels de kolommen PeriodStart en PeriodEnd, maar 't is nogal omslachtig om dat voor elke week dat de dienstregeling geldt te herhalen. Handiger zou 't zijn als 't hetzelfde zou zijn als in de tabel TimeTable kolommen worden gemaakt voor de weekdag waarop deze trein opgesteld behoort te staan, dat dan met een boolean waarde aangegeven kan worden.

]

In de tabel StabledTrains vormt het veld LinkToTrainID de koppeling met de timetable en daarmee dus ook met de dagen waarop de trein zichtbaar wordt.

We hebben kennelijk nog nooit de behoefte gevoeld om die koppeling te wijzigen naar TrainIDTech.

Wil je dus op maandag iets anders neerzetten dan zul je eerst in de timetable 2 regels moeten maken voor hetzelfde treinnummer. 1 voor de maandag en 1 voor di-vr.

Vervolgens kun je het rangeerdeel in StabledTrains neerzetten, dat moet dan dus ook 2 maal.

Omdat onduidelijk is aan welke record je iets koppelt, heb ik zelf meestal tijdelijk in de timetable het TrainiD voorzien van een dagaanduiding. Die moet je daarna gelijk weer verwijderen natuurlijk.

Let op bij het invoeren van nachtovergangen.

Die moeten altijd in 2 regels staan.

In de eerste regel van tijd x tot 23.59.

In de tweede regel van 00.00 tot tijd y.

De simulatie kan zoals bekend is niet omgaan met de overgang om middernacht.

Bijvoorbeeld een trein opstellen van 22.15 tot 06.35.

Start de sim om 23.10.

23.10 ligt na de eindtijd van 06.35 en dus wordt de trein niet opgesteld.

Rijdt de trein elke dag dan is het invullen van LinkedToTrainID dus erg makkelijk.

Rijdt de trein de volgende dag niet dan in Timetable een eigen regel maken maar dan zonder dienstregelings gegevens. En zo kan een rangeerdeel zelfs op za en zo de hele dag op het opstelterrein staan.

Doorspelen na middernacht is nog steeds geen goed idee.

Het rangeerdeel staat noodgedwongen zonder zijn rangeeropdrachten.

Zou je die wel ingeven dan staat de RET mcn de hele za en zo te roepen dat hij zijn rangeeropdrachten van maandag wil gaan uitvoeren. En hij is niet tot zwijgen te brengen !

Heeft hij geen rangeeropdrachten dan zal hij maandag niet met zijn dienst beginnen.

Ik heb wel eens geprobeerd om dat met datainvoer te manipuleren, maar tot nog toe heb ik geen oplossing gevonden.

Een principiele oplossing is dat de software om 00.01 uur alle treinen die op het scherm staan weer koppelt aan de rangeeropdrachten van die dag. Maar daar zijn de programmeurs nooit aan toe gekomen.

Groetjes,

Leo

[Dre]

Wil je dus op maandag iets anders neerzetten dan zul je eerst in de timetable 2 regels moeten maken voor hetzelfde treinnummer. 1 voor de maandag en 1 voor di-vr.

Vervolgens kun je het rangeerdeel in StabledTrains neerzetten, dat moet dan dus ook 2 maal.

Omdat onduidelijk is aan welke record je iets koppelt, heb ik zelf meestal tijdelijk in de timetable het TrainiD voorzien van een dagaanduiding. Die moet je daarna gelijk weer verwijderen natuurlijk.

Ik denk dat ik met deze oplossing geholpen ben. Hoewel ik het nog steeds handiger zou vinden om in de database zelf aan te geven dat een trein op een bepaalde dag op een bepaald tijdstip moet worden geladen.

Stel even dat we maandag 's avonds de treinen 1775 (ICM-III+ICM-III) en 1677 (ICM-IV), die tezamen de volgende (dinsdag)ochtend als 1724 weer uit Enschede vertrekken. 1775 blijft op 404b staan en 1677 combineert direct bij aankomst een half uur later met deze trein. Tezamen gaan ze als 401724 naar 405b alwaar ze 23:15 uur aankomen en omnummeren naar 1724. Hoe weet een trein die gelinkt is aan het technische treinnummer van de 1724 op dinsdag (bijvoorbeeld "1724di") dat 'ie ook op maandagavond tussen 23:15 en 23:59 op spoor 405b geladen moet worden? Dat ontleent 'ie niet aan het de loop van de trein, aangezien trein 1724di volgens de in de tabel TimeTable ingegeven waarden alleen op dinsdag rijdt.

[Hobbyman]

Dat klopt.

Dus een tweede regel in de Timetable voor trein 1724ma. En dan wel zonder dienstregelingsgegevens.

En een derde regel omdat 1724ma ook in de morgenuren zal rijden.

maar als de trein op ma ook rijdt is de 2e regel dus overbodig.

Dat is het leuke van een IC die elke dag rijdt.

1724 Stabled in de avonduren is dan gekoppeld aan 1724 rijdend in de ochtend van diezelfde dag.

start de sim na 00.00 uur en dan is

1724 Stabled gekoppeld aan 1724 van de volgende dag en dat is dus dezelfde regel in de timetable !

Overigens heeft dat tot gevolg dat de 1724 na zijn vertrektijd op het spoor wordt gezet samen met zijn rangeeropdrachten die hem naar 4b zouden brengen.

Persoonlijk ben ik dan ook fel tegenstander van het gebruik van treinnummers op het opstelterrein.

Daar moeten alleen rangeernummers staan opgesteld !

Dat garandeert een goede werking van de simulatie software.

Het oogt ingewikkelder als het is.

En vergeet niet:

Try and error is ook een goede leermeester.

Groetjes,

Leo

[TjoeTjoe]

In de tabel StabledTrains vormt het veld LinkToTrainID de koppeling met de timetable en daarmee dus ook met de dagen waarop de trein zichtbaar wordt.

We hebben kennelijk nog nooit de behoefte gevoeld om die koppeling te wijzigen naar TrainIDTech.

Op zich, als je een beetje handig bent met Access, kan je de data die in het velden 'LinkedToTrainID' zelf veranderen.

Het selectievak zit nu met aan Timetable.ID gekoppeld met een Opzoek-query: SELECT [TimeTable].[iD], [TimeTable].[Train_ID] FROM [TimeTable];

Wijzig dit in SELECT [TimeTable].[iD], [TimeTable].[Train_ID_Tech] FROM [TimeTable]; en het is voor elkaar.

(Het kan zijn dat je ook even met Kolombreedten moet rommelen, want in eerste instantie kreeg ik dit niet meteen aan de gang)

Mooier is natuurlijk als deze koppeling voortaan in de meegeleverde databases zit, maar a la.

Hoe heb ik overigens deze link met de Timetable table (veld LinkedToTrainID) over het hoofd kunnen zien. Dom dom ... van mezelf.

Toevoegen ma/di...za/zo velden zal waarschijnlijk niet gaan of een heleboel over hoop gooien.

Wil je dus op maandag iets anders neerzetten dan zul je eerst in de timetable 2 regels moeten maken voor hetzelfde treinnummer. 1 voor de maandag en 1 voor di-vr.

Vervolgens kun je het rangeerdeel in StabledTrains neerzetten, dat moet dan dus ook 2 maal.

Omdat onduidelijk is aan welke record je iets koppelt, heb ik zelf meestal tijdelijk in de timetable het TrainiD voorzien van een dagaanduiding. Die moet je daarna gelijk weer verwijderen natuurlijk.

Ik heb wel eens geprobeerd om dat met datainvoer te manipuleren, maar tot nog toe heb ik geen oplossing gevonden.

Een principiele oplossing is dat de software om 00.01 uur alle treinen die op het scherm staan weer koppelt aan de rangeeropdrachten van die dag. Maar daar zijn de programmeurs nooit aan toe gekomen.

Nee, ik ga niet zeggen dat dat makkelijk op te lossen is, dat Middernacht probleem.

Toch ben ik wel benieuwd wat nu het 'grote' probleem hier is. Werkt de sim, na initieel geladen te zijn, intern uitsluitend met tijden (dus excl datum). Zou wel verklaren waarom je bij overgang middernacht van die heerlijk grote vertragingen ziet.

[Hobbyman]

Dat laatste lijkt inderdaad het geval te zijn.

De simulatie lijkt alleen te tellen van 00.00 tot 23.59.

Wil je een trein uit StabledTrains op het scherm hebben dan gebeurt dat alleen als de tijd bij de start van de simulatie groter is dan de begintijd in StabledTrains EN kleiner is dan de eindtijd in StabledTrains.

Dat is mede een gevolg van het feit dat de simulatie uiteindelijk een uit-ontwikkelen en vervolmaken is van de simulatie van Arnhem en Hilversum, die werd uitgereikt bij de opening van de huidige verkeersleidingspost in AmsterdamCS. In die oer-versie kon na het starten van de simulatie een aanvangstijdstip gekozen worden tussen 00.01 en ik meen 22.30 uur. De simulatie liep dan nog door tot 23.59 en dat was dan gelijk het einde van het spel.

Een 2e oplossing voor dit probleem is dan natuurlijk het vergelijken van een volledige datumtijdgroep.

Dan is 2011.06.01.0200 rekenkundig gezien dus wel groter dan 2011.05.31.2330. Maar ik ben geen programmeur. En dus vraag ik me af of er in de ICT wereld niet een simpeler oplossing voorhanden is.

Maar dan nog zal het wijzigen van de software waarschijnlijk een klus zijn die veel te veel tijd vergt.

En dus misschien wel nooit gerealiseerd zal worden.

Kortom, laten we blij zijn met wat we wel hebben !!!

En vergeet niet: treindienstlijden = fun.

Groetjes,

Leo

O ja, vergeet ook niet dat bij NS de treinen niet op tijd rijden, maar,

in volgorde van belangrijkheid: op koffie, op papier, en op rails.

En zelfs deze oude waarheid is nu achterhaald door de computer.

[Dre]

Op zich, als je een beetje handig bent met Access, kan je de data die in het velden 'LinkedToTrainID' zelf veranderen.

Het selectievak zit nu met aan Timetable.ID gekoppeld met een Opzoek-query: SELECT [TimeTable].[iD], [TimeTable].[Train_ID] FROM [TimeTable];

Wijzig dit in SELECT [TimeTable].[iD], [TimeTable].[Train_ID_Tech] FROM [TimeTable]; en het is voor elkaar.

(Het kan zijn dat je ook even met Kolombreedten moet rommelen, want in eerste instantie kreeg ik dit niet meteen aan de gang).

Je kunt natuurlijk eigenhandig dat gaan wijzigen, maar het belangrijkste, leest de simulatie het nog allemaal goed in als ik de opzoekfunctie van het veld 'LinkedToTrainID' wijzig van 'Train_ID' naar 'Train_ID_Tech'? Het liefst houdt ik me zoveel mogelijk aan de opmaak die in de meegeleverde database gehanteerd wordt, aangezien ik er dan zeker van ben dat alles functioneert zoals het je zou mogen verwachten.

Mooier is natuurlijk als deze koppeling voortaan in de meegeleverde databases zit, maar a la.

Hoe heb ik overigens deze link met de Timetable table (veld LinkedToTrainID) over het hoofd kunnen zien. Dom dom ... van mezelf.

Toevoegen ma/di...za/zo velden zal waarschijnlijk niet gaan of een heleboel over hoop gooien.

Toen ik de 'StabledTrains' tabel voor 't eerst zag vroeg ik me eigenlijk af waarom niet dezelfde indeling is gebruikt als in de 'MovementOrders' tabel. Daar wordt namelijk wel standaard de opzoekfunctie gebruikt om te linken naar 'Train_ID_Tech'. Als je dat consequent door de hele database zo doet dan zou 't voor de gemiddelde gebruiker ook een stuk duidelijker zijn. (d.w.z. het is eigenlijk best eenvoudig, maar laat het er voor minder ervaren Access-gebruikers allemaal een stuk ingewikkelder uitzien dan dat het daadwerkelijk is).

Trouwens nog even een vraagje dat hier verband mee houdt:

We hebben vier treinen:

7917 Nijverdal-Enschede, bestaande uit 2x DM'90. Nadat deze om 8:43 in Enschede is aangekomen splitst deze zich in 7932 en 7934. De 7932 vertrekt weer om 9:15, de 7934 een half uurtje later

7919 Nijverdal-Enschede, bestaat uit 2x DM'90. Komt om 9:13 aan en gaat naar Enschede-Opstel.

7921 Nijverdal-Enschede, 2x DM'90. Komt om 9:43 aan en splitst zich in 7936 en 7938 die om respectievelijk 10:15 en 10:45 uit Enschede vertrekken.

7923 Nijverdal Enschede, 2x DM90. Komt om 10:13 aan en gaat net als 7919 naar Enschede-Opstel.

Nu wil ik dat de 7932 en 7934 c.q. 7936 en 7938 altijd juist worden geplaatst als de simulatie wordt geladen op het moment dat beide treinen nog in Enschede staan (dus ergens tussen 8:43 en 9:15). Als ik ze enkel in de tabel TimeTable opneem (met EntryTime voor beiden op 8:43), dan vrees ik dat de simulatie niet altijd de bedoeling snap (bijvoorbeeld trein 7934 wordt vóór trein 7932 opgesteld waardoor trein 7932 niet weg kan). Kan ik ze om dat op te lossen tussen 8:43 en 9:15 niet beter enkel in de tabel StabledTrains laten voorkomen en een latere EntryTime ingeven (voor de 7932 bijvoorbeeld gelijk aan z'n SortingTime/vertrektijd)? Dan zou het toch in 99,9% van de gevallen moeten gaan zoals ik zou willen. Hetzelfde verhaal geldt dan voor de 7936/7938.

Persoonlijk ben ik dan ook fel tegenstander van het gebruik van treinnummers op het opstelterrein.

Daar moeten alleen rangeernummers staan opgesteld !

Dat garandeert een goede werking van de simulatie software.

Ik hanteer de stelregel dat alle treinen die door een RET-machinist worden gereden ook met een rangeernummer (40xxxx-49xxxx) rijden, tenzij dit een rangeerbeweging is die in Almelo plaatsvindt (omdat alleen op de standplaatsen Hengelo en Enschede RET-machinisten dienst hebben). Het rangeernummer wordt daarbij samengesteld op de manier zoals dit officieel volgens de daarvoor bestemde handleiding wordt voorgeschreven, bij 5- of 6-nummerige treinnummers betekent dat, dat de middelste cijfers wegvallen. De nummers 401614, 401716, 401618, 401622 en 401626 zijn gereserveerd voor complete treinen die 's ochtends vanuit de Enschedese tuin worden voorgebracht onder de kap. de nummers 41xxxx-49xxxx gebruik ik 's avonds/'s nachts om deze treinen te formeren uit de treinstellen die 's uitlopen in Enschede.

Treinen die in Hengelo van tractie of Hgl4c komen worden door een RET-machinist voorgebracht als ze naar Oldenzaal óf Enschede gaan en rijden dus met een 40xxxx-nummer (zo wordt 20111 Hengelo-Bad Bentheim als 402011 van tractie via Hengelo-Kap en Hengelo-Oostzijde naar spoor 311 gebracht door een RET-machinist). Treinen die vanaf Hgl4c naar Almelo e.v. gaan worden meteen door een machinist gereden, zonder gebruik te maken van een rangeernummer (77018 Hengelo-Almelo komt dus niet als 407718 van Hgl4c)

[TjoeTjoe]

Toen ik de 'StabledTrains' tabel voor 't eerst zag vroeg ik me eigenlijk af waarom niet dezelfde indeling is gebruikt als in de 'MovementOrders' tabel. Daar wordt namelijk wel standaard de opzoekfunctie gebruikt om te linken naar 'Train_ID_Tech'. Als je dat consequent door de hele database zo doet dan zou 't voor de gemiddelde gebruiker ook een stuk duidelijker zijn. (d.w.z. het is eigenlijk best eenvoudig, maar laat het er voor minder ervaren Access-gebruikers allemaal een stuk ingewikkelder uitzien dan dat het daadwerkelijk is).

Wat je hier schrijft is niet juist (of anders intepreteer ik je woorden niet goed)

- in de tabel MovementOrders is het veld MovementOrders.Train_ID_HARD gelinkt aan het veld Timetable.ID.

- in de tabel StabledTrains is het veld StabledTrains.LinkToTrainID gelinkt aan het veld Timetable.ID.

Echter het verschil in beide tabellen is, dat de opzoek-query verschillende velden uit de tabel Timetable gebruikt voor het presenteren van het treinnummer in de tabellen (in MovementOrders tabel wordt Timetable.Train_ID_Tech getoond, in de tabel StabledTrains wordt Timetable.Train_ID getoond)

We hebben vier treinen:

....

.... Hetzelfde verhaal geldt dan voor de 7936/7938.

Ik denk (niet 100% zeker) dat dit de combinatie moet zijn van een record in de Timetable en de StabledTrains tabel. Het record in de StabledTrains linken met het record in de Timetable (met jawel, het veld LinkedToTrainID )

In StabledTrains kan je de "exacte" positionering ingeven in het veld TrackPosition, in meters vanaf links (???)

[Hobbyman]

Ik denk (niet 100% zeker) dat dit de combinatie moet zijn van een record in de Timetable en de StabledTrains tabel. Het record in de StabledTrains linken met het record in de Timetable (met jawel, het veld LinkedToTrainID )

In StabledTrains kan je de "exacte" positionering ingeven in het veld TrackPosition, in meters vanaf links (???)

Dat is helemaal correct.

Als je 1 trein voor zijn vertrektijd op zijn vertrekspoor wilt hebben dan kun je gebruik maken van Entrypointtime in combinatie met ExtraOrdinaryTrack en ExtraOrdinaryDirection.

In de periode tussen EntrypointTime en Vertrektijd wordt de trein dan op het spoor gezet.

Bij 2 treinen werkt dat niet meer en dus ga je gebruik maken van StabledTrains.

Let op: voor beide treinen moet dan in Timetable de ExtraordinaryTrack en ExtraordinarryDirection niet ingevuld zijn.

Anders wil de sim 4 treinen op dat ene spoor zetten.

Nog een opmerking over de begintijd: Om geen treinen "kwijt" te raken dient deze met een negatieve overlap van de aankomsttijd aangebracht te worden. In het ideale geval is dat -1.

Dus 7917 aankomsttijd 08.43.

7932 en 7934 in Timetable met ExtraOrdinaryTrack en Direction blanco

7932 in StabledTrains met begintijd 08.42 eindtijd 09.15 Trackposition 10 m (wordt gerekend vanaf linkerzijde !)

7934 in StabledTrains met begintijd 08.42 eindtijd 09.45 Trackposition 10 + lengte DM90 + 5 (tussenruimte)

dus totaal is 67, gemakshalve dus 70 meter.

Het resultaat is dan als volgt:

Start de sim om 08.42

Trein 7917 wordt pal voor Enschede op het spoor gezet.

Trein binnen nemen, gaat splitsen, etc etc

Start de sim om 8.43

Trein 7917 wordt niet meer op het scherm gezet.

Trein 7932 en 7934 staan beide op het opgegeven spoor.

Groetjes,

Leo

[Hobbyman]

Echter het verschil in beide tabellen is, dat de opzoek-query verschillende velden uit de tabel Timetable gebruikt voor het presenteren van het treinnummer in de tabellen (in MovementOrders tabel wordt Timetable.Train_ID_Tech getoond, in de tabel StabledTrains wordt Timetable.Train_ID getoond)

En toen ik met de Timetable voor Hengelo ging werken bestond het veld Train_ID_Tech gewoon nog niet.

Kun je nagaan hoe vaak ik wel niet een x in de Train_ID heb toegevoegd en weer verwijderd !

En als ik het vergat dan kwam er altijd wel een berichtje uit Canada met het dringende advies om dat x-je weer te verwijderen want daar kan het TNV systeem echt niet mee omgaan !

[Dre]

Dank beiden voor deze opmerkingen! Daar kan ik weer verder mee...

Dus 7917 aankomsttijd 08.43.

7932 en 7934 in Timetable met ExtraOrdinaryTrack en Direction blanco

7932 in StabledTrains met begintijd 08.42 eindtijd 09.15 Trackposition 10 m (wordt gerekend vanaf linkerzijde !)

7934 in StabledTrains met begintijd 08.42 eindtijd 09.45 Trackposition 10 + lengte DM90 + 5 (tussenruimte)

dus totaal is 67, gemakshalve dus 70 meter.

Nouja... we willen de reizigers niet overbodig ver laten lopen, dus de trackposition moet nog wel een beetje richting het stootjuk opschuiven (aangezien de track position van links = het sein is). Laten we zeggen dat de machinist tot 5 meter van het stootjuk rijdt op bijvoorbeeld spoor 402b. Dan worden de track positions (even snel uit m'n hoofd) 198-(5+52)=141 voor de 7934/7938 en 198-(5+5+52+52)=84 voor trein 7932/7936. Vooral op spoor 403b zou het leuke taferelen opleveren als je ze vlak voor sein 348 neerzet, dan zien de reizigers ergens in de verte twee treinstellen staan...

[TjoeTjoe]

... Vooral op spoor 403b zou het leuke taferelen opleveren als je ze vlak voor sein 348 neerzet, dan zien de reizigers ergens in de verte twee treinstellen staan...

Ja ja jazeker. Vooral voor de reizigers van het type die het liefst op het allerlaatste moment het perron op komen rennen. Van het soort 'Russich-roullette-spelen met-de-vertrektijden-van-een-trein' ... en dus het liefst om 09:14:30 half buiten adem het perron op komen rennen ...

(Leuk, even een spelletje hoofdrekenen )

daar kunnen we dan weer twee typetjes in onderscheiden:

-1- type 'geen-conditie-en-niet-uitgeslapen' : deze rennen met de ogenkleppen op tussen de 5m a 57m (5m+52m) het perron op en 'stappen' de trein in

-2- type 'beetje-wakker-en-eindsprintje-over' : deze rennen met bloed doorlopen ogen tussen de 62m (5m+52m+5m) tot 114m (5m+52m+5m+52m) en laten zich in de trein vallen.

Leuk,een raadseltje, helaas geen prijzen te winnen hier, maar welk type (1 of 2) zou er nu het eerste op de plek van bestemming zijn?

(Noot: nu maar hopen dat mijn reken-capaciteiten me niet in de steek hebben gelaten .. LOL )

[Hobbyman]

En dan is er nog het type dat de dichtsbijzijnde deur neemt, dus van het achterste stel.

En onmiddellijk daarna vertrekt het voorste stel.

[TjoeTjoe]

En dan is er nog het type dat de dichtsbijzijnde deur neemt, dus van het achterste stel.

En onmiddellijk daarna vertrekt het voorste stel.

Sssstttt .... je verraad bijna het antwoord op dit complexe raadsel

[Dre]

Om dat soort luie mensen te bedienen hebben we trein 7970. 's avonds komt 7955 aan in Enschede en die splitst in 7970 (uit 7955v) en 407972 (uit 7955a). 407972 rijdt via 412a om naar een ander perronspoor. Ook de vroege vogels op de zaterdag worden wat dat betreft op hun wenken bediend met de treinen 7924, 7926 en 7928. Zaterdags begint trein 7909 met samenstelling DM'90+DM'90+DM'90 is Hengelo (nee, zoveel mensen zijn er om half 7 's ochtends nog niet op de been tussen Hengelo en Enschede ) is louter om materieel over te brengen, aangezien 7911 en 7913 (die in Enschede keren op 7926 en 7928) zaterdags niet rijden. 7909 komt aan en splitst in 407909 (2x DM'90) en 7924 (1x DM'90). 407909 gaat naar 412a. Vanaf daar worden 407926 en 407928 om 7:30 en 8:00 voorgebracht. Vroeger wilde men trein 7909 nog wel eens langs het perron in drieën delen, waardoor je voor de 7924 dus eerst langs twee lege treinstellen moest lopen (die werden namelijk afgesloten om er niet voor te zorgen dat mensen in het voorste treinstel zouden stappen).

Als trdl houdt het je nog een beetje bezig op de zaterdagochtend. Heel veel werk heb je dan nog niet, het concentreert zich een beetje in Enschede, waar tegelijkertijd ook de eerste IC's naar Schiphol c.q. Den Haag/Rotterdam worden voorgebracht (al komt de 1724 dan als 80128 uit Hengelo). Maar over 't algemeen wordt het wat drukker dan de dienstregeling van 2000. Gelukkig is de korte opvolging van de IC van/naar Duitsland en de IC van/naar Enschede eruit, aangezien de treinen van/naar Duitsland geïntegreerd zijn in de binnenlandse IC-dienst naar Schiphol. In ruil daarvoor krijg je 'n leuk IC-pendeltje tussen Enschede en Hengelo, beladen richting Hengelo, daarna rangeren vanaf 303b via 337 naar 305a, anderhalf uur daar laten staan en leeg naar Enschede voor de volgende pendel (met regelmatige uitwisselingen met de serie 1600/1700).

[signalsoftRC]

even wat achtergrond info over tijden in de sim:

de sim rekent met dag+tijd (DateTime value in .NET). (intern in .NET maken ze van de dag een nummer voor de komma, de tijd een nummer achter de komma. Startende vanaf 1 januari 1899 (of zo). Vandaag is dag 40.000 of zo. 12 uur 's middags is dan 0,5, 1800 uur 0,75)

Met die truuk kunnen tijden gewoon bij elkaar worden opgeteld.

in stabled trains nu een trein opstellen die 's maandagavonds om 23.00 uur komt en 01.00 uur verdwijnt.... da's niet zo makkelijk. De tabel heeft "start tijd" en "eind tijd"... daar de tabel BEWUST geen dag aanduiding heeft (daar ie wordt opgehangen aan een bestaande trein in zo'n geval. rijdt die trein niet, is ook de stabled train er niet!)

Denk eraan dat er ook voor- en feestdagen zijn!

in dat gevalletje moet de stabled train in 2 delen geknipt worden. dit omdat de starttijd vroeger moet zijn als de eindtijd.

dat de rangeeropdrachten niet meekomen is een geheel ander probleem.

om 2300 uur zet de sim de "volgende dag" op door middel van het laden van de dienstregeling gegevens van de volgende dag.

de sim schijnt dan niet de rangbewegingen mee te nemen op de een of andere manier. echter als je om 00.01 start werkt 't wel.

Dit is al 's onderzocht en niet simpel te veranderen, zonder alle andere sims "kapot te maken".

Dat wordt dus een keer een grote verandering voor alle sim.