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

[korvtiger]

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.

[Jockes]

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.

[blomsson]

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

• Råd och tips om hur man använder Trainz och också hur man ersätter en bana med STL:s system mot mitt. Denna BÖR läsas...
• En Guide-del där systemets komponenter gås igenom och där man får veta hur saker och ting kopplas ihop till en fungerande enhet. Varje del (signaler,tavlor, osv) kommer att ha en egen del. Denna SKA läsas...
• En Referens-del som går in i detalj i många aspekter av signalsystemet. T.ex så kan det finnas listor på vilka tavelkombinationer som finns, vilka avstånd som signalerna ska stå på, hur linjeblocket fungerar osv. Denna del kommer säkert att byggas på efter hand. Denna del kommer att vara direkt kopplad till Guide-delen för enkel åtkomst.

Jag kommer antagligen också att införa information om de delar som samarbetar med mitt signalsystem utifrån. Det tydligaste exemplet är STL:s vägskydd.

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

[blomsson]

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:
T HT Tavelval.jpg
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:
T Justering brygga.jpg
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å...
T Justering stolpe.jpg
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!
Signaler.jpg
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:
Tågvägar.jpg
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

[blomsson]

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:

• Hastighetstavla
• Orienteringstavla
• Försignalbaliser(Fiktiv försignal)
• Systemgränstavla (Ingen koppling till signalsystemet)
• Rörelsevägstavlor (Är tavla med signalbeteende, ev. fler än S-tavla och Dvsi-tavla)
• Balistavla (Ingen koppling till signalsystemet)
• U-tavlor (Ev. koppling till Tkl-systemet)
• Ploglyfttavla (Ingen koppling till signalsystemet)
• Ringsträckaskyltar (Ingen koppling till signalsystemet)

Först ett par collage på lite tavelobjekt.
Rörstolpex2.jpg
Ktl-strävax2.jpg
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:
Monteringsalternativ.jpg
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:
Annan Rörstolpe.jpg

Denna typ av montering ger också en specialare i propertyrutan, möjligheten att välja typ av fäste för varje enskild tavla.
PropertyRutan Annan Rörstolpe.jpg
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:
Montage i Morabrygga.jpg
Montage i Fackbrygga.jpg

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:
Ringskylt.jpg
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

[blomsson]

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

• Område utan ATC
  Föraren kör efter yttre signaler och tavlor, ingen information lämnas normalt till ATC-datorn.
  Om ATC-datorn är aktiv övervakas den lägsta av fordonets inställda sth och eventuell hastighetsbegränsning i området.
• ATC-område (innehåller även delvis utrustat område, saknar baliser vid HT ev även vid OT)
  ATC-information ska lämnas vid alla:
  • Huvudsignaler
  • S-tavlor
  • Slutpunktsstopplyktor
  • Fristående försignaler samt tavlor försignalbaliser och repeterbaliser
  • Skredvarningsstopplyktor och skredvarningsförsignaler
  • Platser där den tillåtna hastigheten på banan förändras (dock inte vid halvutrustade tillfälliga nedsättningar)
  • Förvarningstavlor samt orienteringstavlor för lägre hastighet som inte föregåtts av förvarningstavlor
  • Gränser till andra områdestyper
  Dessutom kan ATC-information lämnas vid vägskyddsanläggningar och på andra platser där de benämns fiktiv signal.
  
• ATC-arbetsområde
  Inom ett ATC-arbetsområde övervakar ATC-datorn inte informationen från baliserna.

ATC-systemet består av flera olika delar, här är en principskiss på de grundläggande komponenterna:
ATC principskiss.jpg

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:

• F - Fast kodad balis
• YZ - Styrbar balis där både Y och Z ordet är styrbart
• Y - Styrbar balis där Y ordet är styrbart
• Z - Styrbar balis där Z ordet är styrbart
• M - Markör (inga kodproppar), sänder endast balisnärvaro och används som ett billigare alternativ till F-balis.
• T - Testbalis, används för att testa ATC-antennen vid driftverkstäder

De styrbara baliserna finns också som opto-baliser, används framförallt vid vägskydds-övervakning, där informationen ska flyttas långa sträckor.

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:

• Försignalkodare
• Växelströmskodare (alla växelströmsdrivna huvudsignaler)
• Likströmskodare (likströmsblocksignaler)
• Dvärgsignalkodare (huvuddvärgsignalernas gröna sken)

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:

Kodare:styrsignal exempel.jpg

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:

• P-bortflyttning som är avsedd för genomsignalering. Den är hävbar vilket innebär att den kan ersättas av en ny. P-bortflyttningen kan peka förbi flera hsi, endast en kan existera åt gången. Målavståndet består av grundavstånd till nästa signal (kodas i B-balisen) och ett bortflyttningsavstånd (kodas i P-balisen) som är avståndet från nästa signal till den verkliga målpunkten. Indikeras med ett "P" i entalspositionen i F- och H-indikatorn.
  
• A-bortflyttning som är avsedd för bortflyttning av den av vxl dimensionerade målhastigheten, förbi en hsi mot vxl-spets. Den låses vid passage av en hsi och kan inte hävas. Vid fsi till station kodas P-balis med avståndet mellan infsi och vxl och i A-balisen kodas som vanligt den tillåtna hastigheten genom växeln som ett försignalbesked. ATC-datorn lägger upp en bromskurva mot växelspetsen istället för mot infsi, vid passage sparas dess hastighetsbesked och läggs in som ny takhastighet vid målpunkten.Indikeras med ett "A" i entalspositionen i F- och H-indikatorn.

Transmission
ATC-systemet kan överföra:

• Information som visas i optiska signaler
• Information som skulle ha visats om signalsystemet byggts om med hänsyn till nya hastighetsnivåer och målavstånd
• information via tågradion
• Del av information som finns i linjeboken (primärt hastighetsnedsättningar)

Följande informationsmängder kan överföras:

• Takhastigheter, inkl. stopp
• Målhastigheter från försignaler, kombinerade signaler och huvuddvärgar
• Takhastighet från hastighetstavlor
• Målhastighet från orienteringstavlor
• Målavstånd mellan för- och huvudsignal (även över flera blocksträckor), resp. mellan orienteringstavla och hastighetstavla
• Lutning till målpunkten
• Kanalnummer och positionsinformation för tågradio
• Via tågradio kan information avseende en bestämd signalpunkt överföras

ATC tar hänsyn till:

• Bromsuppgifter
• Tåglängd
• Tågets största tillåtna hastighet (sth)
• Tågets beroende av banegenskaper, t.ex. kurvor, broar, etc

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

[blomsson]

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:

• Användarvänligt.
• Så mycket som möjligt ska vara automatiserat, inga inställningar ska behöva göras som ändå är givna eller kan hämtas
• Tydlig och faktabaserad information i hur systemet fungerar och vad som eventuellt skiljer sig från verkligheten.
• Vem som helst ska kunna använda och bygga med systemet, det gäller bara att följa manualen och regelverket!

Ett fungerande ATC-system ska enkelt fås bara genom att placera baliser vid tavlor och signaler utan någon annan kunskap.

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:
BG Balisinfo.jpg
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.

• Röd - Balisen osynlig, annullerad men ej klickbar
• Gul - Balisen synlig, kodad (funktionell) men ej klickbar
• Grön - Balisen osynlig, anullerad och klickbar
• Grön - Balisen synlig, kodad (funktionell) och klickbar

Kanske verkar dumt att "Grön" kan vara två lägen, men egentligen så betyder det att den är påverkbar och vilken status balisen har syns ju i kodrutan, funktionsrutan och om balisen visas eller ej, blir tydligt ändå tycker jag!
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.

BG Baliskategorier.jpg

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!
BG Balishjälp.jpg
Måtten justeras automatiskt beroende på de val som görs.

Nedan visas tre exempel på länkade tavelgrupper:
BG Balisgrupper.jpg

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.

BG Baliskods exempel Tv 22-32-42.jpg

BG Baliskods exempel Tv 22-62-42.jpg

BG Baliskods exempel Tv 22-64-42.jpg

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.

BG Balisinfo fristående.jpg

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