|
Ett försök till ett nytt modernt svenskt signalsystem!
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 |
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 |
I TANE finns ju Interlocking Tower som betyder just linjeblockering (eller ställverk) - konstigt att ingen använder det???????
|
Citat:
Citat:
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 |
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 |
Uppdatering!
8 bifogad(e) fil(er)
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. Bifogad fil 72766 "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. Bifogad fil 72767 Motstående ände av linjeblocket, först i stopp, Bifogad fil 72769 Sedan i kör efter att linjen har blivit vänd. Bifogad fil 72768 Och då ska Mellnablocksignalen vara i kör... Bifogad fil 72764 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... Bifogad fil 72763 Observera informationstexten... Ett par bilder till på lite signaler och deras informationsruta. Bifogad fil 72762 Bifogad fil 72765 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 |
Det blir bra
ser det ut som. Jag ser fram emot att det kommer provobjekt eller färdiga signaler att testa på sin bana.
|
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...! :drool:
Kan du ha någon nytta av en TKL i utvecklingen av signalsystemet? :) |
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 |
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...
|
2 bifogad(e) fil(er)
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: Bifogad fil 72884 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: Bifogad fil 72885 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 |
4 bifogad(e) fil(er)
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). Bifogad fil 72916 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. Bifogad fil 72918 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. Bifogad fil 72917 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. Bifogad fil 72919 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 |
Även om jag har noll intresse av modern signalteknik så måste jag lämna några kommentarer. :rolleyes:
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. |
Åter från ringspelens förbannelse...
4 bifogad(e) fil(er)
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. Bifogad fil 73037 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... Bifogad fil 73038 När man stänger rutan och öppnar den igen kan det se ut så här... Bifogad fil 73039 eller så här! Bifogad fil 73040 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 |
Dags igen...
3 bifogad(e) fil(er)
... 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. Bifogad fil 73308 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. Bifogad fil 73309 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. Bifogad fil 73310 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 |
Skriver del 2 direkt när jag ändå är i farten...
4 bifogad(e) fil(er)
...tänkte även redogöra lite för vad jag håller på med!
Egentligen håller jag mest på med det som jag har beskrivit i föregående inlägg. Dessutom pågår finjustering av stationsautomater och planering av TKL-styrning av stationer, har en enklare variant som funkar men vill att den ska var mycket mer komplex i sin funktion. Det är också fixande med smådetaljer här och där, och provkörning i Driver, vilket tar enormt mycket tid. Dom här bilderna är skapade för ett tag sedan och jag har kommit lite längre än vad som syns, men de kan visa på ett par intressant detaljer... Bifogad fil 73315 Bifogad fil 73316 Bilderna är väl ganska självförklarande kan jag tycka. Dessa två bilder visar på en automatstyrd station för enkelspårsdrift, en väldigt vanlig stationstyp. Det finns dock ett flertal varianter på denna stationstyp. Man kan också genom bilderna sluta sig till att det är ett reläställverk (troligtvis en 59:a) och att det finns skyddsväxlar. Kan ni lista ut hur det syns? Bifogad fil 73317 Bifogad fil 73318 Dom här två bilderna är på en betydligt större station, den är Tkl-styrd (inte färdigt än) vilket innebär inga stationsautomater. Kan ni se vilken typ av ställverk det är? Som ni kan se så finns det listor på alla tågvägar (och växlingsvägar) i den udda och den jämna kolumnen. Den visar börjanpunkten på en tågväg och dennes alla möjliga slutpunkter. Den undre bilden visar alla objekt som ingår i respektive tågväg, och i vilket läge som växlarna ska befinna sig i när tågvägen blir låst. Det finns också information om tågvägens hastighet. Nu ska jag påpeka ett par detaljer: Varje rörelseväg är mellan två giltiga objekt, kan vara (teoretiskt sett) hur lång eller kort (kanske inte är giltig om den är för kort) som helst. Innehåller alltid minst två objekt, men kan innehålla hur många som helst. Den som är uppmärksam kanske upptäcker ett par konstigheter på bild tre, titta igen! Ledtråd? Ok, signal 31-34 och signal 51 o 52! Har ni sett det? Kolla nu på den nedre bilden och signal 51! Tågväg 51-61 finns på två ställen (liksom flera andra)! Hur kan det komma sig, är det verkligen korrekt? Faktum är att det är fullständigt korrekt men är något som jag har funderat på att ta bort, vet inte om behovet finns! Fast det är kul och snyggt... Det går att utläsa vad som har skett i detaljerna av tågvägarna. Men i korthet(!) så är det så här: Mitt system söker tågvägarna automatiskt genom alla växlar i alla lägen och lägger sedan in dom i en lista. Detta innebär att alla varianter kommer att hittas. Om ni vänder blickarna mot bilderna i den föregående posten och kollar signal 51 och följer den undre tågvägen via varje objekt till slutpunkten, så ser ni hur det blir! Snyggt va, ett grönt badkar!! Visserligen uppochner men ändå. Då kan man ju undra, är detta verkligen verklighetstroget, och skulle man ha någon nytta av det? Det är i högsta grad verklighetstroget, fick faktiskt Stockholmsfjärren att göra detta åt mig en gång för många år sedan. Genom att låsa växel 101 i vänsterläge, kanske också 103 i högerläge kan man tvinga sökningen genom växlarna till signal 61 och slippa prata förbi ett tåg mot stopp om växeln skulle vara ur kontroll. Dock vet jag inte om det finns någon vits med det i trainz, behövs nog igenkänning av dessa varianter i så fall. Jag återkommer, förhoppningsvis om bara några dagar med lite mer bilder på vad jag håller på med! mvh Håkan |
Hoppas detta är av intresse...
För att chocka de som brukar läsa mina evighetsinlägg så blir det bara så här idag...
https://www.youtube.com/channel/UCWw...q5L7NOl1D3SV6Q mvh Håkan |
Citat:
Detta är stort! Speciellt som jag som gillar säkerhet system och infrastruktur. Enkelspårsdrift och trainz är inget och tänka på. Tills nu. Det här är det som fattas, för att få ett nästan 100% signalsystem. :) |
Lite output och input!?
6 bifogad(e) fil(er)
Jag tänkte först påpeka en detalj om en tidigare bild, även fast ingen har sagt något. I den första posten jag skrev den 21/10 så skrev jag om Hinderfrihetspunkten (Hfp). En del har säkert observerat att det på en bild står Hfp(s) och kanske undrar varför det gör så. Hfps betyder den "Signaltekniska Hinderfrihetspunkten" och är 4,5 meter innan Hfp. Detta avstånd är det längsta avståndet mellan nosen på fordonet och dess första hjulpar. I mina beräkningar använder jag mig (hittills) bara av Hfp!
Innan jag kommer till huvudsyftet med dagens(nattens) inlägg så tänkte jag visa några bilder på en del av de signaltekniska beteenden jag har arbetat med under den senaste tiden. Eftersom det har blivit många detaljer/funktioner att testa, så beslutade jag mig för att bygga en "verkligt fiktiv" bana innehållande "alla" olika testobjekt/beteenden. Just nu är det 10 "färdiga" stationer i olika varianter och ytterligare ett femtal är planerade. Detta kommer jag att återkomma till i en separat tråd, när grund-banan är färdig. Alla signaler som jag har tillgång till (HS,HD,SL,DS,FS) är klara! En intressant utmaning var att få till ett korrekt fungerande triangelspår. I den analoga verkligheten så är inte ett triangelspår någon speciell signaltyp eller så, funktionen ligger i ställverket och dess förreglingssystem. Bifogad fil 73604 I mitt system så är det en variabel som man får ställa in som gör att en udda tågväg kan sökas till en jämn signal och tvärtom. Detta är specialfall och ska inte missbrukas!! Denna funktion fungerar (hittills) bara på mellansignaler. I brist på bättre så har jag döpt den till "Triangelfunktion"! Är det någon som har ett bättre förslag, så hojta! Jag har också infört kopplade (förreglade, kontrollbekräftade) signaler, längs upp till höger. Bifogad fil 73605 Detta är triangelspåret på min testbana. De rödmarkerade signalerna blir valda med triangelfunktion, som synes på den övre bilden. Lite information om stationen, i det övre benet så finns det två skyddsväxlar för snabbare tågföring och också möjligt att ha hastigheter över 160km/h. Man kan också tänka sig fler skyddsväxlar för att få samtidigheter i bägge benen eller att flytta signalerna för att få korrekt skyddsavstånd. I det vänstra benet är hastigheten 70km/h och i det högra 40km/h. De nedre växeln har ingen skyddsväxel, projektören tyckte inte att kostnaden blev motiverad... Huvudfokus har dock legat på att få klart stations-automaterna... Dessa är färdiga förutom en del kosmetiska detaljer och "snobb" funktioner, och sedan dyker det säkert upp buggfixar efterhand... Följande automater finns: G-drift (enkelspår/dubbelspår/flerspår - ska kanske snobbas till), Y-spårsstation (bättre än verkligheten!), Enkelspårsautomater (A1,A2,A3) Enkelspårs-stationstyp med och utan skyddsväxlar, ESIK och ESIL. Här kommer några bilder på de olika enkelspårstyperna: Bifogad fil 73606 Bifogad fil 73607 Bifogad fil 73608 Bifogad fil 73609 Observera att stationsautomaterna bara hanterar två spår även om det finns en hel hög fler, precis som i verkligheten! De andra spåren kommer man åt via tkl-funktioner. Sedan när TAM-funktionerna finns så kan inte stationsautomaterna hantera dessa stationer heller. Citat:
Håller med och kan tillägga att två huvudskäl till att det går att göra är: ett fungerande linjeblock och signaler som fungerar som de ska göra på en station! Nästa stora steg är att få till ett bra (fj)tkl system! Och det är nu som NI kommer in i bilden. Eftersom jag inte har konstruerat några egna sessioner, utan bara kört utländska, och även fast jag har många ideér om hur jag vill köra/göra så tänkte jag helt enkelt fråga er som (förhoppningsvis) vill använda mitt system om era önskemål innan jag ger mig i kast med den riktiga tkl-programmeringen. Några frågor kan jag göra: Ska jag skriva egna kommandon som är anpassade till mitt system eller ska jag försöka använda mig av de befintliga? Vad är bäst för er? Är det några specifika kommandon som ni saknar? Va svårt det var att komma på frågor, jag hade ju jättemånga igår, jaja... Ni får komma med era önskemål och beskrivningar om hur ni brukar göra och hur ni vill göra! Ös på bara!! mvh Håkan ps. Förutom (Fj)Tkl funktionerna så är nästa stora projekt i signalsystemet ett eget tavelsystem och ATC-funktionalitet... Återkommer med det när det är mer på G! |
Uj va tiden går...
1 bifogad(e) fil(er)
Dags för lite information efter två månaders tystnad, (i vilket fall i denna tråden)!
Jag fick för ett par veckor sedan ett brev med en undran om jag hade gett upp mitt signalsystem, så jag tänkte delge mitt svar även här innan jag angriper dagens två ämnen! Mitt brevsvar, lite kompletterat: Gett upp har jag inte gjort, däremot så har det varit lite stiltje ett tag med programmeringen, mest beroende på förkylningar/influensa och helgdagar, dock så pågår ett ständigt klurande på hela/alla delar av mitt signalprojekt. Dessutom så håller jag på och bygger på min demobana som kommer att redovisas mera i detalj på forumet när jag har kommit längre i bygget. Tyvärr så tar projektet längre tid än vad jag hade hoppas på, inte så mycket beroende på att jag har underskattat komplexiteten i signaleriet utan beroende på att det har blivit ett projekt med fler delar än vad jag hade tänkt från början. Eftersom jag är ny på programmeringen i trainscript och dokumentationen oftast är undermålig så blir det många stunder med ”trial and error” rörande detaljer som borde finnas i en manual. Dessutom så kan jag inte (än så länge) göra egna objekt utan är beroende av andras alster för att kunna testa funktioner. Sedan så är jag inte så pigg på att släppa saker som inte är funktionsdugliga i stil med ”allmän beta” utan sakerna ska vara så testade som det bara går, dessutom ska det vara en manual som följer med den färdiga produkten. Detta innebär inte att det inte kan finnas fel eller förbättringar utan att projektet ska kunna gå att använda med de komponenter som ingår. För mig så hör alla (beroende på vilken era) komponenter i signalsystemet ihop och därför så ska det som behövs för ett fungerande system släppas samtidigt. Jag nämnde att signalprojektet innehåller fler delar än vad som var tänkt, dessa delar är (fler kan tillkomma):
Tanken är att signaler, växlar, tavlor, tkl och en del kommandon och rules ska finnas och även baliserna som passiva objekt fram till att ATC-systemet är ”färdigt”. Manualen kommer antagligen bara innehålla guide-delen till att börja med. Åter till dagens agenda: Jag blev lite förvånad att ingen sa något angående mina Tkl-funderingar, inte ens fråga vad jag menar! Så jag tänkte att då får jag försöka förklara lite av mina idéer och tankar på fri hand så att säga. Ni som har kikat på videosnuttarna jag länkade till tidigare har antagliget sett att jag använder mig av lite olika kommandon i Driver. Dessa kommandon är inte tänkta att användas när man skapar sessioner, utan som hjälpmedel vid nöjeskörning och felsökning. Däremot så behövs det antagligen kommandon som gör att man kan köra till en specifik signal eller liknande. Därför så är min plan att dela in kommandona i (minst) tre grupper: 1. "Session-kommandon" 2. "Nöjeskörning" 3. "Hjälpmedel/Felsökning". Om jag inte kan lägga tågvägar, hur kan jag då skapa sessioner? Bra att du frågade! Hela tanken med mitt system är att det ska fungera som i verkligheten, där TKL (inom signalreglerat område) bestämmer vad som får göras och när. Detta ska skötas inom de föreskrifter som gäller vilket ställer höga krav på TKL-systemets kontroll av fordon/förare och stationer, men också en flexibilitet att lösa situationer för att förhindra eller låsa upp låsningar vid komplexa körningar. TKL-system kommer förstås att bli en flerstegs-raket och långt ifrån färdig i första släppet. AI vs. Autopilot? Helst bägge beroende på situationen! Nackdelen med AI-kommandon är att de försöker lägga om växlar och ställa signaler, fördelen är att de kan lägga om växlar! Vi tar en liten bild till hjälp: Bifogad fil 73874 Låt säga att man vill köra ett tåg från Stn A till Stn D: Enkelt(!), schemat kanske ser ut så här: Autopilot, Wait 5min , Kanske vill ange ett specifikt spår eller trackmark som ankomstställe. Vad kommer att hända, Autopiloten talar om att följa signalernas besked, efter kanske 4min (beroende på hur det programmeras) så kommer TKL att magasinera en tågväg som går in när linjen är fri. Eftersom Stn B o C är Automater så kommer alla tågvägar att ställas och eventuella möten skötas automatiskt. Vid TV-triggern för Stn D kommer tågvägen ställas till den valda ankomstpunkten eller kanske till ett "normal" spår. Vi tar samma schema men vill efter ankomst till ett visst spår ta oss hem till lokstallet som ligger utanför signalreglerat område. Detta går att lösa på flera vis, man kan ju lägga till en ny signal (dvärgsignaltavla) som nästa punkt och sedan lägga till ett NavigateTo kommando för att ta sig till lokstallet. Men jag vill kunna använda mig av NavigateTo/Via direkt istället för Autopiloten. Eftersom TKL vet(förhoppningsvis) var objekten finns i förhållande till varandra så borde det gå att låta TKL sköta allt fram till det signalreglerade områdets slut och sedan låta Trainz ta hand om resten! Att göra så här handlar ju mera om att använda sig av de kommandon som finns och att förenkla scheman och minimera antalet kommandon som behöver användas. TKL-systemet är som synes väldigt komplext och en (alltför) stor ambitionsnivå kanske sätter käppar i hjulen, men ett med ett äpple om dagen så är snart päronträdet tomt! Det finns en till aspekt på detta som jag återkommer till när jag har gjort en bild på det! Någon har säkert sett att det står TKL/Automat på Stn B. Det rekommenderas inte att man har Automater på stationer med flera inkommande linjer, men i vissa fall kan det vara motiverat. Det kanske bara går ett fåtal tåg per dag mellan Stn B o E och till ett eget spår som inte stör automatdriften. Nu till den sista punkten Eftersom jag har nämt att jag håller på med ett eget tavelsystem i diskussionerna om diverse tavlor, så tänkte jag berätta lite tidigare än vad planen va! Jag har precis börjat så det finns inga snygga bilder än. Först ska jag säga att jag tycker om STL:s tavelsystem, det är snyggt och flexibelt och nu när LAn arbetar med uppdateringen så kommer det att bli ännu bättre! Dock så finns det tre skäl till min idé. Problemet med STL:s flexibilitet är att det blir väldigt många objekt att lägga ut och ofta kommer tavlor på samma ställe och gör det svårt att kunna justera rätt tavla. En del tavlor, framförallt Orienteringstavlan sitter aldrig ensam, alltså så blir det en extra tavla att alltid lägga ut. Och det kanske viktigaste skälet, mitt signalsystem, eller snarare ATC-funktionerna. Jag kommer att gå in mera på Tavlor/Signaler/ATC senare men kan säga så mycket att ATC:n (baliserna) kommer att bli hårt länkade med signalsystem därför behöver jag ha kontroll på alla objekt som har med "signaleriet" att göra. Tavelsystemet kommer att innehålla minst tre grupper: Hastighetstavla, Orienteringstavla, Balistavlor (tavlor som ALLTID har ett ATC-beroende) och eventuellt Signaltavlor (tavlor som finns istället för och namnges som signaler), denna grupp tavlor skulle kunna lösas med enbart namngivning av objekten, men känns bra med en dubbel kontroll på dessa! I propertyrutan så väljer man bland giltiga kombinationer hur tavelgruppen ska se ut. Observera följande fyra saker: Det är bara tavel-kombinationer och typer som har betydelse för mitt signalsystem som är ett krav på dessa banor. Detta system bör(kommer att) fungera med STL:s övriga system, och kommer att släppas fristående. Man kan fortfarande lägga till tavlor som vanligt, förstås. Jag använder mig av STL:s tavlor och "texture-groups" som dependecis självklart med tillstånd! Detta innebär bl.a att om man har massa OT-V på sin bana behöver de inte bytas ut, däremot så måste HT bytas ut och även OT-Ha och vissa tilläggstavlor. Tror det va allt, överdosering som vanligt... Frågor, funderingar och önskemål tas som vanligt emot med intresse! mvh Håkan |
I have a dream that one day an ATC panel should be exist inside the cabin.
Nåja.. Vore kul att det finns en 3d-panel som man kan lägga till via en punkt som gör att det går att stoppa in ATC i loken på riktigt :D Alla funktioner kanske inte behövs vara fungerande, men det vore roligt med exempelvis förvarningsfunktionen för förvarning av hastigheter samt att hastighetsöverträdelse fungerar :D Tror detta skulle vara ypperligt att implementera tillsammans med ett nytt signalsystem istället för att anpassa den efter ett befintligt |
Citat:
Istället är tanken att lägga en ATC-panel ovanför "schemaremsan" där jag tror den syns bäst och är minst i vägen, kommer säkert gå att flytta den om man vill. Tanken är att alla funktioner ska fungera, dock inte direkt förstås eftersom ATC:n i sin utformning är ganska lätt att förklara men svår att projektera...! Jag kommer att berätta mer snart om hela ATC-systemet! Det har varit planen hela tiden att ha ett helhetskoncept med alla de delar som jag nämner i första tråden, sedan så kommer man på mer och mer och mer... mvh Håkan |
Tavlor, kan det va något?
8 bifogad(e) fil(er)
Nu har jag varit tyst (oroväckande) länge i denna tråden, det kanske föranleder någon att tro att mitt Signalsystem ligger i träda? Inte ens nära!!
Ibland när man håller på och inför nya saker så kan man spela spratt med sig själv och få ägna sig åt lite opåkallad felsökning. Efter det så blev jag lite trött på programmeringen och har spenderat ett par veckor åt att bygga på "Demobanan" och har ju också varit involverad i STL:s tavelsystem. Men innan det, så har jag hållit på med två huvudsaker, baliser och mitt eget tavelsystem, men även en del annat smått och gått... Eftersom diskussionen om STL:s tavelpaket är i full gång så tänkte jag berätta om mitt system som i stort är klart. Jag nämnde i min föregående tråd lite om mitt Tavelsystem, så det kanske blir lite upprepningar, men nu har jag bilder!! Skälen till varför mitt system skapas, nämns i en post strax ovanför denna. Alla objekt som jag gör eller som jag scriptar kommer att vara namngivna med ett "HB" först, tydligt och lätt att hitta. Tavlorna kommer att heta "HB T typavtavla". Mitt tavelsystem innehåller, just nu, tre taveltyper (kanske blir fler, håller på och funderar på vad som är bäst):
Vi börjar väl med huvudbilden och ett gäng förklaringar: Bifogad fil 74531 I STL:s tavelpaket så skulle tavel-kombinationen bestå av fyra separata tavlor, i mitt system är det en tavla! I propertyrutan syns de olika inställningarna för tavlan. Inom den blåa rektangeln är olika justeringsalternativ, de kanske är självförklarande men nämner ett par. Den övre i mitten, "Avstånd från spårmitt" har bara två alternativ (syns längre ner), eventuellt ska det även gå att placera tavlan mellan dessa värden. "Höjd över RöK" är tavlans höjd och dessa mått är de som är grundinställningen i BVF/TDOK och ska normalt inte behöva ändras, vilket är en skillnad mot STL:s paket. "Längs spåret" är till för att finjustera positioneringen, tex vid placering mot Ktl-stolpe. "Tavelavstånd" är glipan som är mellan varje tavla (ska tas bort på de som inte har tilläggsatavlor), grundinställning 5cm (syns nedan) justerbart från 1cm till 20cm. Alla positioneringar räknas ut automatiskt, och det är sällan som några justeringar kommer att behöva göras. I tråden "Tavlor, tavlor och tavlor" finns några fler bilder, bl.a på tavlor placerade på snedsträva, automatiskt uträknat. Behöver dock ordna fästen för KTL montage. Den gula rektangeln är information om tavlans ATC-beroende och är (just nu) endast informativt! Den röda rektangeln talar om vilken typ av Orienteringstavla det är och det går att ändra vilken typ av tavla som ska användas. Verkligt avstånd används till den länkade Balisgruppen, om sådan finns. Den gröna rektangeln visar de val som är gjorda på varje position för denna tavla. Hos Orienteringstavlan bestämmer den första positionen tavlans funktion, vad den orienterar för, och de andra positionerna är tilläggstavlor för den funktionen. Hastigheten kan i vissa fall bestämma vilka tavlor som kan väljas efteråt. Här syns de val som går att göra för position 1. Bifogad fil 74532 Det är bara tavelkombinationer som är giltiga som finns att välja, vilket också är ett stort skäl till att jag gjorde mitt system. Även inom de giltiga kombinationerna är antalet kombinationer minimerade, dels för enkelhetens skull och också för att stävja den "konstnärliga friheten"! Exempel: På bilden överst går det inte att skifta position mellan "Avståndstavlan" och "ATC Överskridande", däremot så kan man ha "ATC Överskridande" på position 2 men inte någon mer tavla än piltavla vid avvikande placering. Alla tavelstorlekar och taveltyper bestäms automatiskt beroende på valen som görs. Även Förvarningstavlan är en Orienteringstavla! Bifogad fil 74533 Den har dock inga val för tilläggstavlor och finns bara på banor med ATC under givna premisser. Denna kändis har en egen Taveltyp hos mig!! Bifogad fil 74534 Inga val för tilläggstavlor och finns bara på banor med ATC och all information sker via länkade baliser. Ett par bilder på Hastighetstavlan. Bifogad fil 74536 Valen som finns att göra är beroende på den inställda hastigheten och då också vilken typ av tavla som visas.. Bifogad fil 74535 Här syns också tavla i brygga! Kan nämna att även signalernas placering i höjdled är justerad så att de stämmer överens med föreskrifterna. Detta tavelsystem ska fungera oberoende av mitt Signalsystem och ska kunna samarbeta med STL:s tavelsystem, eftersom det bara är Hastighetstavlan (Speedbord) som Trainz bryr sig om, men det kommer att krävas (om jag kan göra som jag vill) i mitt Signalsystem, eftersom allting kommer att hänga ihop. Tavelsystemet är i stort färdigt, ska kolla en del saker och några fler val ska till. Tror det va allt om tavelsystemet... Vad har jag mer hållit på med? Jag har programmerat balis-delen av ATC-systemet, men det tänker jag berätta mera om i ett separat inlägg! Sedan har jag en lista som jag betar av, tre punkter bockas av, två tillkommer... Så det går sakta framåt kan man säga. Jag håller på med ett verktyg för att underlätta placeringen av Trackside objekt. Jag har utvecklat mitt växelscript till de elektriska (centralstyrda) växlarna. Jag använder LAn:s växlar från STL:s hemsida. Detta är ett kollage på lite exempel: Bifogad fil 74537 I den övre gruppen skrivs hastigheten in i varje läge, grundinställningen syns i den övre bilden. Detta är dock icke giltigt, som synes i texten. Antalet växeldriv och avståndet mellan dessa räknas ut automatiskt, tyvärr så finns det inget sätt att veta hur motordrivet(växeln) placeras ut och driven kan då hamna i fel riktning. Genom att klicka i rutan så ändras positionen hos driven. Det finns också ett val att ändra slipersavståndet, det bero på att det verkar inte vara något spår (som jag har kollat) som har ett korrekt slipersavstånd och då går det att ändra för estetikens skull. Antalet motordriv bestäms automatiskt, och går bara att ändra vid lägre hastigheter. Men jag vill ha ett växeldriv även fast det är en 70-växel? Inte möjligt, fast ändå är det det! Kolla på den mellersta bilden i kollaget, låt säga att vänsterläget slutar i en stoppbock (skyddsväxel), då kan man välja 40km/h och ändra till ett driv. Växelns andra ände (A Vx101b i detta fall) ser då ut som på bilden för korrekt säkerhet, helt enligt regelboken, förutom att det saknas TKK!! Bifogad fil 74538 Observera att hastighetsvalen som görs endast påverkar och krävs för mitt system, i övrigt är det ett sätt att slippa lägga ut flera objekt i onödan. Dessa objekt som jag håller på med nu, kommer att släppas någon gång efter att SP2 har kommit, och objekt, koder och dylikt är kollat. Om det kommer att bli SP2 krav på hela Signalsystemet det vet jag inte i skrivande stund, men om jag gör egna objekt senare så blir det garanterat så och om SP2 är den snabbaste och stabilaste versionen så finns det egentligen ingen anledning att lägga sig lägre...! Just nu håller jag på att testa STL:s vägskydd ihop med mitt system vilket innebär att "oegentligheter" har upptäckts, återkommer med det efter mera byggande och testande. Hela Signalsystemet kommer att ackompanjeras av en Manual som kommer att beskriva allt på en Guide nivå och i de flesta fall även en detaljerad nivå, som en referens del. Jag förutsätter att alla som tar del av mitt Signalsystem kommer att läsa alla drygt 500 sidor...:grin: Tror det var allt för nu... mvh Håkan |
Mycket imponerande!
Tycker bra om dina idéer om att hjälpa byggarna på traven genom att endast tillåta inställningar som är korrekta och att skiva ut information i propertyrutan. En av de största anledningarna till folk att vilja gå över till detta system från STLs moderna system är ju felen som uppstår när man satt ut för många signaler på en bana och meddelandesystemet brakar ihop. Har du stresstestat detta system för att se om det klarar större banor än STLs? Borde inte vara något problem tycker jag, om du gjort det på ett effektivt sätt från början. :) |
Oerhört imponerande! :) Tavlorna är väl på ett liknande sett som STW's gamla tavlor var, att det var ett objekt och i det valde man tilläggstavlor mm. Väldigt praktiskt och väldigt få objekt att hålla på med! Är väldigt intressant att följa dina framsteg Håkan.
|
Tackar, tackar korvtiger och Jockes!
Alltid trevligt och uppmuntrande med positiva kommentarer, vilket gör det enklare att fortsätta med projektet. Konstruktiv kritik, frågor och önskemål är också välkommet förstås. Stw:s tavelsystem känner jag inte till, men verkar nog som de liknar varandra. Jag har ju några filosofier i mitt projekt, vilket säkert framgår av tidigare inlägg, men en filosofi är att ju färre objekt som användarna behöver lägga ut ju färre objekt blir det att ställa in och färre objekt för Trainz att hantera. Detta borde ge ett effektivare byggande och också kanske ett snabbare Trainz. En annan filosofi, som korvtiger är inne på, är att hela systemet ska vara lätt att använda, det innebär inte att det inte kan vara komplicerat att skapa verklighetstrogna banor, utan att jag tillhandahåller hjälp direkt i propertyrutan på vad som kan/får göras och försöker påpeka vad som orsakar eventuella problem direkt vid byggandet, en del syns i de tidigare inläggen. I många fall är det dock upp till byggarna att bygga på ett korrekt vis eftersom det inte går (eller är väldigt svårt) att kontrollera förhållanden mellan objekten. Grundtanken är att även med väldigt lite kunskap om järnväg eller vissa specifika tekniska detaljer så ska man kunna bygga en fungerande svensk järnväg, bara man följer de regler, föreskrifter och konventioner som kommer att redovisas i den medföljande Manualen. Manualen är tänkt att innehålla minst tre viktiga delar (säkert fler).
Stresstestat har jag egentligen inte gjort, men jag kodar med en lite annan filosofi än svenolov. Jag skickar väldigt få meddelanden och använder mera direkta anrop mellan objekt. Om min kod är effektiv eller om banan bara är för liten än, det är jättesvårt att veta. Dock så är jag inte så snäll mot datorn, just nu har jag 15 program inklusive Tane och det rullar på bra tycker jag, visserligen är inte Tane inställt på högsta men nästan! Jag har dock jämfört den banan som jag skickade till dig korvtiger, när vi håll på med "message buggen" mot demobanan. Originalbanan har: signaler 447st och växlar 141 Demobanan har: signaler 245st och växlar 70 Jag är ju inte riktigt där än, men kommer komma dit med lätthet och ska bli väldigt intressant om det blir några problem då!! Arbetet fortsätter... mvh Håkan |
Lite sill på laxen eller nått sånt...
5 bifogad(e) fil(er)
Eftersom SP2 har varit i flaggorna så har det inte blivit något direkt nytt programmerat sedan sist, utan lite små fixar, testande och byggande När nu SP2 har landat så blir det en hel del testande av det som hittills är gjort för att se om det är något som behöver skrivas om, och också för egen del att se om jag har möjligheten att skapa och lägga ut 3D-objekt (om de blir bra/snygga är ju en annan sill).
Inatt så tänkte jag bara visa lite av de förändringar som jag har gjort så inte blir så tungt som omväxling! Först en bild på samtliga val som går att göra vid hastighetstavlan: Bifogad fil 74781 Bilden i en tidigare post visade valen som fanns vid hastighet 110km/h här kan de ses vid 40km/h och då finns samtliga val som kan göras. Den valda hastigheten har den övergripande makten över vilka val som går att göra. Ett val som inte syns på bilden är piltavlan, den går endast att välja vid högerplacering med pilen åt vänster. Dessa två bilder visar förändringarna som är gjorda gällande tavlans justering i sidled från spårmitt: Bifogad fil 74782 Detta är justeringen om tavlan är placerad i brygga. Tavlan placeras med centrum 2.25m från spårmitt (hälften av 4.5m som är standardavstånd mellan parallella spår) och går att justera i 1cm steg från 2.5m till 2.0m, dvs inom det fria rummet för Normalprofil K. Skulle knappast tro att den behöver flyttas på... Bifogad fil 74783 Detta är justeringen vid övriga placeringsalternativ. Tavlan placeras ursprungligen vid centrum 2.75m från spårmitt och kan flyttas till 3.35m med H/V knapparna till vänster. Det går också att justera tavlan med 1cm eller 10cm steg inom dessa avstånd. Jag nämnde också tidigare att tavlor och signaler (och en del övriga objekt) placeras direkt på ett korrekt avstånd både i sidled och höjdled. Detta är en bild som visar skillnaden mellan de signaler som följer med STL:s paket och samma signaler med mitt script inblandat! Bifogad fil 74780 Till vänster STL:s paket, till höger mitt script med Centrum från RöK på 3.0m. Eftersom mitt system behandlar signaler på samma vis som verkligheten gör så innebär det att Trainz interna sätt att påverka/ställa signaler till kör bara används när de får tillåtelse att göra så. Detta betyder att signaler på stationer alltid är normalt i stopp. För att de ska gå till kör krävs det en order (detta gäller även en del andra funktioner i systemet), det räcker inte bara med att ett tåg rör sig mot signalen. För att detta ska fungera så krävs det TKL-funktionalitet och detta har blivit den viktigaste kringliggande funktionen för signalsystemets existens. Eftersom allt hänger ihop så fungerar inte det ena utan det andra! I Trainz så finns det något som kallas för Interlocking Tower, vilket i mitt tycke är ett omständligt, tidskrävande och omodernt sätt att lägga tågvägar. Mitt system bygger på verkligheten och jag som programmerare gör jobbet åt er! Jag tänkte redovisa en praktiskt skillnad i hur det kan se ut från EN signal till SAMTLIGA signaler som den signalen kan peka mot. Så här ser den bilden ut: Bifogad fil 74784 Vad kan man då utläsa av denna bild. Jo, många tågvägar blir det! Dessutom om det vore en medgivande dvärgsignal också så skulle det bli kanske dubbelt så många rörelsevägar. Man kan se att signal C 51 pekar mot fem stycken signaler (31,33,61,81,83). Men någon kanske undrar hur kan det bli så många tågvägar, räcker det inte med fem stycken! Det finns två skäl till varför det är så många, dels så kan ni se att det finns en asterisk vid en del nummer. Detta betyder att den tågvägen har en lägre hastighet än den utan asterisk med samma slutpunkt. 51-61 och 51-61* är två olika tågvägar med samma slutpunkt, detta beror på att systemet har hittat flera vägar genom växlar med olika hastigheter. Det andra skälet är att man kan lägga en tågväg med ALLA deras tågvägar och ALA deras tågvägar osv, direkt från signalen istället för att behöva vänta till att nästa signal syns från lokförarplats. Detta är något som jag har skapat strax innan SP2. Tänk om man skulle skapa alla dessa tågvägar och ställa upp villkor för fientliga tågvägar, signaler, växlar mm som i Interlocking tower, nu gör jag jobbet åt er istället! Även tågvägsutlösning, hinderfrihetskontroller (även fast det finns dumheter i trainz med det), skyddsträckor, samtidigheter mm sköts helt automatiskt av systemet, allt ni behöver göra är att bygga korrekt... Detta som syns här är BARA tänkt att användas när man nöjeskör eller testar sin anläggning men villkoren för om en rörelseväg går in eller ej är samma, varesig man kör för nöjes skull eller i arbetet! När man skapar sessioner så kommer Stationsautomater och TKL-funktionerna att hantera hela rörelsevägs-läggningen baserat på scheman eller andra villkor. Det blev visst långt inatt också, och ändå fick jag inte med allt... mvh Håkan |
Nästan tre månader sedan sist...
8 bifogad(e) fil(er)
så dags att plåga er lite! Nä, så farligt ska det inte bli...
Först så tänkte jag skriva något i min byggtråd men skriver allt här istället. Som jag skrev tidigare så har mycket av tiden gått åt till att lära mig om 3D-bygge och mappning, och det blev som jag befarade, ett helt eget tavelsystem med egna tavlor och fästen mm. Eftersom jag har gjort egna objekt så blev även texturgrupperna omgjorda, där texturerna är baserade på STL:s orginaltexturer (som jag ju redan har pillat på), så framgår det i configen. I och med att alla objekt är gjorda av överstruken så finns det numera inga beroenden till STL:s grejor i Tavelsystemet. Jag tänkte visa lite bilder och beskriva vad som har blivit förändrat sedan sist. Propertyrutans grundutseende, som visas i tidigare inlägg, är inte förändrad, däremot så har det tillkommit lite specialare som redovisas lite senare. I Tavelsystemet så har det tillkommit några tavelgrupper sedan sist, nu finns följande:
Först ett par collage på lite tavelobjekt. Bifogad fil 75223 Bifogad fil 75218 Alla objekt har dimensioner efter verkligheten. Fästena kommer bara att synas under 100m (exakta avståndet framgår inte) sedan syns bara tavlan och eventuella stolpar. Som det är gjort nu så syns allt utom fästena till "drawdistance" klipper, det går att lösa det ganska enkelt så att objekten försvinner tidigare men det är mycket jobb för ganska liten effekt! OBS: Om någon vill veta mer om vad jag bluddrar om så skriv en fråga i min byggtråd istället så att denna hålls mera ren för signalsystemet! När jag gjorde om tavelsystemet så blev det också naturligt att göra en egen "flytt-markör". Eftersom jag länge har tänkt att ha en "ID" symbol på mina objekt, så att de inte misstas för någon annans när man bygger, så fick ID-symbolen hamna som "markör". Jag tänker nog lägga in ID-symbolen på de flesta objekt, så länge som den inte stör arbetet med objekten, även om det är unika objekt, bara för att vara konsekvent. Jag har också ändrat monteringsalternativen, så här ser de ut nu: Bifogad fil 75219 Jag har tagit bort "Fyrkantsstolpe" och lagt till "På annan rörstolpe" och delat upp brygg-montagen i Mora- och Fackverksbrygga. Det kommer troligen att dyka upp lite special-val för vissa tavlor också. Alla monteringsalternativs positionering utgår från det som står i föreskrifterna, förutom "Ktl-stolpe" och "Ktl-sträva" som är gjorda för att passa på stolparna. Detta innebär att tavlornas placering hamnar innanför det fria rummet vid 2.75m alternativet. Eventuellt ska jag lösa det genom att man kan justera tavlorna på hållarna också (precis som i verkligheten), detta kommer i så fall att ske automatiskt, men man kommer antagligen kunna justera manuellt också. Tavlor som man kan placera lågt (U, Dvsi mm) och som också kan placeras högt på rörstolpe, justerar sin sidleds-position automatiskt för att klara fria-rummet (och kanske byter tavla också!) när man justerar höjden på tavlan. Hög Rörstolpe-montering har 3.1m från spårmitt och låg dito har 2.25. Tavlorna har en inbyggd "offset" vid monteringsalternativen "Ktl-stolpe" och "Ktl-sträva" så att de passar mot kontaktledningsstolparna vid standardhöjden. Även "På Annan Rörstolpe" har en inbyggd offset så att den automatiskt placeras vid Rörstolpen när man placerar de bägge "ID-markörena" bredvid varandra, som synes på bilden: Bifogad fil 75216 Denna typ av montering ger också en specialare i propertyrutan, möjligheten att välja typ av fäste för varje enskild tavla. Bifogad fil 75217 De nya valen är normalt infällda och görs synliga med pilknappen. Det finns nu två val med placering av tavlor i brygga, detta är gjort för att kunna göra stolparnas utseende korrekt. Här är två bilder på tavlor i brygga: Bifogad fil 75221 Bifogad fil 75220 Måtten utgår från Huvudtavlans centrum och mäts till RöK och är 6.5m, och går inte att placera lägre. Eventuella tilläggstavlor placeras under huvudtavlan, skulle den nedre tavlan hamna under det fria rummet (just nu 5.3m, kanske lite för mycket marginal) så justeras alla tavlor uppåt. Eftersom höjden är olika på bryggorna så är också stolparna anpassade för varje brygga. OBS: Jag har utgått från STW:s bryggor och stolpar och har bara i enstaka fall kollat mot verkligheten. Det har också kommit med en skylt i tavelpaketet, denna: Bifogad fil 75222 Detta är två varianter av fyra på skylten, och som synes på den högra kan man skriva in namn (och position) på den/de vägskydd som tavlan gäller för, bara en bonusdetalj... Eftersom alla tavlor utgår från en korrekt placering och med inbyggda "offsets" så är behoven av justeringar minimala, skulle tro att det mest behövs mot scenery-objekt eller specialfall! Detta paket ska vara fristående från mitt övriga signalsystem men kräver mitt scriptbiliotek. Det kommer inte att släppas förrän tidigast efter att HF1 har kommit ut. Frågan är om jag ska släppa det utan beta-testning eller om det finns ett par hugade testare där ute... Fler delar ska ju testas senare och framförallt hela Signalsystemet men dit är det ett tag till... Just nu håller jag på och testar och fixar småsaker, samtidigt som jag skriver den efterhängsna manualen... mvh Håkan |
Baliser kan det va något?
2 bifogad(e) fil(er)
Även fast lusten att skriva på forumet är lite dalande så har jag ett par saker i "pipelinen" som jag tänkte klämma ut så får vi se hur det blir sedan!
Jag har ju nämnt flera gånger tidigare att jag skulle skriva litegrann om ATC och baliser. Jag kommer att dela upp inlägget i två delar, där den första delen hanterar ATC och baliser i verkligheten och del 2 hanterar mitt system, som ska fungera som i verkligheten!! Jag kommer att skriva om det konventionella ATC-systemet. Det fanns tidigt en tanke om ett gemensamt europeiskt säkerhetssystem för järnvägstrafik, men efter flera tågolyckor på 1960- och 1970-talen så beslutade Sverige att införa ett eget system - ATC (Automatic Train Control). 1980 togs de första sträckorna med ATC i bruk. 1993 uppdaterades systemet till ATC2 som innehåller: version 2.0 konventionell ATC, version 2.1 Radioblock, version 2.2 Öresunds-förbindelsen. Med ATC2 kom också flera nya finesser, bl.a. P- och A-bortflyttning av målpunkt, Höjning av hastighet efter växel. Många av nyheterna är till för att snabba upp tågtrafiken. ATC indelas i olika områdestyper beroende på hur övervakningen sker.
ATC-systemet består av flera olika delar, här är en principskiss på de grundläggande komponenterna: Bifogad fil 75967 Jag kommer inte att berätta så mycket om delarna som finns i loket men desto mera om kringutrustningen. Baliser En balisgrupp kan bestå av 2-5 baliser. Nu skriker säkert någon och hävdar att man minsann har sett bara en balis! Det är både sant och falskt! Det som ser ut som en balis är i själva verket en Tågdatamottagare (TDM), populärt kallad ruteräss eftersom den ser ut så på planritningen. TDM är opto-styrd och används vid ingångsättning av vägskydd för selekterad fällning, framförallt på snabbtågssträckor, och placeras ca 5km innan vägskyddet som ska aktiveras. Eftersom TDM räknas som en icke säker teknik så ska vägskyddet kompletteras med baliser 100m in på fällsträckan för normaltåg. Det finns även uppdateringsbaliser. TDM ersätts numera med andra tekniker (fortfarande icke säkra) tillexempel givare. Övervakningen av vägskydden utformas med speciella Ot-V balisgrupper. Jag ska inte gå in så mycket i detalj på balisplaceringar men kan nämna att vid vägskydden så finns det sällan en balisgrupp vid vägskyddet som ger en takhastiget. När målpunkten nås får hastigheten höjas direkt utan tåglängdsfördröjning. Om det krävs en förlängd övervakningsträcka så utformas den med speciella Ht-V balisgrupper. När vägen är aktiverad och fri från hinder annulleras Ot-V gruppen annars så ger den "vänta 0" mot målpunkten placerad 100m innan vägskyddet. Baliserna är passiva objekt och kräver ingen egen strömförsörjning. De aktiveras när lokets antenn passerar över baliserna och sänder då ett telegram till fordonet. Telegrammet sänds flera gånger under balispassagen. Minst 8 mottagna telegram krävs för giltig informationspunkt. Huvudbaliserna i en balisgrupp benämns A-, B- och C-balis i den riktning som gruppen gäller för. En enkelriktad balisgrupp med två baliser ger A - B och motriktad B - A. Dubbelriktade grupper betecknas A | A eller A - B - C | A. A-balisen talar om vilken typ av balisgrupp som det är och information om vad som ska övervakas (tex: takhastighet, målhastighet vid signaler och tavlor). B-balisen måste finnas eftersom en balisgrupp alltid ska ha två baliser, bl.a. för riktningsbestämmande och för säkerhet ifall en balis skulle gå sönder. B-balisen ger antingen målavstånd eller takhastighet beroende på vilken funktion som gruppen har. C-balisen kodas med lutningen. P(refix)-balisen placeras före A-balisen och används vid tågslagsberoende nedsättningar och vid bortflyttad målpunkt. N(ummer)-balisen placeras valfritt först eller sist i en signalbalisgrupp. Nummerbalis vid orienteringstavla placeras alltid sist i gruppen. Informationen i baliserna definieras som "ord". Dessa ord kodas med ett heltal från 0 till 14 (även 15 finns men ger "spärrat balisfel"). Balisorden benämns X, Y och Z räknat från vänster. Balisens icke föränderliga värden kodas med kodproppar och plomberas. Baliser finns i flera olika typer:
X-ordet är alltid fast kodat och talar om balisens placering i gruppen och också vad den har för funktion (kategori). De styrbara orden genereras hos datorställverk direkt i förreglingsdatorn och skickas ut via utdelar till baliserna. I övriga fall så skapas de med hjälp av kodare som sitter i skåp, kiosker osv. Kodare Kodarna finns i följande huvudtyper:
Kodarna är konstruerade så att inget enstaka komponentfel kan ge för hög hastighet eller nödbroms och också så att ett ytterligare fel upptäcks. Kodarna känner av strömmen till signallamporna, en del av kodarna har även ingångar för styrsignaler. Kodarnas ingångar är strömstyrda. När en signal visar "stopp" eller "vänta stopp" så ska, av säkerhetsskäl, kodaren så långt som möjligt vara strömlös. Kodorden skapas med hjälp av kodkort (1-15) som placeras i kodaren på specifika platser. Med hjälp av styrsignaler så kan man förändra en signals optiska betydelse och få en bättre tågförning. Kodarna används även som avståndskodare. Nedan ett exempel: Bifogad fil 75968 Den första växeln är dimensionerad för 40 km/h och den andra för 70 km/h i grenspår. Signalen kommer att visa "kör 40" via bägge växlarnas grenspår. Med en Styrsignal, som hämtas från reläer i ställverket, så aktiveras platsen i kodaren med kodkort "4", annars vid signalbilden "kör 40" aktiveras platsen med kodkort "1". Vid signalbild "kör 80", om det inte finns växlar eller annat som motiverar det ska det normalt kodas med "12", Linjehastigheten (270 km/h). Vid höjning av signalbesked ska signalbeskeden "trappas upp" annars finns risk för oönskade styrsignalkombinationer. Bortflyttad målpunkt Det finns två typer av bortflyttad målpunkt:
ATC-systemet kan överföra:
ATC tar hänsyn till:
I del två så kommer jag att berätta om mitt system och kanske något mera som jag inte har fått rum med här. Ska göra lite bilder så tar väl några dagar eller så! mvh Håkan |
Dags för del 2!
8 bifogad(e) fil(er)
I den här delen så kommer jag att koncentrera mig på hur baliserna är tänkta att fungera i mitt signalsystem, även en del annat smått och gott kan följa med i informationen. Jag tar också tillfället i akt att berätta lite mera i detalj om vissa delar av hur informationen i baliserna skapas och presenteras.
Jag redovisar här hur balis-delen av systemet fungerar i skrivande stund, eventuella funderingar på förändringar redovisas i slutet av inlägget. Trappstegssignalering eller bortflyttad målpunkt finns ännu inte med, det kommer att införas när arbetet börjar med lokdatorn eftersom jag vill kunna se i realtid vad som händer. Bortflyttad målpunkt kommer att kräva lite inställningar av användaren medan trappstegsignaleringen kommer att ske helt automatiskt. Lite upprepning Baliserna är passiva objekt, vilket innebär att de inte har någon egen strömförsörjning utan får sin energi från lokets antenn. Informationen som skickas från baliserna skapas antingen via fast kodad data (kodproppar) i balisen eller via kodare/föreglingsdator som skickas via kabel till baliserna. Lite ny information I vissa fall är benämningen på balisgruppen samma som objekt som den hanterar. T.ex Hastighetstavla (Ht) benämns även hos balisgruppen för Ht eller Orienteringstavla för Väg (Ot-V) benämns också Ot-V, vilket kan skapa förvirring och också tron att tavlan Ot-V ska ha balisgrupp, men det är fel! Filosofi Hela signalsystemet och alla andra objekt som jag håller på med genomsyras av några grundläggande tankar:
Balisplacering Utplaceringen av baliserna kan kännas ganska tidsödande, och det kan det också vara men istället för att placera ut baliserna en och en så placerar man ut en balisgrupp, som sedan konfigureras i propertyrutan så att önskad funktion ges. Baliserna ritas sedan upp baserat på vilken funktion som man har valt och hur kodningen sker. Eftersom man placerar ut en hel balisgrupp och inte enskilda baliser så behöver man inte ha kunskapen hur baliserna ska se ut eller konfigureras, detta sköts automatiskt av systemet. Vissa val kan ändå behöva göras för att få en korrekt funktion. Nedan en bild på hur det kan se ut: Bifogad fil 76092 De vita textraderna är bara för kontroller vid tester. Vid utplacering av en balisgrupp så finns ingen balisinformation i gruppen, den är helt annullerad och samtliga baliser visas på sin position. Genom att klicka på dubbelpilen (ska bytas ut) så kan man välja olika typer av funktioner för balisgruppen. Baliser som får sin information från signaler eller tavlor (i Trainz) är länkade via namn t.ex C 22 BG. Repeterbaliser benämns t.ex C 22 RBG, dessa balisgrupper har också en kontroll på att placeringen är korrekt i förhållande till signalen. Även andra grupper kan att ha kontroller på att de placeras rimligt i förhållande till huvudobjekten och andra objekt. Den nedre propertyrutan visar en länkad signal. Lite förklaringar till bilden! Inom den gröna rutan syns balispositionerna (P,A,B,C,N) i olika färger.
För att ta bort en C-balis för lutning så sätts lutningen till 0‰. Balisens position inom gruppen (P,A,B,C,N) sänds inte till lokdatorn. Inom den rosa rutan så visas vad balisen ger för information i textform. Ibland kan det finnas klickbara länkar för att förändra balisens kodning (se bild längre ner), informationen visas endast när balisen är synlig. Inom den gula rutan så visas balisernas kodord i decimalform, exakt samma som i verkligheten. Det är denna information som skickas till lokdatorn i form av telegram och som också mitt system kommer att använda sig av, har ingen reell betydelse får den normala användaren. På balisen till höger syns hur balisorden är placerade. Lite mer detaljinformation X-ordet är alltid fast kodat (förutom hos markör, som bara ger balisnärvaro och TDM som tar emot lokdata) och talar om vilken kategori som balisen hör till. A-balisen ger även gruppens kategori. Bifogad fil 76093 Inom den röda rutan så visas information om balisgruppen och eventuellt länkade objekt. Den nedre raden möjliggör individuella justeringar. A-balisen bestämmer gruppens position och ger referensen för justeringarna. "Längs spåret" flyttar hela gruppen. "Balisavstånd" är avståndet mellan två baliser, grundvärde 2.6 meter (tre tomma sliprar x 0,65meter = 4x0,65) som hämtas från configen. Detta värde går att ändra själv, men då ändras ALLA balisgrupper och uppdateringar tar bort ändringen. På bilden kan man se att spåren inte har ett korrekt slipersavstånd (0,75) och därför är avståndet justerat på den nedre bilden. "Rotera" roterar varje balis 180° så att kablar och proppar kommer åt andra hållet, roteringsknappen i surveyor roterar gruppen och därför "körriktningen". "Hjälp" visar bilden nedan! Bifogad fil 76090 Måtten justeras automatiskt beroende på de val som görs. Nedan visas tre exempel på länkade tavelgrupper: Bifogad fil 76089 Bilderna säger väl det mesta, men ett par kommentarer. Här syns några av de länkar som jag nämnde tidigare som är klickbara. En Hastighetstavla kan vara enkel- eller dubbelriktad och det väljs i propertyrutan. A-balisen ger länkningen via namnet och B-balisen ger länkningen via inskrivet namn vid valet. All grundläggande information hämtas från de länkade tavlorna. Jag vet inte om detta kommer att fungera eller om jag måste lösa dubbelriktade grupper på något annat vis, några olika lösningar finns redan. Namngivning Till skillnad mot signaler och växlar, som har tydliga benämningar och som också bestämmer funktionalitet och beteende så har inte tavlor eller baliser samma "offentliga" namngivning, dock så finns det bestämmelser hur de ska namnges i ritningar. Jag kommer i manualen att ge förslag på hur man kan namnge även dessa objekt för att få ett logiskt och enhetligt förfarande. Det viktigaste är dock att objekten får ett unikt namn. Till sist några bilder som exempel på hur balisgruppernas status kan agera på en större station. Bilderna får tala för sig själva, bara några kommentarer om Stationens utformning. Det är samma station (mod 85) som har visas här tidigare. Stationen är byggd för att testa olika typer av beteende, vilket innebär att vissa signaler borde placeras närmare växlarna för att maximera spårens längd, framförallt signal 31 och 62. Eventuellt kommer jag att bygga om detta senare och flytta vissa av testerna till mer lämpade stationer. Stationen kommer också att utrustas med P- och A-bortflytning och andra finesser i ATC2, bl.a kan man tänka sig grupper för Signalhöjning (SH) efter de yttersta växlarna för att höja till Linjehastighet, man kan även tänka sig höjningsgrupper på nedersta spåret för att höja hastigheten direkt efter 40-växlarna (SH*) mot L44. Bifogad fil 76094 Bifogad fil 76095 Bifogad fil 76096 Fristående Balisgrupp Jag vet inte om det finns något behov av detta men jag har passat på och gjort en fristående variant av balisgruppen, den har inget som helst ATC-beroende utan är bara ett visuellt spektakel. Bifogad fil 76091 Istället för att länka eller välja som tidigare visats, så väljer man gruppens funktion. Valen fungerar som ett hjälpmedel för ett korrekt utseende vid olika typer av funktionalitet. Det finns ingen kontroll på att regler eller annat åtföljs. Justeringsmöjligheterna, hjälpen och knapparna är samma som tidigare redovisats. Vid varje balis så väljer man typ av balis enligt bestämda regler. Varje vald balisgrupp ger en infotext nederst i bild som beskriver hur den är tänkt att användas. Balisgrupper inbyggda i trackside signaler Redan tidigt kring skapandet av Trackside signalerna så fanns funderingar på att lägga in baliserna som val i propertyrutan. Det finns egentligen bara ett par nackdelar med att göra så, dels så blir configen väldigt komplicerad (läs rörig) eftersom configen inte tillåter kommenteringsrader (idiotiskt). Det andra är att propertyrutan innehåller väldigt mycket information, vilket också kan bli rörigt. Fördelarna är dock flera, bl.a behöver inte länkningen utföras mellan balisgruppen och signaler/tavlor (snabbare), färre objekt att placera ut (enklare), all information på samma ställe. Ska signalerna ha inbyggda baliser så ska även tavlorna ha det! Det innebär att jag kommer att skriva om en del av den grundläggande koden för att få ett enhetligt system, vilket kommer att fördröja släppet av tavelpaketet. Eftersom tavelpaketet kommer att vara fristående så kan det innebära att även baliserna i tavelpaketet kommer att kunna konfigureras via tavlorna oberoende av mitt övriga signalsystem eftersom det ändå kräver mitt scriptbibliotek för att fungera. Skälet att ändå redovisa hur baliserna fungerar nu är att det i princip inte blir någon skillnad, bara färre objekt att placera ut. mvh Håkan |
Dags för en trestegsraket...
5 bifogad(e) fil(er)
I och med konverteringen av signalerna/signalsystemet till Trackside så blev det en naturlig konsekvens att införa även Baliser hos Signalerna och Tavlorna. Att få baliserna att visas är inget
problem men att överföra koden, från det som redan fungerade enligt bilderna i tidigare inlägg, blev mera jobb än väntat. Nu har jag hållit på en del med att överföra, skriva om och utvidga hur Balisgruppen, Tavlor och Signaler fungerar och att det är utseendemässigt liknande mellan de olika objekten. Mycket har förändrats dock är inte allt synligt, sedan är det ju så att ingen har ju testat någon del av systemet ännu och vet därför inte hur stor utvecklingen har blivit. Jag tänker dela upp informationen om vad jag har gjort och hur det fungerar i (minst) tre inlägg. Varje inlägg kommer att hantera ett av de tre grundobjekten: Balisgrupp, Signaler och Tavlor. Jag tänkte börja denna trestegsraket på samma tema som i de två senaste inläggen: Balisgruppen! Den stora skillnaden mellan att införa Baliser hos Signalerna och Tavlorna är att länkningen mellan Balisgruppen och objekten, som visas i det tidigare inlägget, inte behöver utföras, därför blir det färre sökningar, färre objekt att arbeta med och en renare Balisgrupp. Observera att Balisgruppen endast fungerar mot mina scriptade objekt. Informationen som Balisgruppen genererar är samma och även propertyrutan ser i stort sett likadan ut som tidigare. Däremot är valen som går att göra och hur Balisgruppen ska namnges lite annorlunda, även hur en del information hämtas kan skilja sig åt. Bifogad fil 76384 Så här ser valmöjligheterna ut just nu men jag vet att det kommer ett par specialare till i listan. Många av valen(kanske alla) har kontroller på att de placeras på ett korrekt vis i förhållande till objekt runtomkring. Dock finns det inte kontroll på att det är korrekt avstånd mellan grupperna eller att antalet balisgrupper (inklusive Signaler/Tavlor med ATC) överstiger maxantalet inom en viss sträcka, dessa fel får Lokdatorn ta hand om! Vissa balisgrupper har namnkrav, andra söker efter ett giltigt objekt inom ett visst avstånd. Jag visar en bild på Rfsi - Repeterbalisgrupp, en väldigt vanlig typ och som också är lite speciell i Balisgruppen. Bifogad fil 76387 Som synes på bilden så är det några tydliga skillnader från Balisgruppen i förra inlägget. Den tredje och fjärde raden innehållande text är de som sticker ut mest, och jag tänker börja med rad fyra. Det länkade objektet fås genom att en sökning genomförs under max 310meter och ska hitta en signal med ett korrekt namn. En Rfsi ska namnges med ett "R" framför sifferdelen av signalens namn, som synes på bilden. Om rätt signal hittas så räknas ett avstånd ut och även lutningen mellan objekten. Balisinformationen skapas automatiskt och man kan välja P-balis (inte klart) och C-balis för lutning. A-balisen kan påverkas för att välja 10-/40-övervakning. En varningens kommentar angående lutningsinformationen (som även finns hos Signaler/Tavlor), den är bara vägledande och måste alltid manuellt väljas. Skälet till detta är att lutningar kan maskeras, t.ex om signal L4 står på 0 meters höjd och signal L6 står på 0 meters höjd så är lutningen 0‰, om det finns en kraftig lutning mellan signalerna så kommer den inte att synas eftersom signalerna fortfarande står på samma höjd! I den tredje raden så väljer man balisgrupp, tavlor och ställer in balisgruppens data. De flesta balisgrupper är fasta och ställs då in med den knappen. Rfsi är styrbar och får sin information av Signalens data, men kan uppdateras direkt med knappen. Bifogad fil 76386 Tavlor som har ATC-beroende hittas normalt i Tavelpaketet, men Rfsi är en speciell liten sak, den behöver inte ha tavlor! Man kan man välja typ av tavla och även justera den precis som de andra tavlorna. Man kan välja gul eller blå tavla, balisdatan och giltiga val ställs in automatiskt. Bifogad fil 76383 Det andra tavelvalet är Balistavla, den finns även i Tavelpaketet, men jag bestämde mig för att lägga in den hos alla balisgrupper för att slippa placera ut en massa extra objekt. Balistavlan placeras automatiskt beroende på antalet baliser, dock så kan man inte göra några justeringar utan tavlans utseende och placering väljs från en lista. Det är inte säkert att alla val som går att göra behövs för att ATC-systemet ska fungera, ett sådant exempel är dubblering av balisgrupper. Vid en hastighetssänkning med mer än 40km/h bör dubblering av OT-grupperna ske, detta har ju (kanske!) ingen betydelse i Trainz men för verklighetens skull så bör de placeras ut. För att underlätta sådana situationer så har jag skapat en special grupp, som visas här nedan: Bifogad fil 76385 Just den här bilden visar också en annan "finess" som jag har infört i stora delar av Signalsystemet, (fel)meddelande vid lämpliga tillfällen. Här kan man utläsa att den förväntade OT-gruppen inte har hittats inom ett korrekt avstånd. Hade gruppen hittats så hade informationen "kopierats" och ställts in automatiskt i dubbleringsgruppen. Balisgruppen kommer att släppas samtidigt som Signalsystemet och inte i en fristående variant eftersom den är hårt knuten till "mina" objekt. Vill man använda sig av Balisgruppens utseende kan den fristående varianten användas som redovisades i föregående tråd, när den snart släpps! Signalerna och Tavlorna har väldigt många förändringar mot det som har redovisats tidigare, vilket paket jag kommer att berätta om i nästa steg är inte bestämt än... mvh Håkan |
Dags att bränna av steg två av raketen...
6 bifogad(e) fil(er)
Jag tror (utan att veta) att intresset av mitt tavelpaket är större än det övriga systemet, eftersom jag har "lovat" att det ska släppas fristående! Därför så tänkte jag i detta andra steg berätta om signaldelen av signalsystemet...:rolleyes:
Som jag nämnde i det föregående inlägget så är det "stora" förändringar hos signal-och taveldelen av signalsystemet. Jag tycker själv att förändringarna enbart är till det bättre, dock är nog förändringarna och sättet att använda objekten större hos tavlorna än signalerna. Många av de saker som jag har förändrat fanns det tankar om redan innan konverteringen till trackside påbörjades och det har blivit en naturlig process att göra hela förändringen samtidigt. Allt är inte klart ännu! Om man vill jämföra med hur det såg ut tidigare så finns det lite bilder under post #12 och #19. Jag har tidigare visat lite bilder och berättat om trackside konverteringen i tråden "HB Signalsystem - Vad tycker ni?" (där får ni gärna fråga saker om signalsystemet och ge önskemål osv) men tänkte ge lite basal information här också! Den stora skillnaden mot det äldre systemet är att det, istället för en "osynlig master"(trackside) som kopplas ihop med en "scenery signal" via namn, endast är ett objekt som placeras ut. Istället för att varje signaltyp är ett trackside objekt så är signalobjekten indelade i olika "identitets-kategorier" (kom jag på nu!). Följande finns nu:
"HB" indikerar objekt som är byggda och/eller scriptade av mig. Nästa bokstavskombination gör att liknande objekt sorteras efter varandra, och sist vad det är för objekt. Detta gör att objekten blir lätta att hitta (tycker jag själv i alla fall). Linje(block)signalerna är inte påbörjade än, utan kommer att konverteras till trackside när Stationssignaler är färdigt. Jag kan dock nämna att den gruppen kommer att handha alla huvudsignaler som finns på linjer med eller utan linjeblock, därför parentesen i namnet, observera också att även Utfarts(block)signaler räknas som linjesignaler och går inte att välja hos Stationssignalerna. Eftersom jag har valt att kategorisera signalerna så blir det också ett annat sätt att arbeta med objekten. Jag tänkte börja med att visa en bild på de val som finns. Bifogad fil 76444 Hos "HB S Försignaler..." så är de sista valen inom parantes, det betyder att de kanske inte kommer att finnas, förutom "Brosignal". Hos "HB S Stationssignaler" så kanske det är någon som ser att det även finns tavlor i listan! Det stämmer, eftersom S-tavla och "Dvsi-tavla" går att ställa rörelseväg mot och därför måste kunna lösa ut dessa, så får de ett signal-/tkl-beteende i Trainz. Tavlorna "Gräns för växling" har till viss del ett tkl-beteende eftersom de markerar en punkt där växling inte får förekomma utan tkl:s medgivande. Hur jag ska lösa detta det vet jag ej ännu, därför så finns de hos signalerna så länge, dock sist i listan... Monteringsalternativen till Johans signaler är de som Johan har gjort, på bilden visas de som finns för Huvudljussignaler. De som jag har gjort är samma som finns i tavelpaketet. Propertyrutan När baliserna infördes hos trackside-signalerna och dess information skulle visas så började det bli väldigt trångt. En tanke som hade frodats ett tag fick ny näring och jag ställde mig frågan "Varför visa information om objekt som är passerat? Det är väl vad som ligger framför som är intressant?" Så jag började skissa på ett annat utseende på propertyrutan! Bifogad fil 76445 Så här ser den ut, jag tänker gå igenom en del i taget: Den övre raden Innehåller en knapp för val av signaltyper enligt föregående bild, och versions numret. Ett klick på frågetecknet visar informationen till höger, observera att informationen är från en annan bild! Röda rutan Justeringar för signalen och monteringsvalen, om sådan finns, styrs automatiskt. Signalerna placeras med centrum 3m över rök (6.5m i brygga) och kan justeras lite uppåt. Vissa signaler får placeras lågt och kommer då att placeras under det fria rummet och närmare spåret, men kan inte placeras på en höjd däremellan. Tavlorna placeras enligt reglerna för dessa. Avståndet till spårmitt är anpassat efter objekternas storlek, förutom vid ktl-montering där de är anpassade till de objekt som finns att tillgå, och kan inte justeras närmare en ett minimiavstånd. Ljusgröna rutan Visar Signalbild och information om varför signalbilden visas. Även Tpl-signaturen visas och går att ändra (än så länge). Man kan inte välja att inte visa Märktavlan längre. Varför kunna välja bort ett objekt som måste finnas? Visningen av tavlan sköts automatsikt beroende på signaltyp och funktion mm. Orangea rutan Val av signalfunktion, ska eventuellt bytas till signalkategori! I och med uppdelningen så finns det bara två att välja mellan, Infartssignal och Mellansignal. Mörkgröna rutan Val om signalen ska ha ATC-beroende. Om man klickar på pilen så visas balisinformationen enligt den nedre bilden om ATC-beroende finns. Justeringar och val går att göra som beskrivet i föregående inlägg. Observera att även här ställs lutningen (C-balisen) in manuellt. Eftersom baliserna, dess information och visning finns hos och sköts av signalen så är länkningen av externa balisgrupper ett minne blott. Gula rutan Visar information till och om nästa "intressanta" objekt. Kolumn två visar information om ytterligare ett objekt om behov finns. Blåa rutan Om signalen har extraval tillgängliga så redovisats de här, allt sköts automatiskt. Om medgivandedvärgsignal väljs så visas rutan nederst till höger, med justeringar och val, en medgivandetavla har inga val. Ett nytt objekt går också att välja, steghållare! Den är initialt synlig men går att välja bort, den placeras automatiskt och går inte att justera annat än vid ktl-montering då man kan välja sida eller bakom. Jag tycker i alla fall att det blev snyggare, renare och tydligare än innan! När vi ändå håller på så kan vi ta Försignalerna och deras propertyrutor! Bifogad fil 76446 Är ju inga större skillnader hos propertyrutan än mot senaste bilden. Men det finns en viktig skillnad, ATC-beroendet! Hos försignalerna och skredförsignalerna väljs inte ATC-beroendet utan det ställs in från den signalen som hittas i söket. En korrekt signal hittas genom att försignalen är rätt namngiven och medriktad. I skrivande stund så tillåter jag följande konventioner. Om huvudljussignalen heter "C 24" så kan försignalen heta "C F24", C FSi24" eller "C Fsi24". Försignalen ställer in Tpl-tavlan automatiskt om huvudljussignalen är en infartsignal, även avståndstavlan visas automatiskt från avståndet 1100 meter. Så inställningen av tilläggstavlor är nästan ett minne blott. Skredvarningsanläggningen I den här signalgruppen så kan man välja skredvarningssignaler. Det finns två typer: skredvarningssignal(stopplykta) och en skredvarningsförsignal. Dessa objekt namnges på ett speciellt vis. De MÅSTE ha "Skred" följt av mellanslag först i namnet annars kommer de inte att fungera. Sedan ett unikt namn på skredområdet, mellanslag och ett namn/nummer på signalen. Vad området eller signalerna heter finns det ingen direkt regel om, men för långt namn och det får inte rum på skylten. "Skred" är däremot viktigt och särskiljer signalerna mot Tpl-signaturerna på banan. Sökningen från skredvarningsförsignalerna sker på samma vis som hos försignalerna. Skredvarningssignalerna söker också och letar efter en motriktad skredvarningssignal med ett korrekt namn. Om signalen hittar ett "skredobjekt" innan sin motriktade signal så kommer det att kunna påverka skredanläggningen och därmed signalerna. Hittas inget skredobjekt så kommer signalerna alltid att vara släckta som på bilden. ATC-beroendet ställs in hos signalen. Skredobjektet skapade jag för att kunna testa funktionaliteten och tanken är att det ska bli ett objekt som andra kan skapa sina egna "skredfunktioner" med hjälp av! Vi tar ett gäng med propertyrutor till bara för att jag kan! Bifogad fil 76447 De enda kommentarer jag behöver ge är väl att tavlornas signalbeteende inte är riktigt färdigt! Jag tänkte visa en (i mitt tycke) väldigt bra finess med mitt signalpaket. Du håller på och bygger och står i och när du testar så upptäcker du att signalerna inte visar korrekta signalbilder. Du öppnar propertyrutan och får se informationen i bilden till vänster: Bifogad fil 76448 I det gamla systemet(i stort samma som STL:s) så fick man byta ut scenery signalen, skriva in namnet igen, länka om och placera signalen på rätt plats igen! I mitt system så väljer man bara en ny signal, giltiga val blir (oftast) kvar och sedan är de klart! I bilden till höger är signalen bytt till en femskenare, reglerna säger att man även kunde ha valt en treskenare, men den är ju restriktivare och ger kör40 direkt! ATC-informationen uppdateras automatiskt. Om signalen flyttas med propertyrutan öppen så kan man se det korrekta avståndet direkt! Lite bilder att avsluta med Bifogad fil 76449 Signalerna och fästena till dessa är JohanV:s alster övriga objekt knutna till signalerna och tavlorna är jag skyldig till. Här kan man se steghållarna "in action" och lite olika placeringar. Observera att varje signal endast är ett objekt, den gröna id-kuben! Bild 2/3 på femskenaren, innehåller följande förutom signalen: baliser, 4st tavlor, tillhörande fästen och steghållare. Allt skapat automatiskt eller via val i propertyrutan. I det gamla systemet, om man förutsätter att märktavlan hör till signalen, så skulle man behöva placera ut sex objekt plus en osynlig master och justera in det mesta manuellt! Nu tog utrymmet slut, har säkert glömt något... mvh Håkan |
Otroligt vilket jobb du gjort. Det finns en sol utanför dörren som har lyst ett tag om du inte visste det. :)
Jag skall testa när den riktiga svenska sommaren kommer. |
Dags för steg tre av raketen...
5 bifogad(e) fil(er)
Idag är det exakt två år sedan jag skapade den här tråden och skrev mitt första inlägg om mitt signalsystem!
Därför passar det väl bra att skriva den första delen av del tre av trestegsraketen! Ja ni läste rätt, första delen! Skälet till varför jag delar upp denna del i flera underavdelningar har två huvudskäl, dels så kommer det jag ska skriva antagligen inte få rum i ett inlägg! Eftersom vissa delar av tavelsystemet har genomgått stora förändringar, så kan jag lika gärna dela upp informationen för tydlighetens skull. Första gången jag nämner att jag håller på med ett eget tavelsystem, med STL:s grejor, är i post #20 skrivet 170207. I och med att .FBX fann sin väg in i Trainz så fick även jag möjlighet att skapa egna objekt, och då föddes idén (och många andra ideér) att göra ett helt eget tavelsystem. I min byggtråd post #9 i början på augusti och sedan i denna tråd post #28 den 20/9 berättar jag om hur tavelpaketet är tänkt att fungera. I denna första del så blir det lite basal information och lite bilder, dock är det så att varken utseendemässigt eller i propertyrutan är det några jätteförändringar mot tidigare information. De stora förändringarna ligger hos ett fåtal tavlor. En stor förändring är ju också att baliserna numera finns och skapas automatiskt även hos tavlorna, vilket innebär att länkning av balisgrupper mot tavlorna är ett minne blott. Namngivning Till skillnad mot signaler och växlar så har tavlorna inte något krav att heta något speciellt. Det finns regler för hur de ska namnges (i vilket fall en del av tavlorna) på ritningar. Även fast tavlorna, med några få undantag, inte behöver namnges i mitt system så finns det en stor vinst med att vissa ges ett unikt namn, varför? Kommer att bli tydligt senare... Mycket av det som jag visade i signalinlägget är hämtat från hur tavlorna var utformade, eftersom de redan var trackside-objekt och det lockar mig att göra ett enhetligt utseende och beteende. Det kommer säkert att bli en del upprepningar från tidigare inlägg, men det kanske inte gör så mycket! I skrivande stund så innehåller tavelpaketet följande tavlor:
I detta inlägg ska jag redovisa Rörelsevägstavlor och Försignalbaliser. Jag tänker bara gå igenom det som är skillnader mot hur signalerna fungerar och börjar med att visa en bild: Bifogad fil 76473 Som synes så känns det mesta igen från tidigare. I justeringsrutan finns möjlighet att välja tavelavstånd mellan tilläggstavlorna istället för rotering (tavlorna går inte att rotera i verkligheten). Justeringen i höjdled är något friare, tavlor som kan placeras både högt och lågt kan även placeras valfritt mellan min- och maxhöjd. Avståndet till spårmitt justeras automatiskt så att det fria rummet uppnås. Även hos tavlorna finns det ett minimiavstånd för varje tavla till spårmitt förutom för placering på Ktl-stolpe där de objekten bestämmer min- och maxavståndet. Alla tavlor kommer att som minst ha information via frågetecknet, vissa tavlor, som synes här kan ha direktinformation i propertyrutan, andra tavlor kan visa extra information via knappar. Allt för att assistera byggaren i sitt uppdrag! De här tavlorna har heller inga baliser knutna till sig, även fast S-tavlan kan ha det, jag tycker inte att det är värt att lägga in det eftersom ATC-informationen bara kommer att fungera mot mitt system och då måste ändå tavlorna från "HB S Stationssignaler" användas. Tavla Försignalbaliser När hastigheten höjdes på befintliga banor och försignalavståndet från den fristående försignalen inte räckte till så skapades den här tavlan, istället för att flytta den befintliga försignalen. Den finns endast på banor med ATC. Den här tavlan är de facto en fristående försignal! Då kanske vän av ordning undrar, varför finns inte den hos signalerna? Det beror på att den inte visar någon signalbild, all signalinformation ges via baliser, och att den inte har något Tkl-beteende. Detta innebär också att den slutgiltiga funktionaliteten hos tavlan inte kommer att finnas förrän ATC och eventuell hastighetsstyrning är klar. Så här ser propertyrutan ut när tavlan är nyutplacerad: Bifogad fil 76474 Eftersom tavlan endast förekommer på banor med ATC så visas alltid balisinformationen och tillhörande baliser. Tavlan måste också namnges på ett korrekt vis, om huvudljussignalen heter "C 26" så kan tavlan heta "C FF26", C FFSi26" eller "C FFsi26". Då kan det se ut som nedan: Bifogad fil 76475 Tavlan kommer att uppdatera balisinformationen i sinom tid men det är alltid lämpligt att använda sig av "Uppdatera balisgruppen" för att se så att man inte har gjort något misstag, eftersom den kollar så att allt är korrekt och om så icke är fallet ges ett felmeddelande. Eftersom balisgruppen är styrbar så kommer balisinformationen att uppdateras vid lämpliga tillfällen, och alltid ge ett korrekt värde, även när propertyrutan är öppen! Ett problem med tavlan är att funktionerna som beskrivs endast fungerar mot mina signalobjekt. Det normala beteendet vid en felaktigt konfigurerad tavla eller signal är att den inte kommer att fungera och att det på något vis syns på objektet. Skälet till att jag vill göra så är att det dels ska vara tydligt att något inte är korrekt och också att objekten inte ska kunna missbrukas och placeras på ett felaktigt vis. Om tavlan inte konfigureras rätt kommer balisgruppen visa -/00 (v. Stopp) och visa 2st baliser! Tavlan kan också användas för att ge motsvarande information vid ett skredvarningsområde. Så här ser respektive skredvarningsobjekts namngivning ut:
"Skred " måste finnas, "Fara" är skredområdets namn och kan vara vad som helst, "I" är namn/nummer på skredsignalen som Fsi/FFsi pekar emot och kan vara vad som helst! Namnen inom parantes är alternativa namngivningar. Felmeddelanden visas om felaktiga objekt hittas eller objekt saknas, vilket även gäller signalerna som kanske inte fick rum senast... Bifogad fil 76476 Eftersom målpunkten saknar baliser så borde FFsi antingen visa "vänta Stopp" eller inte synas alls, ska fixas! Bifogad fil 76477 Närmast i bild syns tavlan konfigurerad som "Skred-FFsi" med den nya ID-symbolen för detta objekt. Ovan syns en felkonfigurerad tavla som det är gjort nu, men ska ändras! De två nästa inläggen kommer att behandla Hastighetstavlan och Orienteringstavlan, hoppas det räcker med ett inlägg per objekt... mvh Håkan |
Underbart! Det ordet kanske inte räcker. ;):tumme_upp::tumme_upp:
|
It's time for some fart...
6 bifogad(e) fil(er)
Som utlovat så kommer nu del två i steg tre av trestegsraketen: Hastighetstavlan(HT).
Den största förändringen hos HT-gruppen är införandet av baliserna, som nämnts tidigare innebär det att all länkning till externa balisgrupper är helt försvunnen. Bifogad fil 76540 Vid utplacering av en HT så ser den ut som på den översta bilden. Gröna rutan Här väljer man hastigheten som syns på tavlan, eller som kommer att visas i ATC om det är Pilupp eller Pilner. Den valda hastigheten bestämmer vilka tilläggstavlor som finns att välja på. Till höger syns vilka val som går att göra. Den valda tilläggstavlan bestämmer i sin tur vilka val som går att göra för nästa tavla, osv. Vissa tillåtna val känns lite konstiga, så kommer säkert att ändra dessa innan släpp, bl.a att tillåta "ATC Överskridning" till lägre hastigheter än 40km/h även fast det går att koda så. T.ex 10km/h med kodad överskridning på 30% ger 10 + 3, avrundat ner till närmaste helt femtal, som blir... 10km/h!! Mycket sådant här detaljpillande som pågår hela tiden... Röda rutan Här kan man välja om HT ska ha baliser kopplade till sig, om det valet är gjort så kan man också välja att visa balisinformationen genom att klicka på pilen. Möjligheten att välja ATC-beroendet bestäms dels av den valda hastigheten och vilka tilläggstavlor som är valda, eftersom vissa tavlor endast finns på ATC-utrustade banor. Jag har valt att tvinga ATC-beroende vid hastigheter över 120km/h, det beror på två saker:
Orangea rutan Val av tilläggstavlorna sker genom att klicka på länken. Här kan man också se en nymodighet (som finns i samtliga tavlor där behov finns), frågetecknet efter den valda tilläggstavlan. Vid en tryckning på frågetecknet så visas en informationstext om hur och varför tavlan används. Namngivning Hos hastighetstavlorna så finns det inga krav på att de namnges på något speciellt vis, ej heller att de har ett unikt namn. Fördelarna med att namnge samtliga objekt som ingår i signalsystemet (och även en del andra) är dock övervägande tycker jag. Hur man namnger är upp till var och en, kort och tydligt är dock bra. På ritningar används ofta kilometertal och då tenderar namnen att bli långa, dock så är det lättare att få naturligt unika namn. Ett förslag visas nedan, observera att det endast är ett exempel... Bifogad fil 76545 Hos HT är det inte jätteviktigt att det finns ett namn, men det är bra, vilket kommer att visa sig tydligare när jag berättar om OT... Som jag skrev tidigare så är den största förändringen införandet av baliser hos HT, detta medför en del ytterligare information och handhavande som jag tänkte berätta om nu! En balisgrupp tillhörande en Hastighetstavla kan antingen vara Enkelriktad eller Dubbelriktad. En enkelriktad balisgrupp är annullerad i den riktningen som den inte gäller för, antingen med en markör(-,-,-) eller med ett speciellt kodord. Detta styrs automatiskt beroende på vilka inställningar som görs i balisgruppen. Jag lägger in bägge bilderna på en gång: BILD 1 Bifogad fil 76541 BILD 2 Bifogad fil 76542 Blåa rutan När man väljer att visa balisinformationen så kan det ibland finnas möjligheter att förändra informationen som balisgruppen skickar ut. Vilken information som går att ändra och inom vilka värden bestäms av hastigheten och tilläggstavlorna. Text som är understruken och bokstäver som är gröna kan påverkas. Gröna rutan Pilsymbolen är aktiv när balisen är inställd på ett sådant vis att den kan vara både enkel- och dubbelriktad. Röda rutan När den enkelriktade pilen klickas så söker HT i 3 meter efter en motriktad tavla av rätt typ, vid ej lyckat sök så visas ett felmeddelande, exempelvis som på bild 1! Om sökningen lyckas så blir tavlan(balisgruppen) dubbelriktad och namnet på funnen tavla visas, om tavlan inte är namngiven så visas GameObjectID istället, vilket inte säger något annat än att ett objekt har blivit funnet, så namngivning kanske inte är så dumt ändå... Mitt rekommenderade förfaringssätt är följande:
Ljusblå rutan Balisinformationen hos den tavlan som är slav går bara att ändras i till viss del. Om mastern görs om till enkelriktad så försvinner länkningen också, detta sker även om en av tavlorna tas bort. Kontrollen sker vid Init av objekten och vid öppning/stängning av PR. OBS: Varje förändring hos länkad HT måste uppdateras manuellt, det finns ingen automatisk uppdatering av balisdatan. Grupperna är ju fast kodade, så se det som att du kodar om baliserna varje gång du ändrar något... Alla(?) tilläggstavlor finns att välja på för HT, en tavelkombination som kanske kommer att användas en del, är områdesgränsen. Det finns lite olika sätt att placera tavlorna vid gränserna som kan vara asymmetriska eller symmetriska, dessutom kan gränstavlorna stå separerade från HT. Jag har valt att införa symmetrisk placering och endast gränstavlor tillsammans med HT i version 1 av tavelpaketet, eftersom det är enklast både för mig men framförallt för byggaren. Ett exempel på hur det kan se ut: Bifogad fil 76543 Tavla "ATC börjar" in till ATC-område och tavla "ATC slutar" in till outrustat område. När balisgruppen in mot ATC-område är utrustad med kurvnedsättning (som på bilden) så ska det finnas en balisgrupp med tvingande(T) hastighet innan, annars så kommer inte tågen att få full ATC-övervakning. Full övervakning sker när den första medriktade balisutrustade signalen har passerats. Den separata T-gruppen finns i balisgruppen. Även en balisgrupp(OTG) med övervakningshastighet inom outrustat område ska finnas före tavla med GMO-information, men det kommer jag att berätta om i samband med OT! Det finns även tilläggstavlor med "ATC Arbetsområde börjar/slutar", även dessa har endast symmetrisk placering. Tavlorna borde knappast användas av någon utan specifika kunskaper, men finns med ändå! Sökning Förfarandet med sökning av motriktad tavelgrupp finns endast för balisutrustade tavlor. Internt är det som att två enkelriktade balisgrupper är placerade vid tavlorna, skulle man dock bygga så, blir det ett garanterat balisfel och inte minst verklighetsfrämmande! Hela idén är ju att det ska vara så nära verkligheten som möjligt och att då tillåta felaktiga placeringar av objekt är något jag försöker att undvika, ibland är det tyvärr omöjligt att ha den kontrollen... Jag försöker att lägga in information, varningar och felmeddelanden direkt i propertyrutan eller i vissa fall hos utseendet hos objekten. Ibland är det inte möjligt att göra så, beroende på att jag inte vet hur byggarna tänker, dessutom kan ATC-byggande vara ganska komplicerat. Eftersom det verkliga ATC-systemet har ett inbyggt felhanterande i form av "balisfelslarm" så kommer jag låta många av de fel som kan uppstå, fångas upp av ATC-systemet, precis som i verkligheten. Dock så är planen att på platser där föregående signal/tavla har baliser men nästa som ska ha det inte har det, lägga in kontroll i form av varning hos objekten och kanske nödbroms eller liknande hos fordonet vare sig det är så i verkligheten eller ej, för att tvinga fram ett korrekt byggande! Jag nämnde i föregående inlägg funderingar på att skapa ytterligare två tavelgrupper, sagt och gjort: "Tuttavla" och Övriga tavlor har sett sitt ljus. Bilden nedan visar dessa grupper i den nedersta bilden. Bifogad fil 76544 "Tuttavlan" eller Ljudsignaltavlan som den heter finns med tre tilläggstavlor som variant till endast huvudtavlan, annars inga konstigheter. På bilden visas även de tavlor som just nu finns i Övriga tavlor. Tavelpaketet Nästa inlägg kommer att handla om Orienteringstavlan och jag misstänker att det kan bli ett lååångt inlägg så skriver lite information om planerna för tavlorna redan nu! Det återstår några uppsnyggningar och lite finness-programmering, sedan ska tavelpaketet testas under SP2 samtidigt ska demobanan klonas och konverteras med trackside signalerna. När funktionaliteten är testad (förhoppningsvis utan några fel) så ska SP3 installeras och tavlorna testas igen. Jag gör så här för att veta om det är jag eller uppdateringen som gör eventuella problem hos tavlorna. Samtidigt ska Manualen skrivas, där huvudfokus kommer att bli på Guide-delen för tavlorna men ska försöka få med så mycket som jag hinner under referensdelen också. Sedan ska paketet släppas, förhoppningsvis inom en månad, kommer dock inte att släppa något om jag inte är nöjd själv... Jag skrev tidigare att balisgruppen inte kommer att släppas annat än i samband med hela signalpaketet, jag kanske har ändrat mig. Risken med att släppa det innan, är att objekt som inte finns att tillgå kan ge "sökfel" och då blir det garanterat frågor från folk som inte läser manualer och säkert andra också.. Så får se hur jag gör! Jag får med en kommentar till: Pursche och RobertE: Tack för berömmet, jo jag har hört ett ryckte om någon stor lampa som lyser:rolleyes: mvh Håkan |
Att först testa i SP2 och sedan i SP3 är en klok väg att gå. Mina erfarenheter att gå från SP2 till SP3 har bjudit på en kalldusch. Det är möjligt att du kanske måste räkna med det, Blomsson.
Din presentation är föredömlig, men när skarpt läge för banbyggarna inträffar får du nog räkna med en störtskur av frågor. Då får du ett pedagogiskt problem, men det löser du får jag hoppas. Du skriver att paketen presenteras om en månad. Är det inte väl optimistiskt? Kan alltid börja med några uppmjukningsfrågor: Som f d scout och orienterare vet jag vad stegräkning innebär, men inte vad steghållare är. Läste på ett ställe "Enablad? False". Vad innebär det? Summa: Imponerande. Nisse |
Hej Kan bara hålla med. Otroligt imponerande. Jag jobbar som besiktning man på signal anläggningar i Sverige på Sweco Rail. Och ser att du verkar inte ha missat någonting.
Det är på en Trafikverkets Nivå. Låter nästan som en Atc2 simulator detta. Men det finns risk att det är för avancerat för många. Jag har rätt mycket kurser i Atc och praktik ute i spåret och jobbar med det dagligen och har tillgång till all atc information man behöver, men det har inte så många här. Hur placerar men en Sh* balis och vad ska föregående A-balis då har för kodning etc. Jag själv håller inte på med trainz så jag får nog inte uppleva detta system i praktiken. Men det ska ändå bli kul att se vart det mynnar ut detta. |
Vänta tills vi börjar fråga efter ERTMS nivå 2 eller 3. Då kan det bli krångligt. :)
|
Tackar alla för utlåtanden, alltid trevligt och uppmuntrande med uppskattning för det man lägger ner tid på att göra!
Citat:
Såg igår att den officiella versionen av SP3 inte är släppt ännu! Citat:
Citat:
Tanken från tidigare i våras var att ha det klart runt midsommar, så redan "försenat"... Citat:
Signaler som är högt placerade på rörstolpar har oftast (alltid!) steghållare, då kan man antigen stå på stegen eller på steghållare när arbete sker i signalen. Steghållare i brygga är inte så vanligt men förekommer, likaså i kontaktledningstople. Huvudsignaler i kontaktledningsstolpe sitter oftast på en stövel som går att stå på, och upp dit kommer de flesta utan steghjälp. Förekommer att andra signaler i kontaktledningsstolpe har steghållare, t.ex Vfsi, och då ger stegen en möjlighet att arbeta med båda händerna fria. Steghållarna syns i de sista bilderna i post #32, framförallt på signalerna längst till vänster. Trodde ingen skulle bry sig om "enabled? false" därför ingen kommentar i texten! Det är gamla tester som va kvar just i den signalen och talade om ifall P-balisen fungerade som tänkt. Så ingenting att bry sig om. Men kan ta en snabbis(!) om hur baliserna ritas upp: Varje balis (P,A,B,C,N) i balisgruppen har två variabler, mEnabled och mValid som bestämmer om balisen ska vara synlig och/eller påverkbar. Det här står beskrivet i tidigare inlägg i denna tråden. Citat:
Citat:
Min generella tanke med signalsystemet är att vem som helst (som orkar läsa en manual) ska kunna bygga med mitt system utan några stora signalkunskaper. Grundregeln är att följa de regler och föreskrifter som finns. I vissa fall, ATC är ett sådant, så kan det lätt bli komplicerat och förvirrat. Eftersom baliserna är "inbyggda" hos signaler och tavlor så behöver endast specificerade grupper placeras ut separat men systemet fungerar även utan dessa grupper, och man behöver ju inte lägga ut en massa SH(*) baliser om man inte vet hur man ska göra:rolleyes:. Frågan är mera hur många extrakontroller som ska ske innan lokdatorn kommer in i bilden, alltså redan under byggandet. Antagligen kommer det finnas många kontroller hos signalerna som inte är implementerade än. Citat:
Dock har jag inga planer på att införa ERTMS, är inge roligt utan fysiska signaler;). Men ska aldrig säga aldrig, efterfrågan styr ju handhavandet eller hur det nu va... mvh Håkan |
| Alla tider är GMT +2. Klockan är nu 04:32. |
Powered by vBulletin® Version 3.7.5
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
© Svenska 3D-Tåg 2001-2009