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

[Pursche]

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.

[blomsson]

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:

• Hastighetstavla
• Orienteringstavla(Inkl. Förvarningstavla)
• Försignalbaliser(Fiktiv försignal)
• Systemgränstavla (Ingen koppling till signalsystemet)
• Rörelsevägstavlor (Ingen koppling till signalsystemet, som redovisas i signalinlägget ovan)
• Balistavla (Ingen koppling till signalsystemet)
• U-tavlor (Ev. koppling till Tkl-systemet)
• Ploglyfttavla (Ingen koppling till signalsystemet)
• Ringsträckeskyltar (Ingen koppling till signalsystemet)
  
• Tillhörande textur-grupper

Jag funderar även på att lägga in "Tuttavla" och en kategori "Övriga tavlor" i tavelpaketet...

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:

1 DvsiT.jpg
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:
2 FFsi PR först.jpg
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:

3 FFsi PR namn.jpg
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:

• Skredobjekt - "Skred Fara"
• Skredvarningsstopplykta - "Skred Fara I"
• Skredvarningsförsignal - "Skred FFara I" (FSiFara, FsiFara)
• Försignalbaliser - "Skred FFFara I" (FFSiFara, FFsiFara)

Detta är ett exempel!
"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...

4 FFsi PR skred.jpg
Eftersom målpunkten saknar baliser så borde FFsi antingen visa "vänta Stopp" eller inte synas alls, ska fixas!
5 FFsi bild skred.jpg
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

[RobertE]

Underbart! Det ordet kanske inte räcker.

[blomsson]

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.

HT del 1.jpg
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:

• Hastigheten som går att koda vid gränsen är max 120km/h.
• Granskningen av alla linjeböcker gav en maxhastighet på linjer utan ATC av 110km/h.

Nackdelen med att bestämma en specifik hastighet är att om man vill bygga en bana innan ATC:s införande med högre hastigheter än 120km/h så går inte det i mitt system. Men jag väljer hellre att det alltid blir rätt än att det ibland blir fel!

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

HT del namn.jpg
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
HT del 2.jpg
BILD 2
HT del 3.jpg

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:

1. Skapa första tavlan, namnge (HT 125K1), ställ in tavlor och balisinformation
2. Stäng propertyrutan (annars sparas inte namnet)
3. Skapa nästa tavla, en bit ifrån den första, gör punkt 1 o 2 (HT 85T)
4. Gör tavla nummer två motriktad, flytta den närmare tavla ett
5. Öppna tavla 1:s PR och klicka på enkelpilen

Vilken som helst av tavlorna kan vara slav eller master, när dom har blivit inställda. Det är alltid masterns baliser som visas.

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:
HT del 4.jpg
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.

HT del 5.jpg
"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

mvh
Håkan

[Nils Blid]

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

[jorgen3]

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.

[Pursche]

Vänta tills vi börjar fråga efter ERTMS nivå 2 eller 3. Då kan det bli krångligt.

[blomsson]

Tackar alla för utlåtanden, alltid trevligt och uppmuntrande med uppskattning för det man lägger ner tid på att göra!

Ursprungligen postat av Nils Blid

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.

Jag har väl inga stora farhågor om att SP3 skulle ge mig några större problem, men vill veta vad det är som orsakar eventuella problem i systemet och därför är det enklare att utföra separata tester. Nackdelen är förstås att det tar längre tid om allt fungerar som det är tänkt.
Såg igår att den officiella versionen av SP3 inte är släppt ännu!

Ursprungligen postat av Nils Blid

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.

Vet inte riktigt vad det pedagogiska problemet skulle vara. Frågor är givetvis välkomna fast jag hoppas och vill att man bemödar sig med att öppna och läsa Manualen innan man frågar om saker, det mesta kommer säkert att stå där. Dessutom så är propertyrutan fullproppad med information, både direkt och via hjälpknappar.

Ursprungligen postat av Nils Blid

Du skriver att paketen presenteras om en månad. Är det inte väl optimistiskt?

Jag skriver att tavelpaketet förhoppningsvis släpps inom en månad! Jag är normalt emot att ge specifika datum eller liknande för släpp och sådant, brukar bara ge ont blod i slutänden. Tavelpaketet är i stort färdigt, och en av de punkterna som jag hade kvar att göra, gjordes färdig igår! Tyvärr brukar de flesta "bra grejer" ge ringar på vattnet, men man får sätta ner foten ibland!
Tanken från tidigare i våras var att ha det klart runt midsommar, så redan "försenat"...

Ursprungligen postat av Nils Blid

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

Steghållare (och ja det heter så) är en anordning för att kunna hänga eller luta stegar mot signaler/stolpar och bryggor så att stegen står stadigt.
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.

Ursprungligen postat av jorgen3

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.

En ej uttalad "dröm" är en "ATC-simulator upplevelse" hos systemet och att lokförare känner igen sig, dock så är det långt kvar dit. Jag har inte påbörjat arbetet med lokdatorn ännu, men lägger grunden till systemet med de passiva objekten och hoppas att Trainz ska tillåta mig att hämta datan, ungefär på samma sätt som görs i verkligheten, och sedan bearbeta den i lokdatorn och därmed påverka lokets olika system och indikeringar.

Ursprungligen postat av jorgen3

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.

ATC har ju den egenheten att det är förhållandevis lätt att förklara hur och varför det används men kan bli nästintill hur komplicerat som helst att bygga och arbeta med.
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.

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.

Ursprungligen postat av Pursche

Vänta tills vi börjar fråga efter ERTMS nivå 2 eller 3. Då kan det bli krångligt.

Säkert, verkar inte vara lika lätt att få tag på information på hur det fungerar internt som det är med ATC:n.
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

[Nils Blid]

Utförliga och lättbegripliga svar. Utmärkt.

Nisse