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

[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.