Diodeschakeling tbv niet gedecteerde secties... nog nodig?

[Te 2/2]

We hebben het over een testbaantje, en daarmee over de middelen om een situatie uit te testen. Laten we de sporen in het schaduwstation gemakshalve even nummeren van onder (in de schets) naar boven. Uitgangspunt: alle opstelsporen zijn bezet, en het inrijspoor is ook bezet. Je laat de trein van spoor 2 vertrekken, en dus.

Stuurt traincontroller de trein vanaf het inrijspoor naar spoor 2. Echter op dat moment zet je het wissel handmatig terug naar spoor 1 (simuleer een defecte wissel). En wat gebeurt er dan met maar 1 detectiepunt op spoor 1?

Ik had van alles erbij kunnen halen, in mijn hoofd gebeurt dat ook. Ik heb op een testafdeling van software gewerkt bij een internet provider, en afgrijselijke dingen mee gemaakt met software die "vandaag nog"  in productie zou gaan. Breek me de bek niet open. Mijn vertrouwen in software die niet door mij is geschreven, is nihil.

[Servé]

Je zou er haast al je wissels met detectie en al je wielen met weerstanden voor uitrusten

Klopt, heb ik ook

Maar wat ik ermee wilde zeggen, is dat een tweede melder als stopmelder altijd wel handig is. Mocht je trein stil blijven staan en de stopmelder niet bereiken, wordt tenminste je wisselstraat niet vrijgegeven.

[jowi]

Toch ligt dat wat genuanceerder. Je voorbeeld, dat bij het gebruik van 1 blok de boel in de war raakt als de lok contact verliest, zou ook met 1 blok geen probleem hoeven zijn. Immers, zodra de lok het blok inrijd, wordt ie gedetecteerd door het systeem, het blok is dan bezet. Als de lok dan vervolgens contact verliest, is ook de melder weer vrij. Dat is een conflict in de software, immers... de lok staat stil, of heeft blijkbaar het blok alweer verlaten, terwijl de software daar geen toestemming voor gegeven heeft... dat is dus in software af te vangen.

Op dezelfde wijze kun je een situatie verzinnen die met 3 melders per blok 'fout' gaat... stel een lok rijd het blok in via de binnenkomstmelder, rijd over de remmelder en stopt keurig op de stopmelder. So far so good. De software geeft het commando om verder te rijden, de lok gaat rijden, maar valt vervolgens stil, nog op de stopmelder krijg je dus een zelfde soort toestand, de software ziet dat de melder niet meer bezet is, geheel volgens plan Ook dit is natuurlijk het halve verhaal, immers zal de lok nooit in het volgende blok aankomen en dus zal het blok wat verlaten wordt niet worden vrijgegeven.

[Te 2/2]

Je mist het punt: het blok is al bezet. Materieelschade is het gevolg als de software niet goed is geschreven. Komt een trein bij een foutieve wisselstand (foutieve rijweg) automatisch tot stilstand in die rijweg of pas na de eerste melder in het volgende (foutieve) blok? Dat is de kern.

Als beroepsgek heb ik de neiging over de schouder van de maker heen te willen kijken.
Wat heeft hij precies gedaan, wat is zijn idee over een rijweg (een object of een methode, en zijn rijwegen dan lijsten, collecties of multiple arrays), wat is zijn idee over een wissel of wisselstraat (alleen dat wissel zelf of tot en met de plek waar flankbewaking nodig blijft).

Laten we beginnen met het wissel, want daarvan heb je inmiddels afgezien: detectie van een rijdende trein op een wissel heeft geen zin. De wissel(tong)stand detecteren wel, maar dan in combinatie met treindetectie op het wissel of als het detectiepunt zich pal na dat wissel (of de wisselstraat)  bevindt.

Wat is pal na? Ik geef een simpel schetsje en een bewerkte foto als voorbeeld:

Toelichting bij boogwissels duurt het langer voordat flankbewaking niet meer nodig is. Pas als de hart-op-hart afstand van de rails groot genoeg is om twee (of meer) treinen naast elkaar te parkeren, zonder dat zij elkaar raken, heeft detectie zin.

en

Bij wissels met tegenboog geldt i.h.a. dat er geen trein kan staan op het spoor zonder de tegenboog naast het spoor met die tegenboog. Pas na de tegenboog is de hart-op-hart afstand groot genoeg om twee treinen naast elkaar te tolereren.
De voorste rode cirkel in het middelste spoor heeft een andere functie.

Als een programmeur zijn visie op het object wissel (of wisselstraat)  beperkt tot alleen dat ene ding (het wissel zelf), of een lijst wissels (wisselstraat noemt), dan mist hij een essentieel punt in z'n analyse, en dat wreekt zich in de werking van de software, met name bij rijwegen. Als hij deze overweging wel heeft meegenomen, dan kan de software je waarschuwen of zelfs verbieden om melders op een bepaalde plaats te leggen.

Ander punt. Als wissel(straat) bewaking en wisselstanddetectie onzinnig is in Koploper en iTrain dan zegt dat iets over de manier waarop rijwegen zijn geanalyseerd en dus geprogrammeerd in die software. Als een foutieve rijweg pas ontdekt wordt na de eerste melder van het foutieve blok, dan volgt daaruit dat het concept "rijweg" een methode is, en geen object. Dat is simpel te testen in TrainController, en voegt dan iets toe over TrainController, iets wat we daarvan nog niet weten.

Maar daarom gaf ik ook aan in een eerdere reactie dat als je dieper de logica in wil duiken, abstracter, objectgeorienteerd, dat je een ander traject in gaat.

Met een testbaantje, treinsimulatie, kun je je de zwakheden in de software bewust worden, en daarmee in de toekomst rekening houden. Bij TC zou dat kunnen worden ondervangen met scripts, wellicht.

[Te 2/2]

Er lopen 2 discussies door elkaar heen; dit is de ene discussie:

Je zou er haast al je wissels met detectie en al je wielen met weerstanden voor uitrusten

Klopt, heb ik ook
(...)

De andere discussie gaat over de on/licht/zinnigheid van detectie op een wissel.

In reactie 72 reageer ik op Ben:

met citaten van Arjan uit een ander forum over een draadje uit 2013 over TrainController. Er zal sinds 2013 best een en ander veranderd zijn in TrainController, maar vast niet zoveel dat het nergens op slaat.


Het is mijn bedoeling om de nodige wagons op één draaistel van een weerstand te voorzien, zodat ze gedetecteerd worden. Waarschijnlijk niet bij alle wagons in de trein, maar toch wel bij verschillende.

en


Het hartstuk wordt aan dezelfde melder geschakeld als de spoorstaaf. Maar één melder per wissel dus.

Volgens mij is er ergens een verband te leggen tussen die opmerkingen, en dat verband is TC-specifiek (specifiek geweest, in ieder geval).

Volgens mij kom je zo niet verder op dit forum.
We zijn allemaal goed bedoelende amateurs, elk met ons eigen ideale besturingssysteem, en dat is niet TC.

Die paar die er goed in zijn, zoals RudyB, kunnen je ook niet helpen.
Mogelijk vind je op http://www.freiwald.com/forum/ meer tips dan hier ooit te vinden zijn.

Wat me wel op valt is dat Nico Teering je aanreikt:

Rij je wel in twee richtingen dan zet je twee stopmarkers in één blok, voor iedere richting één.

Ook RudyB stelt

TC heeft aan 1 permanente sensor per blok, of 2 momentane sensoren, eentje aan elke kant van het blok (indien tweerichtingsverkeer, anders is 1 kant voldoende), eigenlijk genoeg.

In beide passages staat dat TC "eigenlijk" geen stopmelder nodig heeft. En dat klinkt mij gezien de situatie in dit draadje onwaarschijnlijk in de oren.
 
Ga naar https://arjanmooldijk.wordpress.com/
en stel daar je vragen over een 100% veilig schaduwstation in TC.
Daar kom je verder mee dan hier mogelijk is.

Deze mensen zijn Koploper of iTrain rijders die toevallig ook wat in TC lopen te "sleutelen". Heel interessant, maar niet to-the-point.

[Te 2/2]

Dan verschillen we daarin van mening, want ik vind wisselstandterugmelding juist heel zinnig. En ik verbaas me er wel eens over dat anderen daar zo lichtzinnig overheen stappen.
Ik meld de wisselstand altijd terug. Zonder goede terugmelding geen verdere actie. Ook de polarisatie van het puntstuk is daaraan gekoppeld. Zonder melding geen spanning op het puntstuk.
Ik rij dan wel analoog, maar dat maakt voor het principe weinig uit.

Of iets lichtzinnig is of onhaalbaar, hangt af van de gebruikte software.

5 kernverschillen analoog versus pc-gestuurd:

• locdecoder(+software) bepaalt rijrichting
• geijkte rijsnelheid en treinlengte bepalen softwarematig de huidige plek van een trein
• een blokgrens is logisch, niet fysiek
• een juist geconfigureerde blokgrens (parameters) is bepalend voor softwarematige flankbewaking
• om een spookmelding te kunnen krijgen, is een sensor nodig, en wel in een zo vroeg mogelijk stadium (wisseltong of puntstukpolarisatie), alleen dan kan de besturing een spookrijder direct stoppen.
  Bij TC kan dat zo vroeg, bij Koploper misschien niet (en dan kies je voor een melder aan de blokgrens).

Wat analoog lichtzinnig is (spookrijders afstoppen als het te laat is) is computergestuurd misschien onvermijdelijk.

Uit beide onderstaande draadjes blijkt dat het wel kan (maar dat men er meestal van afziet omdat er toch nooit wat gebeurt):
http://forum.beneluxspoor.net/index.php/topic,56245.msg3221417328.html
https://forum.3rail.nl/index.php?topic=37207.0

[henk]

Ik vind dat het woord lichtzinnig wat ... eeeh .... lichtzinnig is gebruikt.  Wat in de grote treinenwereld 'lichtzinnig' zou zijn is op een modelbaan hooguit slordig. De besturingsprogramma's die ik ken laten de centrale een opdracht aan een trein, wissel of sein verstrekken en gaan er gevoeglijk vanuit dat die opdracht ook wordt uitgevoerd. En dat is in 9.999 van de 10.000 gevallen ook zo. De doodenkele keer dat een wissel niet heeft geschakeld, merkt de software dat op het eerste de beste detectiepunt en zet de boel stil. Heel soms is een flankaanrijding niet meer te vermijden. Het resultaat is dan best slordig, maar een doorsnee model ondervindt geen blijvende schade. Tot zover de rampzalige gevolgen van mijn lichtzinnigheid. 

Het kan natuurlijk ook hobby zijn om per se de wisselstand te willen detecteren en daarvan gebruik te maken. En dan is het per definitie goed.

[gvandersel]

In Koploper is ook detektie van de gehele trein mogelijk. Hierdoor worden verloren wagens (als een weerstand op de wielen hebben) gedetekteerd en wordt voorkomen dat een trein die eerst loc voorop rondreed opeens met de locomotief in het midden van de trein rondrijd. OM nog maar te vermijden dat een gemende trein ontstaat met de loc in het midden.
Wat beterft detekteren van wissels. Hiermee kan in bepaalde programma's een rijweg eerder vrijgegeven worden of zelf het omleggen van het wissel tegen gehouden worden.

Wat beterft een blok: dit is een pijp waarin alles wat er aan de ene kant ingaat aan de andere kant uit moet komen. Om te bewaken dat het er ook uit komt zijn terugmelders aangebracht. Voordeel daarvan dat als de pijp erg lang wordt je hem met deze melders in meerdere stukken kunt opdelen.

Groet,

Gerard van der Sel.

[Te 2/2]

Als analoog rijder ben ik geinteresseerd in computer gestuurd rijden, omdat dit iets duidelijk maakt over hoe je analoge schakelingen kunt verbeteren.
Recent heb ik een lijstje gemaakt over wat de verschillen zijn tussen de drie hier genoemde pakketten: Koploper, iTrain en TC. Met name waar het gaat om detectie, wisselstraten en rijwegen.

Focus op overeenkomst of op verschil
Veel gebruikers zoeken naar de overeenkomsten in plaats naar de verschillen, want dat maakt het simpeler om over te stappen. Veel gebruikers beperken zich tot het basisgebruik van een pakket, en hebben daaraan voldoende.

Alle drie de pakketten zijn in staat wisselsstanden en treinen op wissels te detecteren, wisselstraten te bewaken en rijwegen te definieren en zo nodig te bewaken.
Wat voor alle drie opgaat, is dat er niet te detecteren valt als er geen detectiepunten (op de juiste plek) zijn. Een systeem moet nu eenmaal gevoed worden door sensoren.
Toch zijn alledrie de pakketten in staat om heel veel te berekenen in plaats van te checken, en dat vormt misschien wel het grootste verschil met analoog besturen.

Bij analoge besturing blijft het concept rijweg meestal beperkt tot wisselstraten, waarvoor vaak een diodenmatrix is bedraad.
Computer gestuurd zijn alle treinbewegingen op een modelbaan te beschouwen als rijwegen: een baan is als het ware (beeldspraak) een hele grote matrix waarin elke loc een wijzer vormt naar een cel in die matrix.
 
Toch zijn er grote verschillen tussen die pakketten in de afhandeling van blokken en wisselstraten als het op rijwegen aankomt.

Detectie, kansberekening
Je kunt wel uitgaan van puur virtuele melders, of van een absoluut minimum aantal melders, maar dan valt er ook minder te detecteren, en dan kan de software ook minder voorkomen. Als de kans 1 op 10000 is, moet de eerste vraag zijn: bij hoeveel sensoren? En is dat dan bij 1-richtings of 2-richtingsverkeer?
Komt die 1:10000 door een vuiltje op de rails?

Jowi gaat uit van 1 melder per opstelspoor bij 2-richtingsverkeer. Bij dat uitgangspunt is dan de vraag, is dat ook een kans van 1 op 10000?

Arjan gaat voor 100% betrouwbaarheid en gebruikt stroomdetectie op wissels via polarisatie van wisseltong en puntstuk. Als je z'n draadje door leest, dan kom je erachter dat hij later is afgestapt van de detectie van de wisseltong-stand (via een servoarm-schakelaar, en dat principe vervangen heeft door stroomdetectie. Aardig is dat hij vermeldt dat Rosoft voor hem daarvoor de printplaten heeft gemaakt.

Dus Wim gelooft er misschien zelf niet in, of ziet het nut er nu niet (meer) van in. Maar hij weet daardoor wel dat TC de mogelijkheid biedt, net als Koploper en iTrain doen, trouwens.

Ongevalkans versus snellere doorstroom
Ik heb ergens gelezen dat een Koploper-liefhebber alleen op wissels detecteert als deze snel weer moeten kunnen worden vrijgegeven. Dus niet om 0,1 promille ongevallen te voorkomen, maar puur voor een snellere doorstroming.
Ligt dat bij  iTrain- en TC- gebruikers net zo?