Äldre Ljussignaler (diskussions tråd).

[MegaCastor]

En uppdatering från felsökningen:

Som ett experiment ersatte jag alla länkade växlar med vanlig växlar.
Inga a,b,c,d i slutet på växelnamnen alltså.

Resultatet blev oförändrat. Felen finns kvar vid starten av sessionen.
Det verkar inte som om länkningen av växlar påverkar detta.

/Magnus

[korvtiger]

Ursprungligen postat av MegaCastor

Låter rimligt. Det första felet dök upp i TANE och är inget som jag har stött på i gamla TS2010.
Det kan ju röra sig om en ny kontroll i TANE:s underliggande system som visar sig på detta sätt.

Uppstår Message overflow-felet i TS2010?
Sökningen skulle som du säger mycket väl kunna vara någon begränsning de lagt till i TANE av någon anledning.

Ursprungligen postat av MegaCastor

Det låter också rimligt.
Men det är ändå lite konstigt för banan saknar blocksignaler. Har det någon betydelse?

Det låter lite märkligt, vet faktiskt inte om det äldre systemet stödjer någon form av blocksignaler, men antagligen. Tror tillochmed att man hade semaforer som blocksignaler längs stambanorna utanför Stockholm, även om det fungerade på ett lite annorlunda sätt på den tiden.
Har kikat på koden och hittat en märklig sak. Svenolov har (som alla vettiga programmerare borde) lagt till en begränsning som gör att sökningen aldrig överstiger ett vist maxavstånd. Detta avstånd är valt till 10km. Detta gör det hela väldigt skumt, för alla spårloopar borde bara resultera i att sökningen terminerar, men av någon anledning pågår sökningen så länge att TANE får nog.
Det skumma är att anropet till sökningen verkar göras för varje signal en gång per sekund, vilket borde innebära att felet uppstår på nytt varje sekund, eller att felet skulle krascha hela signalbiblioteket, så att ingen signal fungerar. Inget av detta inträffar vilket är märkligt.

Ursprungligen postat av MegaCastor

En hypotes:
Jag misstänker att detta kan ha att göra med att scriptet behöver
analyserar banan i uppstarten av sessionen.
Om skriptet behöver bygga upp en intern datastruktur som beskriver
banans layout så behöver scriptet söka igenom banan med TrackSearch
och notera var olika objekt som signaler och växlar finns.
Varje växel blir då ett vägval som leder till en ny del av banan.
Då behöver scriptet lägg om växlarna i tur och ordning och söka
igenom varje del för sig.

En ganska vettig hypotes, men för att söka av spåret behöver inte växlarna faktiskt läggas om, utan scriptet borde själv klara av att hitta vidare på de två spåren. Men jag är ganska säker på att scriptet i början analyserar tågvägar på varje station för att hitta genomfartstågvägar, så det skulle kunna har något med det att göra. Men det borde vara så att den nöjer sig med att använda den lagda tågvägen från signal A till B som genomfartsväg. Ska kika och se om jag kan hitta någon sådan del av koden.

Ursprungligen postat av MegaCastor

Flertalet av dessa a- och b-växlar är två enkla kopplade växlar till
exempel vid övergång från det ena spåret till det andra på en
dubbelspårig sträcka eller vid infarter till stationer.
Det är bekvämt att bara behöva lägga om den ena växeln trots att båda
läggas om samtidigt. Det finns några få engelsmän så det blir inte många
c- och d-växlar.

Låter vettigt. Trodde att det var en enkelspårig bana med tanke på att du använde det gamla signalsystemet.

Ursprungligen postat av MegaCastor

Räknat färdigt:
463 signalobjekt (masters, signal markers, klarerare)
474 växlar varav 16 ingår i 4 dubbla korsningsväxlar (a,b,c,d) och 134 ingår i kopplade växelpar (a,b).
/Magnus

Det är ganska många signaler, men det verkar ju fungera fint när allt väl går igång! Det är också en väldigt hög andel kopplade växlar, men det hjälpte ju inte att ta bort kopplingen, så det är ju inte där felet ligger heller.

Ursprungligen postat av MegaCastor

En uppdatering från felsökningen:

Som ett experiment ersatte jag alla länkade växlar med vanlig växlar.
Inga a,b,c,d i slutet på växelnamnen alltså.

Resultatet blev oförändrat. Felen finns kvar vid starten av sessionen.
Det verkar inte som om länkningen av växlar påverkar detta.

/Magnus

Bytte du nummer på dem, så att de matchade udda/jämn riktning eller tog du bara bort a/b? Skulle kunna vara att scriptet blir förvirrat om det försöker hitta tågvägar och växlarna kommer i fel ordning.

Ett annan teori:
Har du några speciella rules som lägger om växlar i början av sessionen som skulle kunna vara inblandade?

[MegaCastor]

Ursprungligen postat av korvtiger

Uppstår Message overflow-felet i TS2010?
Sökningen skulle som du säger mycket väl kunna vara någon begränsning de lagt till i TANE av någon anledning.

Felet uppstår i TS2010 också.

Lite bakgrund:

Banan började byggas i TS2010 med det moderna signalsystemet.
Problemet med message overflow i början av sessionen uppstod
även där. Tendensen var att felet blev värre ju fler signaler jag satte upp.
Först en enstaka rad i felrutan, sedan flera med växande antal signaler.

Vad värre var, problemet tycks nästan växa exponentiellt så att det vid
en viss punkt "exploderar" och fyller felrutan med liknande message overflow-
meddelanden. Då hänger hela systemet upp till 10 sek i början av sessionen
innan man kan titta på felmeddelandena. Sedan kan man köra tåg och då
tycks signalerna i de flesta fall fungera, även om jag ibland har sett
skumma beteenden hos några enskilda signaler.

Några bilder som visar felutskrifterna:

Översikt

2010-alla.jpg

Början på detaljerna för första raden

2010-1.jpg

Slutet på detaljerna för första raden

2010-2.jpg

Och så fortsätter det...

Edit: Jag har också 76 MB JetLog.txt om det skulle vara av intresse.

Samma signal tycks ge upphov till en massa message overflows.
Det var ungefär i detta läge som jag gick över till TANE...

/Magnus

[korvtiger]

Ursprungligen postat av MegaCastor

Felet uppstår i TS2010 också.

Lite bakgrund:

Banan började byggas i TS2010 med det moderna signalsystemet.
Problemet med message overflow i början av sessionen uppstod
även där. Tendensen var att felet blev värre ju fler signaler jag satte upp.
Först en enstaka rad i felrutan, sedan flera med växande antal signaler.

Vad värre var, problemet tycks nästan växa exponentiellt så att det vid
en viss punkt "exploderar" och fyller felrutan med liknande message overflow-
meddelanden. Då hänger hela systemet upp till 10 sek i början av sessionen
innan man kan titta på felmeddelandena. Sedan kan man köra tåg och då
tycks signalerna i de flesta fall fungera, även om jag ibland har sett
skumma beteenden hos några enskilda signaler.

Men om du för över denna banan i TANE, får du exakt samma fel då? Har denna bana flera signaler än den ifrån TANE som du visade växelfelmeddelandena ifrån?

Det här felet är ju inte samma som det andra, utan ett helt annat. För i det här fallet så overflowas alla signaler på banans message queues. Det verkar som att alla signaler i början av sessionen ungefär samtidigt skickar ett broadcast-meddelande (alltså ett meddelande som alla som lyssnar på signalen kan fånga upp) och talar om att deras signal state har ändrats. (Antagligen för att de alla initialiseras på samma gång och då sätter sitt signal state) Eftersom alla signaler också verkar lyssna på alla andra signaler på banan så kommer alla signalers message queues att innehålla samma meddelanden. En specifik signal (Hoc 52) råkar vara den som får samtliga signalers meddelandeköer att overflowas, därav att det namnet förekommer på alla rader i felmeddelandeöversikten som du visar i första bilden.

Orsaken till det här är att det är fler signaler på banan än vad Trainz klarar av att hantera. Särskilt gamla TS2010 som inte är flertrådad har en tråd där alla signaler initialiseras och får meddelandeköerna att overflowas för att varje signal inte har tid att ta hand om meddelandena. Potentiellt så skulle TANE kunna klara av detta för att den är bättre multitrådad och kan låta signalerna ta hand om meddelandena samtidigt som nya signaler initialiseras.

Det borde gå att få reda på hur många signaler som är maxgränsen. Om du tar valfri signals detaljerade lista och räknar hur många rader med meddelanden som redan är i kön (alltså antal rader som börjar med "router"), så kommer du att få det maximal antalet signaler som går att ha i TS2010. Min gissning är att det är 256.

Själva meddelandet "Signal, StateChanged" är ett standardmeddelande inbyggt i Trainz som det verkar, så jag tror inte att vi kan påverka det på något sätt.
En potentiell lösning skulle vara att leta reda på den loop som initialiserar alla signaler på banan och se till att den bara initialiserar ett 10- eller 100-tal signaler åt gången, och efter varje grupp med signaler tar en kort paus för att lämna över CPU:n till alla signaltrådar så de kan få tid att uppdatera sig och gå igenom meddelandeköerna. Men det förutsätter att detta görs i Svenolovs script och inte är Trainz egna, underliggande signalscript.

Ursprungligen postat av MegaCastor

Edit: Jag har också 76 MB JetLog.txt om det skulle vara av intresse.

Naaae, men tack för erbjudandet! Har nog att göra så det räcker i alla fall!

[MegaCastor]

Ursprungligen postat av korvtiger

Naaae, men tack för erbjudandet! Har nog att göra så det räcker i alla fall!

Trodde nog det men det skadar ju inte att fråga

Hur som helst, tack för informationen. Det finns en hel del att begrunda
och undersöka men jag hinner nog inte med det de närmaste dagarna.

/Magnus

[blomsson]

Hej!

Kan informera om att samma problem uppstår i TANE! Vad jag kan se så är det ungefär samma typ av felmeddelanden. Dock så sker det inte alltid, inte med samma visnings problem med signalerna, vilket gör det lite lurt att åtgärda. Det sker bara vid uppstart av rutten, när signalerna skapas , så är inte på korvtigers resonemang oxå. Fast efter detta problem har hänt så funkar det att lägga in nya objekt och de skapas som vanligt och all den gamla informationen verkar finnas kvar på de tidigare signalerna.

Om du vill ha mer info om detta och TANE så kan jag forska lite mer och lägga upp några skärmdumpar?

mvh
Håkan

[korvtiger]

Ursprungligen postat av blomsson

Hej!

Kan informera om att samma problem uppstår i TANE! Vad jag kan se så är det ungefär samma typ av felmeddelanden. Dock så sker det inte alltid, inte med samma visnings problem med signalerna, vilket gör det lite lurt att åtgärda. Det sker bara vid uppstart av rutten, när signalerna skapas , så är inte på korvtigers resonemang oxå. Fast efter detta problem har hänt så funkar det att lägga in nya objekt och de skapas som vanligt och all den gamla informationen verkar finnas kvar på de tidigare signalerna.

Om du vill ha mer info om detta och TANE så kan jag forska lite mer och lägga upp några skärmdumpar?

mvh
Håkan

Att det bara uppstår ibland beror nog på att TANE är bättre multitrådat. Så medan en processorkärna initialiserar signaler och fyller på alla meddelandeköer kan de andra kärnorna ta hand om dem i de övriga signalerna.

Du får gärna forska mera om detta om du har tid. Jag vet inte om det är något som går att åtgärda, men ju mer information man har ju lättare är det att uttala sig om vad som är fel och vad som kanske kan göras åt det.

Har ett litet experiment som någon av er skulle kunna få göra:

Ta en av era banor som felet uppstår på och gör en kopia av den.
Använd batch replace för att ersätta alla mastrar, SMs och klarerarsignaler på banan med en signal utan massa extra funktionalitet, till exempel:
<kuid:-25:828> Signal BR 3
Använd batch replace till att ta bort alla scenerysignaler också och byt dem mot ett träd eller något som inte är scriptat.
Spara och stäng ned banan.
Kontrollera gärna i CM att banan inte har några STL-signaler eller mastrar som dependencies.
Kör sedan och se vad som händer.
Om samma fel inträffar så är det hela svårt att lösa då begränsningen ligger i Trainz. Om det inte inträffar innebär det antingen att vi kanske kan göra något åt det i scriptet, eller så beror det bara på att signalerna är mer lättviktiga och går snabbare att initialisera, så att Trainz orkar med fler av dem.
Testa gärna detta även i TS2010 om ni har ork/möjlighet.

[MegaCastor]

Ursprungligen postat av korvtiger

Bytte du nummer på dem, så att de matchade udda/jämn riktning eller tog du bara bort a/b? Skulle kunna vara att scriptet blir förvirrat om det försöker hitta tågvägar och växlarna kommer i fel ordning.

Jag bytte nummer för att följa udda-jämn-principen.

Ursprungligen postat av korvtiger

Ett annan teori:
Har du några speciella rules som lägger om växlar i början av sessionen som skulle kunna vara inblandade?

Nej, inget sådant heller.

/Magnus