| Auteur |
 Onderwerp  |
|
|
Patrick Smout
Belgium
89 berichten |
 Geplaatst - 02 jan 2015 : 10:09:03
|
Ik maak gebruik van de mogelijkheden die koploper gebruikt om deadlocks te voorkomen, echter ondanks dit loopt het toch nog niet lekker. Vermoedelijk doe ik dus nog iets fout.
Alvorens m'n database hier te posten heb ik nog een vraag.
Je kan in een blok opgeven dat er bepaalde blokken vrij moeten zijn en voor een andere groep minstens een aantal.
Is het nu zo dat koploper deze blokken nu effectief reserveert op het ogenblik dat deze beslist op een loc verder te laten rijden?
In mijn opzet is het namelijk zo dat sommige blokken waarop getest wordt meer dat 1 blok verder liggen zodat bij vertrek uit een blok deze niet onmiddellijk deel uitmaken van de rijweg.
Met vriendelijke groeten,
Patrick Smout |
Bewerkt door Patrick Smout op 02 jan 2015 17:07:45 |
|
|
hubertus
Netherlands
1909 Posts |
Geplaatst - 02 jan 2015 : 10:43:41
|
Koploper checkt de blokken die je in de deadlock opgeeft.
Als aan de voorwaarden in die deadlock niet wordt voldaan, zal koploper die richting niet kiezen.
Is er op basis van de deadlock voorwaarden geen enkele richting mogelijk, zal de trein niet vertrekken.
Waar de blokken liggen die in de deadlock zijn opgegeven, doet er voor koploper verder niet toe.
Huub |
 |
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 02 jan 2015 : 11:46:49
|
Hallo Huub,
als KL beslist om een richting te kiezen dan moet deze volgens mij op dat ogenblik ook één of meerdere blokken uit de voorwaarde alvast reserveren voor de trein die hij laat vertrekken. Doet KL dit niet dan is de kans reëel dat de zaak alsnog vastloopt omdat een andere trein net hetzelfde kan beslissen.
Zolang de blokken in de voorwaarde vrij blijven kan elke trein blijven testen op een deadlock zonder verder gevolg.
Klopt mijn redenering?
Met vriendelijke groeten,
Patrick Smout |
|
|
|
hubertus
Netherlands
1909 Posts |
Geplaatst - 02 jan 2015 : 12:04:22
|
Volgens mij kan koploper maar een ding tegelijk, maar wel heel snel.
Dus zodra in jouw hypothese op basis van de deadlockvoorwaarden de ene trein kan vertrekken en dus een blok reserveert, kan de andere trein dat niet meer. Ook al zit daar maar een milliseconde of minder tussen.
Huub |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 02 jan 2015 : 17:07:19
|
Hallo Huub,
helemaal akkoord maar wat als de blokken in de deadlock preventie voorwaarden meer dan 2 blokken vooruit liggen (bvb een passeerspoor)?
Als KL standaard maar 1 of 2 blokken vooruit reserveert dan moet er voor de deadlock preventie extra stappen genomen worden. Volgens mij moet KL dan (deels) de blokken die aangegeven zijn in het deadlockpreventie scherm ook al reserveren op het ogenblik dat de trein zijn blok verlaat ongeacht hoeveel blokken vooruit dit is.
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Wim Ros
Netherlands
6228 Posts |
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 02 jan 2015 : 18:59:47
|
Hallo Wim,
zou best kunnen dat ik dit niet begrijp. Zou ook verklaren waarom ik nog steeds deadlocks krijg ondanks het feit dat ik ze volgens mijn beleving wel degelijk correct ingevuld heb.
Zoals ik het begrijp:
Als in de deadlock preventie voor A naar vervolgblok B staat dat Blok C vrij moet zijn en van Blok D/E/F minstens 1 vrij moet zijn dan zal KL een trein in A niet laten vertrekken naar B tenzij C vrij is en van D/E/F/ er minstens 1 vrij is.
Ok zover?
Nu mijn vraag: Als aan deze voorwaarde voldaan is en KL beslist om de trein vanuit A te laten vertrekken naar B, wordt dan C ook automatisch gereserveerd door de trein (en idem dito voor het vrije blok D of E of F)?
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Wim Ros
Netherlands
6228 Posts |
Geplaatst - 02 jan 2015 : 22:27:58
|
Nee, want zodra hij onderweg gaat naar B is de deadlock niet meer van toepassing, die was er alleen om hem te laten vertrekken uit A.
Mvg
Wim.
Alleen de waarheid ligt in het midden
s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus |
Bewerkt door Wim Ros op 02 jan 2015 22:29:10 |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 03 jan 2015 : 12:35:56
|
Wim,
in mijn beleving is dit dan niet 100% waterdicht. Als KL namelijk niet onmiddellijk deze blokken reserveert (bvb. door aantal blokken extra voldoende hoog te zetten zodat zeker de blokken binnen de VW voor de deadlock gereserveerd worden) dan heb je alsnog kans dat dit uitloopt op een deadlock. Een andere trein, komende uit een ander blok, kan net hetzelfde doen voor bvb. blokken D/E/F (ten minste 1 vrij). Als beide doorgaan omdat er daar nog net 1 blok vrij is loopt het alsnog fout (tenzij D/E/F gereserveerd wordt door één van beide treinen op het ogenblik dat één van beide treinen mag vertrekken (deadlock voorwaarde voldaan)
Met vriendelijke groeten,
Patrick Smout |
|
|
|
hubertus
Netherlands
1909 Posts |
Geplaatst - 03 jan 2015 : 12:46:58
|
In zo'n situatie kan het inderdaad zo zijn dat een deadlock niet waterdicht. Dan zul je de oplossing in logische acties en variabele routes moeten gaan zoeken. Vaak is dat sowieso wel aan te raden, omdat je dan veel flexibeler bent.
Huub |
|
|
|
Wim Ros
Netherlands
6228 Posts |
Geplaatst - 03 jan 2015 : 15:27:19
|
Patrick,
Extra blokken vooruit reserveren doe je via je seinstelsel instellingen. De kans is dan groter dat de blokken gereserveerd worden. Als er aan de voorwaarde is voldaan via de deadlock.
Iets 100% waterdicht aftimmeren via deadlocks zal niet lukken.
Maar uit de andere richting kun je controleren of b.v. A en B vrij zijn zodat er niet naar DEF gereden mag worden.
Dus beide richtingen controleren kan een optie zijn.
Mvg
Wim.
Alleen de waarheid ligt in het midden
s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 03 jan 2015 : 20:33:04
|
Hallo Wim,
voor mijn seinstelsel had ik 1 blok extra gereserveerd doch voor enkele schaduwblokken stond aangegeven dat dit genegeerd moest worden. Deze optie terug uitgezet en nu heeft het een aantal uren staan draaien zonder problemen. Beide richtingen werden ook reeds gecontroleerd maar dat bracht geen soelaas.
Probleem zit 'm dus wel degelijk in het feit dat de deadlock check geen reservatie doet. Momenteel kunnen omzeilen via extra blokken voor de seinen maar dus niet waterdicht.
Ter info, ik heb enkele jaren geleden geruime tijd aan het spelen geweest met een deadlock avoidance algoritme dat beschreven is in de volgende paper http://www-bcf.usc.edu/~maged/publications/train_paper95.pdf
A.d.h.v. deze paper heb ik een C++ programma geschreven dat, zonder specifieke voorkennis van de layout of regels, deadlock avoidance doet. Was heel mooi om dit in simulatie aan het werk te zien op een 10-tal verschillende layouts. Ik heb dus wel enige praktijkervaring in deze materie.
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Wim Ros
Netherlands
6228 Posts |
Geplaatst - 04 jan 2015 : 14:44:52
|
Patrick,
De basis van koploper is 1 blok vooruit kijken of reserveren.
Deadlock is kijken vanaf de plaats van vertrek of er later als hij is aangekomen in zijn bestemming nog een vertrek mogelijkheid is. Anders gezegd dat er geen kop tegen kop situatie is ontstaan, meer dan dat is de deadlock preventie niet.
Wil je het intelligenter, dan moet je met logische acties werken, en kijken welk blok bezet is en welk blok vrij en dan via variabele treinroute regelen of de trein mag vertrekken, ook kan je dan eventueel een vaste treinroute activeren waarin je de blokken laat reserveren. Maar alleen met een deadlock los jij het niet op.
Mvg
Wim.
Alleen de waarheid ligt in het midden
s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 04 jan 2015 : 18:46:16
|
Hallo Wim,
ok, bedankt voor de aanvulling mbt logische acties. Hou ik in het achterhoofd mocht het alsnog foutlopen.
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 08 jan 2015 : 23:47:09
|
Na enige tijd in simulatie gereden te hebben kwam het toch nog regelmatig voor dat er een deadlock situatie optrad.
Advies van Wim opgevolgd en enkele korte vaste treinroutes toegevoegd om de blokken onmiddellijk allemaal te claimen zoals ze getest worden door de deadlock instellingen.
Nu al meer dan 3 uren gedraaid zonder een deadlock en geen zichtbare hinder voor een vlot treinenverloop.
Combinatie van de deadlock test + activering vaste route met onmiddellijke claim van alle blokken lijkt een prima combinatie te zijn ter voorkoming van deadlocks.
De deadlock test zorgt er in dit geval voor dat treinen die naar elkaar toe rijden op een enkelsporig traject enkel maar kunnen vertrekken op die baanvakken indien er halverwege ruimte is op de passeersporen (minstens 1 van 2 vrij). De vaste route met onmiddellijk claims over hetzelfde traject zorgt ervoor dat alle blokken van vertrek t.e.m. passeerspoor gereserveerd worden voor de trein alvorens die het enkelsporig baanvak oprijdt.
Iedereen bedankt voor het meedenken!
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Wim Ros
Netherlands
6228 Posts |
Geplaatst - 09 jan 2015 : 11:45:42
|
Patrick,
Kop tegen kop op een enkelspoor met meerdere blokken los je op met een 2-richtinggroep, waarbij de blokken in dat spoor tot dezelfde groep behoren. Heb je verder geen deadlocks voor nodig behalve dat er een blok vrij moet zijn na het enkele spoor die kun je met een deadlock controleren.
Mvg
Wim.
Alleen de waarheid ligt in het midden
s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 09 jan 2015 : 13:12:13
|
De deadlock treed niet op kop tegen kop op het enkelspoor.
Halverwege een enkelsporig traject is er een passeerspoor.
De deadlock test of minstens 1 passeerspoor vrij is (en dit voor een vertrek van een trein vanuit beide kanten/blokken richting passeersporen).
Zelf als slechts één passeerspoor vrij is zal koploper nog altijd langs beide kant een trein laten vertrekken. Eén van beide zal het passeerspoor nog kunnen inrijden en de 2e (kan) zorgen voor een deadlock (hangt van de richting af die de trein op het andere spoor uitwil).
Door de blokken in het passeerspoor te reserveren bmv een vaste route voorkom je dat de 2e trein zal kunnen vertrekken.
Deze uitbreiding zorgt ervoor dat deze situatie geen deadlock meer geeft, echter het rijgedrag is nu wel te voorzichtig. Als namelijk de trein die staat te wachten op het reeds bezette passeerspoor de kant op moet waar de trein vandaan komt die als eerste het nog enige vrije passeerspoor bereikt zal er ook geen deadlock kunnnen optreden.
De deadlock preventie in koploper kan volgens mij deze laatste situatie niet aan (geen mogelijkheid om richting aan te geven voor de passeerspoor blokken en deze alsnog als niet blokkerend te beschouwen als door de richting van de trein een deadlock niet aan de orde is)
Op zich niet zo'n probleem, het werkt nu (zij het iets te voorzichtig) en dat is het belangrijkste.
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Wim Ros
Netherlands
6228 Posts |
Geplaatst - 09 jan 2015 : 13:26:55
|
Patrick,
De passeersporen behoren ook niet tot een 2-richtinggroep, die voorkomt dat er op een enkelspoor in 2 richtingen bereden een kop tegen kop situatie ontstaat.
Heeft verder ook niets met de deadlock preventie te maken. Die heb je alleen nodig om te kijken of je na je enkele spoor een vrijspoor hebt op je inhaal of opstelspoor. Daarmee controleer je geen blokken in je enkele spoor, dat doet de 2-richtinggroep voor je.
Mvg
Wim.
Alleen de waarheid ligt in het midden
s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus |
|
|
|
hubertus
Netherlands
1909 Posts |
Geplaatst - 09 jan 2015 : 19:21:05
|
Als je een beetje bedreven bent in logische acties, zou ik het eerder daarmee oplossen dan met een deadlock-preventie. Op zich doet die deadlock natuurlijk wel wat die moet doen, maar er zijn nog wel wat situaties denkbaar, waar je wat meer flexibiliteit wilt hebben. Een deadlock-preventie geldt altijd, je kunt dus geen onderscheid maken naar bijv. naar rijrichting van treinen in de blokken waarop gecheckt wordt of naar treintype. Volgens mij kun je een deadlock ook op geen enkele wijze omzeilen, ook niet met een vaste route. Op zich begrijpelijk, maar ook hier, soms wil je wat meer flexibiliteit, voor een rangerende loc bijvoorbeeld.
Huub |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 09 jan 2015 : 20:55:00
|
quote:
Oorspronkelijk geplaatst door hubertus
Als je een beetje bedreven bent in logische acties, zou ik het eerder daarmee oplossen dan met een deadlock-preventie.
Zou inderdaad ook een oplossing kunnen zijn. De logische voorwaarden die je instelt met de deadlock preventie zijn straight forward en kan je zo met logische acties realiseren. Voordel is dat je zeker ook al de richting kan testen.
quote:
Volgens mij kun je een deadlock ook op geen enkele wijze omzeilen, ook niet met een vaste route.
Strikt genomen zal een vaste route inderdaad enkel de zaak maar erger maken. In mijn geval wordt de vaste route gebruikt om alle blokken te reserveren tot aan een passeerspoor. Ik misbruik als het ware de vaste route om blokken te reserveren.
Even ter zijde. Het algoritme waar ik mee gespeeld hebt werkt helemaal anders. Dit algoritme gaat ervan uit dat treinen altijd een bestemming hebben. Als nu een trein een volgend blok wil reserveren dan wordt er gecontroleerd of alle andere treinen die rijden nog hun bestemming kunnen bereiken. Zo ja, gaan dan. Zo nee, dan wordt er gezocht naar een passeer mogelijkheid verder op de route. Is die er, geen probleem. Is die er niet dan stopt de trein tot er wel een vrij pad ontstaat. Dit werkt wonderwel vrij goed zonder dat er regels ingesteld moeten worden.
Met vriendelijke groeten,
Patrick Smout |
|
|
|
Henny
Netherlands
102 Posts |
Geplaatst - 09 jan 2015 : 21:54:44
|
heren,
ik heb dit probleem opgelost d.m.v. tellers, dan beperk je het vertrek door een variabele route in of uit te schakelen die vertrek tegen gaat.
werkt prima, kom maar kijken op de vakantiebeurs komende week in Utrecht.
Henny Noordhoek (Duiven gld)
IB-H0m-LTD-Koploper |
|
|
|
Patrick Smout
Belgium
89 Posts |
Geplaatst - 17 jan 2015 : 17:14:46
|
Heel af en toe toch nog een deadlock, echter voor mij volstrekt onverklaarbaar hoe deze kan optreden.
Vandaag de volgend situatie gehad (zie bijlage):
L6215 komt vanuit B27 en wil via B11 naar B20 (of alternatief blok B21) en vervolgens door naar B19. Dit is een vaste route die ingaat vanuit 27 naar 11 en 20/21. Bij start van de route moeten er 2 blokken vrij zijn en deze worden onmiddellijk geclaimd dus 11 en 20 of 21)
L5529 komt vanuit 18 en gaat via 20 of 21 naar 11 en zo naar 27/28.
De situatie is nu gestopt omdat L5529 doorgereden is naar 21 en L6215 ook naar 21 wil.
Dit gedrag kan ik niet verklaren (zie ook logfile)
1) Loc 5529 vertrekt als eerste naar B21.
2) Het vertrek van Loc6215 uit 27 is geregeld via een vaste route. Omdat blok 21 gereserveerd is door 21 zou ik verwachten dat B20 genomen wordt.
3) Dit blijkt dus niet het geval te zijn, L6215 wil ook naar B21 en niet naar het alternatieve blok B20.
Volgens mij mis ik hier iets in het hele verhaal (of strookt de werking niet met wat er bedoelt werd)
 Download Attachment: JoEvi_20150117_075432.txt
486,66 KB
Download Attachment: JoEvi.bck
128,4 KB
Download Attachment: Deadlock.jpg
279,39 KB.
Met vriendelijke groeten,
Patrick Smout |
|
|
| |
Onderwerp |
|
Deadlock problemen
