Ett försök till ett nytt modernt svenskt signalsystem!

[blomsson]

Hej!
Jag har precis påbörjat ett projekt till att göra ett nytt modernt signalsystem.
Tanken är att det skall baseras på regler och föreskrifter som finns i Säo (numera TTJ), och vara från tiden sent femtiotal och framåt.
Udda/jämn-principen och fjb-numrering (21,22,31,32, osv) är två fundamentala principer för att det ska fungera.

I detta system kommer man inte att kunna ställa in varje signalbild för sig, utan signalernas beteende är baserat på att signalens typ är korrekt i förhållande till den signalbild man vill kunna (får) visa.
Tanken är också att det ska ingå en liten guide så att avstånd och signaltyp blir korrekt vid skapande av banor.

Följande kriterier kommer att styra signalbilden:
1. Hinderfriheten
2. Ev. växel-hastigheter
3. Avståndet till nästa signal
4. Signalbilden på nästa signal
5. Signaltyp
6. Säkert något jag inte kommer på just nu!!

Det kommer också att finnas ett fullt fungerande linjeblock.

Del 2:
Införande av stationsobjekt som sköter om stationsautomater (framförallt på mindre stationer), detta finns klart i huvudet redan(peppar, peppar)! Fjtkl/tkl för att skapa verklighetsliknande tåg-förning och läggning av tågvägar/växlingsvägar och även lokal-frigiving av växlar (finns väl ett tiotal ideér).

Del 3:
ATC! Detta är till viss del ett mer komplicerat projekt, eftersom en korrekt utplacering av objekt som ska ge ATC-besked kräver en del extra kunskaper. Också det faktum att fordons beteende och till viss del placeringen av signaler och tavlor påverkas av om det är en bana med ATC eller ej.
Det går säkert att göra en "ATC-light" variant som ersätter "hubben" som ju är en sorts övervakning även det!
Programmeringsmässigt så vet jag inte hur svårt det är och många utav fordonen är ju redan scriptade, men det blir en senare fråga!

En grundförutsättning för att detta ska fungera är att mitt signalsystem kan fungera tillsammans med det material som STL har skapat, framförallt vägskydd, tavlor och fordon. Kommer troligtvis inte att fungera med svenolovs scriptade signalsystem, ej heller det äldre signalsystemet om det inte går att göra någon överbryggning i framtiden.

Jag använder mig utav samma objekt (osynlig master + scenery-signal) som svenolov och med samma namnkonvention. Jag tror dock inte att det skulle vara några större problem att använda sig av rena trackside-signaler tillsammans med "osynlig master". Jag använder mig också av samma typ av utseende, dels är det snyggt, och man känner igen sig om man bestämmer sig för att använda mitt system istället.
Om det finns intresse och jag får använda mig av signal-objekten, så delar jag gärna av mig utav detta projekt.

Just nu håller jag på och plågar mig och programmerar property-rutor. Jag har också testat en annan variant på att initiera signalerna för att slippa framtida problem med "message overflow" och timeout buggar, än så länge verkar det funka men har ju inte testat i stor skala än och man vet ju inte vilka överraskningar som Trainz har i beredskap när scriptan blir mer komplicerade och fler i antal!
Dokumentationen om Trainz och trainscripting är väldigt undermålig tycker jag, och inte uppdaterad så det tar därför mycket tid att lösa "problem" som borde finnas dokumenterade...

Vet inte riktigt vilken Trainz-build man ska sträcka sig till? Lägre än 3.5 ger ju varningar så kanske där någonstans!

Ni är välkomna att säga vad ni tycker och komma med förslag, önskemål och frågor. Jag kommer att skriva här om utvecklingen av signalsystemet. Jag har inte satt upp någon tidsplan men tror inte att del 1 och halva del 2 ska ta så fasligt lång tid, om bara Trainz vill sköta sig...

mvh
Håkan

[Nils Blid]

Mycket intressant, Blomsson – och jag kommer att följa ditt arbete med spänning, och kanske ha en och annan synpunkt också.

Tidsperioden förefaller väl tilltagen liksom ambitionen.

Linjeblockering fungerar uselt i Trainz vilket säkert många instämmer i. Även jag har drabbats vilet resulterat i en krasch mellan två tåg som båda körde 90. Det var i Nynäsbanan som jag hade lagt in blocksignaler enligt reglerna.Jag satt i cabhytten i station X och fick grönt ljus av utfartssignalen. Samtidigt startade ett AI-tåg från station Y. Det fick också grönt utfartsljus. Jag blev helt överraskade när ett mötande tåg i full fart dök upp bakom den kurva mitt på linjen.

Vad hände? Det här är inte min avdelning men den troliga förklaringen är att båda tågen fick grönt ljus därför att den kommande signalen visade grönt. För min del var ju lösningen enkelt; jag tog bort alla blocksignaler. Resultatet blev då att när jag passerade X:s utfartssignal slog den om till rött. I sin tur uppfattade utfartssignalen i station Y att nästa signal visade rött och därför slog om till rött ljus.

Det här ju egentligen grundbulten i Trainz´ signalsystem.

Har du, Blomsson, några tankar hur fixa det här?

Nisse

[lan]

I TANE finns ju Interlocking Tower som betyder just linjeblockering (eller ställverk) - konstigt att ingen använder det???????

[blomsson]

Ursprungligen postat av Nils Blid

Mycket intressant, Blomsson – och jag kommer att följa ditt arbete med spänning, och kanske ha en och annan synpunkt också.
Nisse

Alla synpunkter är av intresse! Ju intresserade andra är ju roligare blir det att hålla på!

Ursprungligen postat av Nils Blid

Tidsperioden förefaller väl tilltagen liksom ambitionen.
Nisse

Ambitionen kanske är (för) hög, fast tidsperioden är inte så tilltagen som det verkar.
Den första automatiska-linjeblockeringen provades på sträckan Kimstad-Norsholm 1921. Mellan 1925 och 1930 så utvecklades komponenterna i linjeblocket till att likna det som finns idag bl.a. 1925 Göteborg - Olskroken, Malmö-Arlöv och 1930 Stockholm S. - Älvsjö.
1956 byggdes den första linjeblockeringen av nuvarande typ.

1960 byggdes det första ställverket av relätyp avsett för fjärrblockering, benämnt SJ 59(mod 59). Provanläggning 1955 Ånge-Bräcke. Detta ställverk nytillverkas fortfarande. 1965 kom ett nytt reläställverk, (mod 65) mera i form av moduluppbyggnad (tillverkas inte längre). 1985 kom datorställverk (mod 85) där allt styrs av två separata program i datorn (tillverkas inte längre). 1995 kom ett nytt datorställverk (mod 95) som är uppgraderat för nyare ATC-systemen.
För en utomstående är det inte mycket som skiljer men är ganska lätt att se om man vet vad man ska titta på!

[quote=Nils Blid;302491
Linjeblockering fungerar uselt i Trainz vilket säkert många instämmer i. Även jag har drabbats vilet resulterat i en krasch mellan två tåg som båda körde 90. Det var i Nynäsbanan som jag hade lagt in blocksignaler enligt reglerna.Jag satt i cabhytten i station X och fick grönt ljus av utfartssignalen. Samtidigt startade ett AI-tåg från station Y. Det fick också grönt utfartsljus. Jag blev helt överraskade när ett mötande tåg i full fart dök upp bakom den kurva mitt på linjen.

Vad hände? Det här är inte min avdelning men den troliga förklaringen är att båda tågen fick grönt ljus därför att den kommande signalen visade grönt. För min del var ju lösningen enkelt; jag tog bort alla blocksignaler. Resultatet blev då att när jag passerade X:s utfartssignal slog den om till rött. I sin tur uppfattade utfartssignalen i station Y att nästa signal visade rött och därför slog om till rött ljus.

Det här ju egentligen grundbulten i Trainz´ signalsystem.

Har du, Blomsson, några tankar hur fixa det här?[/QUOTE]

Skälet till varför två tåg krockar är att det inte finns någon funktion i svenolovs system som kontrollerar om linjen är fri, för vändas osv. Problemet är också trainz, som ställer en signal i kör om det finns ett tåg i närheten. Eftersom det då finns signaler emellan de båda stationerna så blir det kör! Jag kan inte fixa detta i svenolovs system, men det är som du säger en grundbult i ett fungerande signalsystem. Alternativet är att köra utan linjeblock, bara utfartssignaler (går dock inte att välja har jag sett så är väl kört ändå!) och då skulle det kunna funka som TAM-sträcka (Tåganmälan) men krävs ju ändå kontroll på stationerna... Så kanske lite moment 22. Fick en fundering om det skulle gå att använda mitt linjeblock tillsammans med svenolovs system, men är tveksam till det! Ska pröva när jag kommer så långt!

Till lan:
I TANE finns ju Interlocking Tower som betyder just linjeblockering (eller ställverk) - konstigt att ingen använder det???????

Interlocking Tower är funktionsmässigt signalställverk inte linjeblock och ag har prövat detta men fungerar inte tillsammans med svenolovs signalsystem. Dessutom tycker jag inte om att man måste skriva in tågvägar och beroendeförhållanden för hand.
Betänk följande: Dubbelspårs-station med fem tågspår, alla spår kan nås från alla infartssignaler, ger fem tågvägar per signal, vilket ger 10st infartstågvägar och tio utfratstågvägar i varje riktning, totalt 40st! När allt är möjligt att göra i scriptet istället...

mvh
Håkan

[Nils Blid]

En grundlig och begriplig förklaring. Fortsätt så, Håkan. (Tips: När Bengegbg och jag gjorde vår första manual fick vi skäll av betatestaren för att vi inte var tillräckliga övertydliga. Vi bättrade oss).

Det här är ett stort och svårt ämne. Är imponerad av att Blomsson/Håkan vågar ge sig i kast med det.

Kör vidare, Håkan!

Nisse

[blomsson]

Tänkte skriva lite och visa lite bilder på vad jag håller på med så att ni inte tror att jag bara snackar...
Även fast Trainz är en avart av C++ så går det skapligt. Mycket tid går dock åt till att fatta vad Trainz klagar på.

Min ide är att man ska kunna testa och se hur signalerna beter sig i surveyour, detta innebär att det kommer att bli mer information i property-rutorna än tidigare, men färre saker att ställa in. Fokus ligger på att jag som programmerare leder oss som bygger i rätt riktning så att banorna blir så verklighetstrogna som möjligt. Detta betyder att informationen i property-rutor och att guider/manualer är tillräckligt tydliga så att vem som helst ska kunna bygga en signaltekniskt korrekt bana. Denna ide passar säkert inte alla, men jag tycker att de regler och föreskrifter som finns ska följas. Jag tror inte det blir svårare att bygga, däremot är järnvägen full av speciallösningar och att täcka upp allt kan bli väldigt svårt!

Beroende på att Linjeblocket och Stationsautomater/Tkl är viktiga för ett väl fungerande signalsystem så koncentrerade jag mig på att göra klart Huvudljussignalerna och Försignalerna. Kvar att göra är Huvuddvärgsignalerna, Stopplycktor, Dvärgsignaler och lite annat smått och gått. Vissa delar är tågvägs-beroende och kommer inte att synas i surveyour.
Linjeblocket (som tog lite längre tid att göra än vad jag hoppades, genvägar är senvägar) är precis klart förutom Linjeplatsfunktionen. Dock brukar det alltid dyka upp saker man inte har räknat med när nya detaljer tillkommer.

Jag tänkte visa lite bilder på vad jag har gjort hittills, dock är det svårt att se hur linjeblocket fungerar. Signalerna är samma som svenolov använde och samma namnkonvention. Ska också säga att monteringen inte är klar än, har koncentrerat mig på signaleriet.

Linjeblocket i kör.
Utf L41 lik.jpg

"Check-boxen" LIK/LIU är till för att testa linjeblocksfunktionen i surveyour enligt ovan nämnda princip.
Linjeblocket återtaget, så att linjen går att vända.
Utf L41 liu.jpg

Motstående ände av linjeblocket, först i stopp,
Utf L42 liu.jpg

Sedan i kör efter att linjen har blivit vänd.
Utf L42 lik.jpg

Och då ska Mellnablocksignalen vara i kör...
Mblsi L4 k.jpg

Det verkar funka, mer tester ska utföras och Linjeplatsfunktionen ska in också. Är inte hundraprocent nöjd, finns lite fler ideér få se hur mycket man ska bråka me det om det fortsätter att fungera.

Samma Mellanblocksignal efter en klåfingrig projektör...
Mblsi L4 ingen fsi.jpg
Observera informationstexten...

Ett par bilder till på lite signaler och deras informationsruta.
Inf k40.jpg
Msi s 250m.jpg


Funderar på om informationstexten skulle färgkodas beroende på om informationen är positiv eller negativ och om den ger förslag till förändring?
Mera information ska in i property-rutorna.
Och det ska också testas mot STL:s-objekt.

Frågan är om jag ska göra klart signalfunktionerna eller om jag ska börja på med TKL-funktionerna! Är väldigt sugen på det sistnämnda...

Växel-hastigheterna hämtas från scriptade växelobjekt.


Jag slänger ut en fråga rakt ut i etern och undrar om det är någon som skulle ha lust att skapa några objekt till mig som jag kan scripta. Huvud-objektet är motordrivna växeldriv med specifika önskemål. Sedan har jag också ett par hemliga objekt som kan bli väldigt bra! Men hjälp behövs, pm eller här om intresse finns.

Det va säkert något mer jag skulle skriva... Men nu är det fotboll och mat!
Alla frågor, förslag osv är av intresse. Ös på bara!

mvh
Håkan

[jgloket]

ser det ut som. Jag ser fram emot att det kommer provobjekt eller färdiga signaler att testa på sin bana.

[bönan]

Ser riktigt spännande ut! Kör iofs inte Trainz själv, men om någon bygger en rutt med ett så väl fungerande signalsystem är det nästan så att man är tvungen att köpa Trainz bara för att testa...!

Kan du ha någon nytta av en TKL i utvecklingen av signalsystemet?

[blomsson]

Tack för heja-ropen och tack för erbjudandet Bönan, men farsan jobbar som Fjtkl på Cst så har ett bra bollplank hos honom. Dock är hans standardsvar när man frågar vad som sker eller hur de gö,r "det är olika"! Inte så upplysande som man kunde önska...

Kan ju också nämna när jag ändå skriver, att signalsystemet kommer att kräva någon form av Tkl-funktion för att fungera. Tanken är att Tkl ska vara så flexibelt att det inte ska spela någon roll om du som bygger och skapar sessioner väljer att köra tågen med hjälp av tidtabell/schema/körplan eller via "trackmarks". Systemet ska känna av var "trackmarks" ligger och hitta en korrekt rörelseväg till/förbi det objektet. Tidtabeller och liknande funktioner får nog testas ut var för sig eller skriva egna. Har inte forskat i hur de fungerar ännu!
Låter det komplicerat? Tror det är det också, men det är det som är lite kul och får jag det att fungera så tror jag att det kan bli väldigt bra! Dock är ju alltid Trainz en stor brasklapp i sammanhanget.
Men en funktion i taget, så är hjärnan glad!

mvh
Håkan

[bönan]

Spännande! Ja det stämmer nog som han säger, "det är olika", mellan olika fjärrar, lokalbevakade stationer och inte minst från TKL till TKL...

[blomsson]

Dags för ett litet informationsinlägg!
Det har kommit ett par funderingar kring "mina" scriptade växlar, så jag tänkte förklara lite vad det innebär.
I svenolovs system använde han metoden att välja en signalbild till en specifik signal och att man också valde en hastighet på den tågvägen. Eftersom jag ville ha ett system som dels följer de svenska föreskrifterna och att vi som bygger inte ska behöva ställa in en massa olika parametrar som kan skötas via scriptet och dessutom ha en (viss) kontroll på att vi bygger på ett korrekt vis. Som programmerare av detta system så blir det då mitt ansvar att se till att byggarna får en korrekt information i form av manualer/guider, men jag har även infört hjälp i form av information i property-rutorna som kan ses lite i tidigare bilder, kommer att visa fler varianter lite senare.
Beslutet att göra på mitt vis skapade dock ett problem, hur göra med hastigheten i växlarna? Tidigt hade jag två ideér, antingen en lista med alla växlar som man skrev in data i, men fastnade ganska direkt för tanken att skapa ett script till växlarna där man väljer en hastighet i varje växel-läge. Sagt och gjort, detta var det första jag testade att det fungerade och sedan var det "bara" att ge sig på resten...

Så här ser property-rutan ut för de scriptade växlarna:
Växelhastighet.jpg

Man väljer i en lista vilken hastighet som skall vara i varje läge. Linjehastighet = 270km/h och innebär att signalbilden blir en körsignal (kör80 ev med försignal), även hastigheterna fr.o.m 80km/h ger samma signalbild om inte avståndet till nästa signal säger något annat. Växelhastigheter lägre än 80km/h ger en signalbild med kör40 eller lägre beroende på avstånd och signaltyp på nästa signal. Detta är den visuella hastigheten eftersom signalerna kan ju bara visa två hastigheter, 40 och 80. ATC kommer att visa den korrekta hastigheten, men det är en senare fråga!

Jag har även en vilja att lägga in följande val men jag behöver hjälp med att skapa dessa objekt:
Växelval.jpg

Man kan också tänka sig att lägga in flera varianter i listan, bl.a. spårspärr med motordriv, spårspärr med elektrisk förregling och spårspärr utan elektrisk förregling.

Ett växeldriv används oftast vid rena skyddsväxlar och på bangårdar där hastigheten är låg och växlarna är korta. Två växeldriv är det dominerande antalet, (nästan) alltid tillsammans med fyra TKK (tungkontrollkontakter). Fyra växeldriv används vid växlar med rörlig korsning för hastigheter med 130km/h, dock ska antalet egentligen vara sex, men två sitter vid den rörliga korsningen så därför skrev jag fyra.
Dummy drivet kanske det finns någon användning för, kanske till sorgebarnet ekv/dkv, som ju alltid blir fyra växeldriv när det borde vara två!! Vilket dessutom ställer till det vid numrering av växlarna för korrekt rörelsevägs-läggning och vid kopplade växlar. Tänker inte skriva mer om det problemet nu, om det finns intresse så kan jag utveckla det mera i en liten utsvävning.

Apropå kopplade växlar, så är det en fundering om det ska läggas in i växel-scriptet eller skötas i signal-scriptet, är nog inne på det senare, samma som svenolov har gjort, dock med det kravet att kopplade växlar alltid ska ha samma läge sinsemellan, så att man inte råkar ut för att a-änden ligger till vänster medan b-änden ligger till höger, blir sällan bra...

Detta script går att använda till vilket växelobjekt som helst (tror jag, brasklapp). Fördelen om jag får hjälp med att göra/infoga olika växeltyper i ett objekt, är att kontrollen på hur växlarna fungerar, hastigheter och kanske andra funktioner finns i scriptet. Växelobjektet skulle ju fungera även i andra sammanhang även utanför mitt signal-projekt.

Projektet löper vidare i värmen och emellan allt för mycket sport på tv och lite i verkligheten.
Stationsautomaterna/TKL är fas ett i stort klart, håller nu på och skriver flödesscheman och tankar om hur det ska fungera mera i detalj (alldeles för många ideér). Håller också på att snyggar upp och skapar lite nya funktioner i signalsystemet. Om några dagar (förhoppningsvis) kommer jag att redovisa en del av dessa och också berätta mer om hur Stationsautomaterna/TKL är tänkt att fungera.

mvh
Håkan

[blomsson]

Tänkte att jag skickar iväg lite bilder på några av de saker jag har infört i signalsystemet.

Den första bilden visar en utfartsblocksignal i kör med ett försignalbesked (den blinkar, jag lovar).
Ublsi - felsityp.jpg
Det första man kan se är att det är en stationssträcka utan mellanblocksignaler.
Vilket inte är något nytt, men alla kanske inte vet att det räcker med ufartsblocksignaler och motstående infartssignaler i ett linjeblock.
Jag har infört att man ser namnet på motstående blockanslutning, kan vara bra att veta om det inte funkar som man har tänkt sig eller bara för att det är kul att veta...
I informationsrutan kan ni se något som jag vurmar lite för, att ge information och hjälp till de som bygger. I det här fallet har nästa signal två eller tre fasta gröna sken och då borde den här signalen visa kör med två gröna blink. Oftast när en signaltyp inte stämmer överens med en tänkt signalbild så blir signalen stoppställd och sedan finns det en förklaring varför den visar den signalbilden. Det är ju inte säkert att byggaren har gjort något fel, kanske vill ha det så, därför ska jag försöka att beskriva orsaken till signalens status och ge råd där det behövs och finns möjlighet. I detta fall så valde jag att ge signalen ett restriktivare signalbesked, vilket även sker i fristående försignaler. Nackdelen kan vara att det kanske är svårt att upptäcka signaler som visar ett "mindre rätt" körbesked än om det visade stopp eller var släckt vid ett potentiellt felbygge. Vad tycker ni?

Nästa bild visar en infartssignal med en medgivandedvärgsignal och signalen visar tre fasta gröna.
Inf 3 gröna.jpg
Nyheten på den här bilden är medgivandedvärgsignalen. I svenolovs system så skapade man en master någon meter framför huvudsignalen som man skapade en slav till som vanligt. Nu vet inte jag hur han löste det programmeringstekniska men antagligen så bestämde avståndet emellan mastrarna om de hörde ihop.
Jag har valt att göra på ett annat vis, en master två slavar. Namnges på följande vis: master C 24, scenery-hsi (C 24), scenery-dvärg (C D24). Sedan när objektet är funnet så följer den med Hsi-beskedet eller fungerar som en växlingsdvärgsignal. Medgivandetavlan har jag inte bestämt än om den ska ha samma bokstav innan eller en annan, men principen blir troligtvis den samma. Allt sker automatiskt efter att objektet är skapat.

Nästa bild visar samma infartssignal men med två fasta gröna.
Inf 2 gröna.jpg
Nyheten här är information i avståndsrutan till nästa hsi.
Eftersom en huvudLJUSsignal i kör "länkar" till nästa huvudLJUSsignal om huvuddvärgar eller stopplycktor emellan inte visar stopp så tyckte jag att det vore lämpligt att ha med avstånd och namn till både det första objektet och till den signalen som huvudLJUSsignalen faktiskt pekar på. Allt för tydlighetens skull.

Sista bilden visar property-rutan för en dvärgsignal.
Dsi - property.jpg
Tpl-signatur och avstånd till signalobjekt eller vissa andra objekt som en växlingsväg kan sluta vid och även inforutan. I detta fall talar den om att en medväxel (troligtvis) ligger i avvisande läge.

Den lilla puppen längst ner (radiobutton) är en liten grej jag har lagt in för felsökning, inget att bry sig om!

I signalsystemet är det stopplycktor, linjeplatsfunktion och kopplade signaler kvar och en massa AI-beteenden, men det blir mera aktuellt i samband med Stationsautomater/TKL.

Jag ska rita en spårskiss så att det blir lite enklare (hoppas jag) att förklara/förstå vad jag pratar om i samband med Stationsautomater/TKL. Återkommer inom kort på denna kanal...

Alla frågor, kommentarer, förslag osv är välkomna...

mvh
Håkan

[korvtiger]

Även om jag har noll intresse av modern signalteknik så måste jag lämna några kommentarer.

Det ser ut att börja arta sig, bra jobbat! Jag tycker hela konceptet med att hålla saker enkla utan att begränsa är mycket god. Att sakerna i systemet hjälper byggaren är nog en väldigt smart idé också. Även om man skickar med en tjock manual så är det inte alltid folk har ork att plöja igenom den, särskilt när det gäller signalteknik som kan bli rätt tungt om man även ska förstå och lära sig det man läser. Levande exempel som mina exempelbanor till det äldre signalsystemet eller delar som talar om vad som är fel och vad som behöver åtgärdas är smidiga sätt att förenkla för byggarna i dessa fall. Det gäller ju bara att man tänker på alla specialfall så att man inte begränsar något i sin iver att göra det enkelt för användaren.

Överlag känns det som att ditt angreppssätt till det hela passar sig mycket bättre för modern signalering än vad Svenolovs system gör. Hans system byggdes nog ursprungligen med modern signaleringsprincip i åtanke, men också för att vara väldigt flexibelt. Det har istället blivit mycket smidigare att använda för den äldre signaleringsprincipen än för den moderna vad det verkar. I det moderna systemet är det nog lättare att göra som du gör, att signalerna får ta över största delen av logiken själva, så att användaren slipper ställa in massor med inställningar som egentligen är givna av signalens placering eller typ.

[blomsson]

och dags att åter grotta ner sig i den underbart brokiga trainz världen!

Tack för kommentarerna korvtiger, sådant gör det alltid inspirerande att fortsätta med detta projekt. Utmaningen ligger ju lite i att göra systemet enkelt, användarvänligt, stabilt, snabbt och ändå kraftfullt och flexibelt.

Min idé är ju att jag som programmerare av signalsystemet ska sköta allt som ändå tar tid att ställa in och där informationen i systemet går att hämta från kända objekt. Dock så kan jag inte ha koll på allt, vilket i vissa fall innebär att mitt system kan bli lite hårdare i bedömningen av vissa villkor. Tillexempel så kan jag inte veta sikten till signaler och om det finns olika giltiga avstånd så har jag valt det längre, går förstås att ändra om det skulle behövas!

Jag tänkte berätta lite om mina planer på funktionen Stationsautomater/TKL och visa lite bilder. Detta är bara lite kortfattad information, det blir lite mer detaljerat senare när själva programmeringen har tagit fart och jag har testat lite.

Först en bild på några stationstyper som kan förekomma i landets järnvägsnät, växelnummer inom parantes är i reläställverk 59 med kopplade växlar medan de andra är i datorställverk.
Planritnings exempel bred 2.jpg
Dessa stationstyper kan förekomma i lite olika varianter. Den övre raden är stationer som ofta styrs med hjälp av stationsautomater. Den undre vänstra är min Centralstation på demo-banan och den är inte färdig, byggs på med mera detaljer att testa efter hand. Som synes så är det väldigt många signaler, för dom som är lite bevandrade i signalnumrering kanske kan ana att det är många dvärgsignaler, korrekt, jag kommer att gå in mer i detalj när jag förklarar hur tågvägsläggning och sådant är tänkt att fungera. Det går också att se att det är två enkelspårslinjer (innan signal 23 och 24) och att det är linjeblockering på dessa. Eventuellt så ska den ena bli TAM-sträcka (tåganmälan/System M) ifall jag vill lägga in den funktionen i TKL-funktionen, blir lite annan logik och också mera att göra för TKL och även lokförare antar jag!
Den högra stationen är med för att visa problematiken med ett triangelspår. Den är en ritning av södra änden av Katrineholm, den saknar ca ett dussintal med dvärgsignaler. Ett påpekande för dom som undrar hur si35 och si58 kan stå mot varandra utan en växel emellan. För att man ska kunna ställa två tågvägar i konflikt med varandra måste skyddssträckan vara minst 200m (100m om 10övervakad i ATC). I detta fall är avståndet kortare än 200m så två motstående tågvägar går inte igenom.

I normala fall är alla signaler "stoppställda" på en station. Linjeblocket befinner sig (om det inte är spärrat) i kör i en riktning, dock är Utfblsi i stopp, i vilken riktning linjeblocket än befinner sig i. För att förändra statusen på stationens objekt så krävs det en order från ställverket och uppfyllda villkor från objekten som ska påverkas för att ordern ska utföras. Tillexempel att vända linjeblocket till riktning ut från station, kan man antingen lägga en utfartstågväg eller ge kommandot "LIK" (linje i kör). Om linjen är fri och vändning medges så kommer linjen först att gå till stopp och sedan till kör i nya riktningen och Utfblsi visar kör och om villkoren för utfartstågvägen är uppfyllda så läses den och man får kör i Msi. Om ordern inte går att utföra så magasineras ordern och utförs när möjlighet ges.
Eftersom mitt signalsystem fungerar som signalerna gör i verkligheten så krävs det ett system som sköter om ordergivningen till objekten!

Mitt Stationsautomat/TKL system kommer att sköta sig helt automatiskt, du som bygger kommer inte att behöva göra många inställningar (kanske inte några).
Grundidén är att det ska fungera som beskrivet ovan. Ur ställverkets perspektiv så spelar det ingen roll varifrån ordern kommer, utförandet blir likadant ändå (finns säkert något undantag, gör det alltid i järnvägsbranschen).

Man börjar med att placera ut ett tkl-objekt för varje station detta objekt syns bara i surveyor.
Första bilden visar objektet innan det är namngett. Man döper det med stationsnamnet och med stationssignaturen (samma som objekten på stationen har) inom parantes. Jag har tagit med stationsnamnet därför att stationen heter ju något och man kanske kan använda det senare som destinations uppgift eller något...
Stnauto - 1 odef.jpg
När man stänger rutan och öppnar den igen kan det se ut så här...
Stnauto - 2 G-drift dubbel.jpg
eller så här!
Stnauto - 3 Enkel-auto.jpg
Vad betyder då det här?
Allting som syns med vit text är automatiskt hämtat.
Alla infartssignaler måste ha en trigger för att systemet ska veta när rörelsevägar ska läggas. I verkligheten så är det antingen en signal i kör eller en spårledning som blir belagd eller TKL som ger en order. Jag hade en fundering på att använda mig av den i TANE introducerade "Track Circuit Detector" för att simulera spårledningar men det kanske blir för komplicerat? Ni får gärna säga vad ni tycker. Den går ju att använda sig utav ändå, eftersom mitt system söker först efter en trigger, hittas inte någon sådan så söks efter en Utfblsi på föregående station, vilket gör det lätt att lägga in en sökning av ytterligare objekt, men man kan bara ha ett trigger objekt per infartssignal.
Förutsättningen för att detta ska fungera är att objekten är korrekt namngivna. Triggers namnges med ett stort "T" och mellanslag och sedan signalens fulla beteckning. Systemet skapar sedan en korrekt stationsautomat baserat på vilka objekt som hittas.
Hos dubbelspårsautomaten kan man se att de udda infarterna styrs av Utfblsi medan de jämna styrs av triggers. Enkelspårsautomaten är för udda tåg inte färdig(finns ingen linje) och den för jämna tåg styrs av Utfblsi. Enkelspårsautomaten har tre olika funktioner som syns på bilden, vet inte om man har någon nytta av alla eller om det räcker med en helautomat(A3).
Om ni vänder blicken mot planritningen igen så kan ni se två gröna pluppar mellan Y-station och Enkelspårs-station, dessa symboliserar lämpliga placeringar för triggers. I detta fall så blir avståndet ungefär 3km. Normalt så är det spårledningarna som utgör den sista blocksträckan innan stationen som triggar automaterna, detta ska ske i tid så att försignalen innan infartssignalen hinner ändra sken.

Varför ha både triggers och signal som aktiverar automaterna?
Kolla på Gren-station på ritningen, där finns risken att man kan få en tågväg från varje håll samtidigt som då blockerar varandra. Om då genomfartstågvägarna aktiveras via Utfblsi från angränsande stationer så förhindras den risken.
Om man bara hade Utfblsi som aktiverare så skulle man kunna få en "grön våg" över hela Mellansverige!

Varför ha både Stationsautomat och TKL?
En stationsautomat har den fördelen att den är förutbestämd och har givna villkor och därför lägger tågvägar i givna mönster beroende på förutsättningarna. En stationsautomat har aldrig något tågnummer/tidtabells beroende.
TKL-funktionen är tänkt att fungera utifrån uppgifter från tidtabell (eller liknande funktioner) hos varje fordon och då ställa rätt rörelseväg genom givna förutsättningar. Kan behövas en form av överlagrad TKL där man har behov av både stationsautomat och TKL-funtioner
Möjligheter att stänga av, slå på funktioner via "rules" kommer antagligen också att finnas och också att lägga rörelsevägar från driver när man nöjeskör!

Var kommer tågvägarna ifrån?
Alla rörelsevägar skapas via scriptet och inget behöver göras av byggarna, annat än korrekt namngivning av objekten. Nu kommer vi inpå problemet med triangelspår!!

Alla kommandon som ges av TKL, varesig det är en lokal- eller fjärr-tågklarerare skickas till en station, som i sin tur styr objekten som är anslutna till den (eller flera) stationen. Hur flera, jo ett datorställverk kan vara utbredd och samma förreglingsdator styr då flera stationer (driftplatser) och ibland även linjeblocket.
När TKL försöker lägga en rörelseväg så finns det i logiken krav på vilka förutsättningar som ska infinna sig för att tågvägen ska bli lagd. Eftersom varje ställverk är en unik enhet så är det ju inte så svårt att tillåta andra villkor än de normala. Kolla på triangelspåret, låt säga att du vill lägga en tågväg från si24 till
si17. Normalt så går det ju inte, jämn signal till udda signal, fy skäms den går vi inte på, men är ju inget problem att lösa i enskilda stationer.
När mitt script letar efter en tågväg från si24 via triangelspåret så kommer scriptet aldrig sluta leta, eftersom det inte hittar en jämn signal, evighetsslinga! För att lösa detta problem (förutom att ha en maxsök sträcka) så får man skapa en specialare i scriptet eller i signalen. I verkligheten så byter även tåget nummer när spårledningen mellan si17 och si19 beläggs.

Finns det några andra varianter på automater?
Inte på automater direkt, men numera är det väldigt vanlig med TLS (tågledningssystem). Det innebär att varje signal kan ha en körplan för tågen och Fjtkl slår ett kommando för att aktivera det för varje signal som ska ha funktionen.

Tågvägsläggningen kommer också att ske automatiskt men det går jag inpå mera senare.

Som vanligt så skriver jag fruktansvärt mycket, hoppas ni inte blir för trötta och att det finns något matnyttigt i allt detta ordflöde...
Har säkert glömt något ändå!

mvh
Håkan

[blomsson]

... för lite Kurs med Kurt!
Idag tänkte jag förklara lite om rörelsevägarnas olika funktioner och beteenden.
I rörelsevägarna ingår Tågväg och Växlingsväg. Skillnaden mellan dessa är kraven på skyddsavstånd, skyddssträcka och vilka objekt som kan agera börjanpunkt och slutpunkt för respektive rörelseväg och också vid vilken hastighet som fordonen får framföras på rörelsevägen.
I skyddet för en rörelseväg ingår också sidoskydd (flankskydd). Sidoskyddet kan utformas på flera olika vis, allt från spårslut(!) via signal i stopp till skyddsväxel. Det optimala skyddet är en skyddsväxel som ger det högsta skyddet och möjliggör hastigheter över 160km/h. Sidoskyddets utformning beror också på hur det anslutande spåret är konstruerat, lutning, längd, osv, som då ger en given maxhastighet på det spår som ska skyddas beroende på vilket sidoskydd som väljs. Om man vill grotta ner sig mer, så finns all info i TDOK 2013:0623.
Jag har i skrivande stund inte brytt mig om några hastighetsrestriktioner i själva signalen ännu, detta skulle isåfall ske via ett restriktivare atc-besked, men går lika bra att utforma med hjälp av hastighetstavlor (som ju också kan vara atc-beroende).
Jag har bara koncentrerat mig på avstånd, hinderfrihet och fientliga rörelsevägar, men kommer också att kolla så att spårspärr är i läge på om den används som skydd.

I dom bilderna som jag kommer att visa idag så har jag bytt ut symbolerna från generella signalpunkter till symboler som liknar de som finns på datorställverkens och "fjärrens" skärmar. Symbolernas betydelse står beskrivet, dock en liten förtydling, det går inte att se på bilden om en signal är en Huvuddvärgssignal eller en Huvudljussignal med en medgivandedvärgsignal! För Tkl är det samma sak, men finns vissa skillnader signaltekniskt. Signal 81-84 är Huvuddvärgar.

Den första bilden visar en Tågväg från HS 21 till HS 31 och en Växlingsväg från DS 55 till Signal 65 via DS 57 och HD 81.
Tågvägen 21-31 är en tågväg. Växlingsvägen 55-65 är faktiskt tre stycken växlingsvägar! Varje delväg är en egen rörelseväg, 55-57, 57-81, 81-65. Om man förlänger tågväg 21-31:s slutpunkt från HS 31 till HS (N)41 så är det också en egen rörelseväg! Detta kanske är lite komplicerat men jag tror det blir tydligare senare när jag visar lite bilder på mitt Tkl-system.
Planritnings exempel 85symboler Bild1.jpg
Innan en rörelseväg kan låsas så kontrolleras alla objekt som ingår i rörelsevägen och alla objekt som kan agera som skydd för rörelsevägen. Eftersom grundbeteendet är samma för bägge rörelsevägarna så kommer jag att koncentrera mig på tågvägarna och kommenterar bara växlingsvägarna när jag tycker det behövs (kommer ihåg!). Jag har redan talat lite om sidoskyddets utformning, och vid tågväg 21-31 så söks skyddet via växeln och när det hittas en växel som kan agera som skydd så läggs den i skyddande läge och sökningen avslutas (skyddande växel är 101, 104 och 106). Om inte skyddet uppfylls så fortsätter sökningen eller också så avslutas sökningen utan ett tillfredställande resultat, tågvägen går inte att låsa. Efter tågvägens slutpunkt så söks det efter en hinderfri skyddssträcka (olika beroende på förutsättningar) och ett skyddsavstånd till motriktad eller korsande tågväg (200m/100m vid 10 övervakning) eller växlingsväg (100m/0m vid 10 övervakning). Skyddet söks via växlarnas läge. Området som finns bortanför slutpunkten kallas för frontskyddsområde och skyddas av frontskyddsobjekt och de kan vara av samma typ som för sidoskydd. Dessa objekt måste befinna sig bortanför skyddssträckan för att kunna användas som skydd. Ett frontskyddsområde kan agera som skydd för flera rörelsevägar samtidigt.

Nästa bild hanterar det som kallas "samtidigheter". Samtidigheter innebär att det går att lägga flera till synes fientliga rörelsevägar samtidigt, hur är då detta möjligt? Egentligen är det inte något konstigt alls. Som synes på bilden så är det två tågvägar låsta, 51-33 och 52-62. För att dessa två tågvägar ska kunna existera samtidigt så krävs det att bägge tågvägarnas sidoskydd, skyddsavstånd och skyddssträcka kan tillgodoses. I vissa fall kan det bero på i vilken ordning tågvägarna läggs och hur växlarna ligger, därför att frontskyddet söks i växlarnas lägen och växlarna kan bli förhindrade att läggas om eller lokalfriges om de agerar som skyddsobjekt.
Planritnings exempel 85symboler Bild2.jpg
Skyddsavståndet mäts från signalen till Hinderfrihetspunkten(Hfp), vilket är det närmaste ett spårfordon får vara en växel eller spårkors utan att inkräkta på det fria rummet för det anslutande eller korsande spåret. Hfp blir där avståndet spårmitt-spårmitt är 4,1m (tågspår-tågspår/sidospår), 3,9m (sidospår) och 3,7m (riktningsspår på bangård), dessa mått har ändrats (ökats!) genom årens lopp.
Eftersom varje skyddsavstånd genom en medväxel beror på avståndet från tungspetsen via hfp till den sökande signalen, så vore det bra att veta hfp.
Mitt problem blev, hur ska jag kunna hitta hfp? Svaret blev, att det vet jag inte!
Hur gjorde jag då?
Jag har med hjälp av ritningar, och mätningar i den analoga verkligheten, kommit fram till schablonvärden på växellängder baserat på deras hastigheter, dessa är korrekta även fast det kanske finns lite variationer inom hastigheterna.
Förutsättningarna är följande: rakspår med 4,5m spåravstånd, avstånden är mellan tungspets och tungspets, uppmätt på samma spår. 40/50/60-växlar: 100meter, 70/80-växlar: 120meter (borde nog vara 115meter), 100-växlar har jag inte kunnat hittat något värde på, men borde gå att räkna ut… (har gissat på 145meter), 130-växlar: 180meter.
Sedan så ritade jag upp förutsättningarna i trainz och mätte avståndet från tungspetsen till 4,1m spårbredd, och det blev hfp-avståndet för varje växellängd. Man skulle kunna tänka sig ett hfp-objekt som lades ut, men då kommer säkert någon att lägga ett sådant mitt i växeln... Så, nej tack! Nöjer mig så här så länge. Nackdelen med schablonvärden är att specialfallen blir bortglömda, tex en växel på bangård som viker av tvärt kommer ju att tappa flera meter på anslutningsspåren.
Jag har också jämfört andra mått i växlarna med växlarna som ritas upp i trainz, för att få flera jämförelsepunkter, och det ser ut att vara konsekventa data.
Jag använder dessa mått konsekvent och tycker det ser bra ut, och dessutom är det taget från verkligheten...
Har prövat att lägga in dessa växellängder i Trainz, men den nya typen av spår har en gräns vid ca 140meter vid 4,5m spårbredd för att de ska bli animerade.

En del kanske reagerar och tycker att det borde sitta hinderpålar vid hfp! Nja, dels så finns det inget krav att det ska vara så, dessutom så kan man placera signaler på eller nära hfp istället, och mitt intryck är att hinderpålar finns mest på bangårdar där det förekommer mycket växling och där kanske inte signalerna är så frekventa, eller på lite äldre stationer där de inte har blivit sönderkörda än...

För att nu återgå till ritningen med den nya informationen så kan man se att DS 60 som står vid hfp har ett avstånd på 85 meter (indikerar 40-60 växel) och att avståndet mellan dvärgen och HS 62 är 200 meter. Dessa avstånd betyder att skyddsavståndet är uppfyllt för tågväg 52-62:s slutpunkt. Även sidoskyddet för tågväg 51-33 är uppfyllt och slutpunkten (HS 33) söker skydd via skyddsväxel 131.
Om man vänder blicken till HS 61 så är det andra värden. Avståndet 98 meter från DS 59 till växeln indikerar 70/80 växel. Avståndet 100 meter mellan HS 61 och DS 59 är väl ändå för kort? Egentligen så är det ju det, men om man har 10-övervakning kodat i baliserna (byggs på ett speciellt vis, inget jag visar nu) så är detta avstånd giltigt. 10-övervakning innebär att ATC-systemet slutar övervaka bromsningen först vid 10km/h istället för 40km/h som är det normala.
Observera att dessa värden gäller ifrån medväxel-änden, tex HS 33 behöver inte bry sig, signalen placeras några meter framför växeltungan, om växel 131 tas bort så behövs det samma skyddsavstånd som för HS 31.

Är det för mycket, kämpigt, ångest? Håll ut lite till, är snart klar, och tänk på mig som bestämde mig för att programmera allt detta... Det finns då folk till allt!

Den sista stationsbilden berör rörelsevägens slutgiltiga uppdrag, utlösning!
En rörelseväg kan utlösas på två olika vis, automatisk eller nödutlösas. Den andra är ett kommando som Tkl ger och som omedelbart(normalt) stoppställer signalerna och sedan (ibland på tid) frigör objekten som ingår i rörelsevägen.
Den automatiska utlösningen sker efter att ett fordon har passerat varje vägdel (oftast sträcka mellan två signaler) på ett korrekt vis. Om ett fordon kommer till en rörelsevägs slutpunkt och signalen är i stopp, så kommer den sista vägdelen (och eventuella andra delar som inte har blivit upplåsta) att låsas upp på tid.
Planritnings exempel 85symboler Bild3.jpg
En del tycker säkert att jag har gödslat med dvärgsignaler på den här demostationen! Faktum är att det inte är så, i alla fall inte i ett datorställverk, eller på större stationer, och det finns en idé bakom detta också. Det finns tom ställen där det finns dvärgar som inte går att påverka och som bara har ett syfte, och det är att möjliggöra tidigare utlösning av rörelsevägar.
När fordonet har löst ut tågvägen (det rosa sträcket) fram till DS 59 så går det att lägga en tågväg 33-(U)71 bakom det fordonet. Hade inte dvärgen funnits där så fick utlösningen vänta tills HS 61 hade passerats. Det går även att använda sig av stopplycktor för liknande funktion.
I samband med detta så kan jag också nämna att det finns en till funktion som även finns i mitt TKL-system, magasinering av rörelsevägar eller poulärt "maggning". Titta på sista bilden, TKL lägger 22-32-42, tågvägarna går in. Sedan läggs 33-(U)71, tågvägen går inte in, sträckan är ju redan låst. I detta skede så "maggas" tågvägen och kommer att läggas när sträckan blir fri. Dock så kan ju andra tågvägar läggas emellan (31-(N)41) som går in och då får den "maggade" tågvägen vänta en stund till.

mvh
Håkan