Print deze pagina | Sluit het venster

Onverklaarbare stop

Geprint door: Koploperforum Digitale Treinbesturing
Webadres onderwerp: http://www.koploperforum.nl/topic.asp?TOPIC_ID=5329
Geprint op: 08 dec 2016

Onderwerp:


Auteur onderwerp: janspoor
Onderwerp: Onverklaarbare stop
Geplaatst op: 10 okt 2015 21:52:34
Bericht:

Goedenavond. Een vreemd verschijnsel dat ik niet kan oplossen: de in tractie rijdende locs Railion en Railion-2 stoppen steeds op de eerste bezetmelder (4.09) in blok 3. Alle andere locs rijden goed door naar 4.10, dus kennelijk ligt het niet aan de baan. Gek genoeg wordt "waar in baan" wel goed aangegeven op 4.10. Moet ik voor de in tractie rijdende locs nog iets extra's aanvinken o.i.d.?
Zojuist gebeurde precies hetzelfde met loc Bordeaux-2 maar nu in blok 2 op bezetmelder 2.16. Ook hier klopte het "waar in baan" wel want die stond op 2.15. Help, het spookt!!!! Hopelijk zie ik iets over het hoofd wat jullie meteen zien: dat zou fantastisch zijn. Groet van Jan

Download Attachment: blokken-82.bck
243,26 KB

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft

Reacties:


Reageer op auteur: Wim Ros
Gereageerd: 11 okt 2015 00:04:01
Bericht:

De communicatie logging mee laten lopen daarin kun je zien wat er gebeurd en wanneer het gebeurd.

Mvg
Wim

Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: janspoor
Gereageerd: 11 okt 2015 14:54:06
Bericht:

Dank, Wim, voor de suggestie. Die heb ik nu toegepast en er zijn me een paar dingen opgevallen: ik heb er goed op gelet dat het vinkje bij "spookmeldingen" uit staat en alleen het vinkje bij "bezetmelding wijziging" aan, maar het lijkt wel dat de bezetmelder bij iedere wagon wisselt van "bezet" naar "vrij", terwijl op het betreffende scherm van Ecos echt alleen maar een bezetmelding wordt weergegeven als de loc passeert. Dus dat snap ik niet. Om het geheel een beetje beheersbaar te houden heb ik met twee treinen (en later alleen met de locs) gereden en lijkt alles keurig te werken zoals het hoort. Wel valt me op dat soms de volgende bezetmelder eerder op "bezet" staat dan de vorige op "vrij", maar omdat dat nog nooit problemen heeft gegeven zal dat nu ook wel geen punt zijn, denk ik. Maar waarom het aanvankelijk beschreven probleem zich voordoet is me nog steeds niet duidelijk. Ik sta open voor (verdere) suggestie's. Waarvoor alvast dank. Groet, Jan

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: Wim Ros
Gereageerd: 11 okt 2015 17:23:50
Bericht:

Jan,

Ik kan daar niets zinnigs over zeggen want ik heb je baan er niet bij,
Maar dat bezetmeldingen eerder bezet zijn als dat de vorige vrijgegeven is lijkt me niet zo vreemd. En zo te lezen trek je de verkeerde conclusies, en weet je niet hoe het werkt en wat je mag verwachten.

De logging is ervoor om te kijken of het stopblok tegelijk met de binnenkomst melder bezet gemeld wordt, dat is de enigste verklaring waarom de trein te vroeg stopt.

Spookmeldingen zullen niet werken want het gaat immers om gereserveerde meldpunten in een blok, pas als er een melder buiten de reservering bezet gemeld wordt is er sprake van een spookmelding.

Dat je scherm trager werkt dan de communicatie met de PC dat kan heel goed, en als koploper vrij bezet vrij geeft is het misschien tijd om de baan en of de wielen eens schoon te maken.

Mvg
Wim.

Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: janspoor
Gereageerd: 11 okt 2015 22:21:21
Bericht:

OK, Wim, ik puzzel verder. Je bedoelt dat je mijn baan er fysiek niet bij hebt, neem ik aan? Want ik heb in mijn eerste bericht een attachment bijgevoegd. In ieder geval bedankt zover voor het meedenken. Groet, Jan

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: KdeB
Gereageerd: 12 okt 2015 15:54:32
Bericht:

Hoi Jan

heb ik ook last van gehad, bezetmelder vrij/bezet. Bij mij waren het vuile wielen.
Ik neem wel aan dat je binnenkomst melder lang genoeg is om de wagons te dedecteren.

Mvg
Koos



Met vriendelijke groeten
Koos de Bruin

Het wordt vanzelf weer kerstmis.
Marklin, Ecos2, Koploper, Crail, Windows XP.


Reageer op auteur: janspoor
Gereageerd: 12 okt 2015 16:31:01
Bericht:

Dat switchen "vrij/bezet" doet hij alleen als er wagons achter de loc hangen. Ik heb nog iets anders geconstateerd: als ik alleen de wagons met de hand heen en weer beweeg over de meldsectie, krijg ik ook een melding in de communicatie logging, hoe vreemd is dat? Terwijl ik zeker weet dat er geen weerstandslak o.i.d. onder de wagons zit en ik heb jet ook niet over wagons met verlichting. Wat bedoel je precies met je vraag of de binnenkomstsectie lang genoeg is? de locs, ook die in tractie, passen er helemaal in, maar natuurlijk niet de hele trein incl. wagons. Groet, Jan

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: phdirk
Gereageerd: 12 okt 2015 19:37:10
Bericht:

Hallo Jan,

Gebeurt het inkomen van je bezetmelder als één van de wielen van je wagens net op de geïsoleerde raillas staat tussen de bezetmeldsectie en het niet gedetedteerde stuk, of de volgende bezetmelder. Je overbrugt dan namelijk de isolatie op dat moment en dan zal je bezetmelder inkomen.
Uit je posts maak ik op dat je niet met volledig gedetecteerde treinen rijdt en de wagens niet stroomafnemend zijn.


Met beste groeten
Dirk
HO=TC


Reageer op auteur: janspoor
Gereageerd: 12 okt 2015 21:10:37
Bericht:

Dag Dirk. Dat zal het zijn inderdaad. Ik had daar ook al een moment aan gedacht maar ben blij dat jij dat nu bevestigt. Nee, ik rijd inderdaad met niet volledig gedetecteerde treinen. Dat is nog een volgende stap. Ik ben al blij dat ik zo ver ben gekomen. Dank voor je suggestie. Mvrgr Jan

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: janspoor
Gereageerd: 14 okt 2015 13:48:02
Bericht:

Omdat het blok (5) dat volgt op de blokken waar het fout ging (3 en 4) relatief kort is, en de trein waarmee het fout ging relatief lang, heb ik nu het vrijkomen van het vorige blok verplaatst van de eerste naar de tweede bezetmelder en dat lijkt te werken. Ik kan het niet helemaal verklaren, maar ik ga voor het eindresultaat .

M vr Groet, Jan

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: Klaas Baas
Gereageerd: 16 okt 2015 11:39:55
Bericht:

Het zelfde probleem komt ook op mijn baan voor.
De wielen van de wagons geven als zij op de onderbreking staan een signaal aan de bezetmelder "bezet". Bij een trein met 10 x 6 assen dus 60 x bezet, vrij. Of dit door vuile wielen komt betwijfel ik omdat ik denk dat hoe schoner de wielen hoe beter het contact.
Ik heb het vermoeden dat de stop in de eerste bezetmelder van het blok komt door het contact van de wielen.
Het is me niet duidelijk hoe jullie dit opgelost hebben als dat al zo is. Kan iemand me dat duidelijk maken.


Reageer op auteur: Wim Ros
Gereageerd: 16 okt 2015 12:02:40
Bericht:

Staat bij jullie de spookmelding aan, en krijg je een popupscherm met een spookmelding op de betreffende melder.
Dat aan/uit/aan gedrag is normaal en daar is niets aan te doen. Koploper reageert alleen op de eerste melding alle andere meldingen worden normaal gesproken genegeerd.
Ook hier worden de verkeerde conclusies getrokken.
Het kan alleen zijn dat het op de een of andere manier iets met de spookmeldingen te maken heeft. Of anders iets met het verschuiven van de binnenkomende terugmeld gevevens. Maar dat is alleen te achterhalen met het systeem en de baan erbij, of door de loggegevens op de juiste manier te analyseren.

Mvg
Wim.


Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: Klaas Baas
Gereageerd: 16 okt 2015 13:55:11
Bericht:

Wim bedankt voor je reactie,

Spookmelding registreren staat bij mij uit.
De stop op 1e bzmeldpunt gebeurt niet constant maar zo af en toe en in verschillende blokken.

Hartelijke groet,

Klaas Baas


Reageer op auteur: phdirk
Gereageerd: 16 okt 2015 14:25:51
Bericht:

Hallo Jan en Klaas,

Ik heb in het verleden ook last gehad met het 'knipperen' van bezetmelders. Ik heb dat probleem ondervangen door de wachttijd van de bezetmelders te verhogen. Dat doe je bij [Algemeen]=>[Instellingen per database]=>[Remmen/Spooktrein/Massa]. Je kunt dan bij 'Maximale vrije tijd bezetmelder/spooktrein' een hogere waarde invullen. Bij mij staat die nu op 16 sec in plaats van 3. Het is een beetje uitzoeken wat de optimale waarde is. Ik ben begonnen bij 20 sec en ben toen steeds 1 sec lager gegaan tot de problemen terugkwamen. Ik ben toen weer 1 sec omhoog gegaan en sindsdien geen problemen meer gehad.


Met beste groeten
Dirk
HO=TC


Reageer op auteur: Klaas Baas
Gereageerd: 17 okt 2015 10:21:15
Bericht:

Bedankt Dirk,

Ik ga met de instellingen die jij beschrijft aan de slag.

Hartelijke groet,

Klaas


Reageer op auteur: dentheo
Gereageerd: 17 okt 2015 10:40:16
Bericht:

Is dit draadje niet uit de hand gelopen ?

1)Is het probleem dat de trein stopt op de eerste bezetmelder ? Of

2)Is het probleem dat de eerste bezetmelder pinkt ?

Lijken mij twee probleempjes

Theo vanop de heide.
N+SX+kpl+kplRsd


Reageer op auteur: Wim Ros
Gereageerd: 17 okt 2015 11:19:50
Bericht:

De Trein zal alleen stoppen als hij daar een opdracht voor krijgt, dus de bezetmelder die daar verantwoordelijk voor is, is even bezet. Dat krijgt hij door van de bezetmelder/centrale.
Waarom dat gebeurd kan diverse oorzaken hebben, een aantal meest voorkomende zijn hier besproken, aan de eigenaren van de banen te bepalen welke mogelijkheden van toepassing zijn, voor hun situatie.
Het aanzetten van de communicatie logging kan daar een grote hulp in zijn, en dan de kunst die op de juiste manier te lezen.

Mvg
Wim.


Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: janspoor
Gereageerd: 17 okt 2015 12:26:59
Bericht:

Nee, ik vind van niet: beide probleempjes lijken met elkaar te maken te (kunnen) hebben. Ik vind het wel interessant dat het probleem(pje) zich dus wel vaker voordoet.

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: dentheo
Gereageerd: 17 okt 2015 18:59:34
Bericht:

Alles startte met de loks die stopten op de eerste bezetmelder in plaats van de tweede.
Nu is het draadje al enkele dagen over het knipperen van de eerste bezetmelder, over de tweede is nooit meer gesproken.
Als nu de tweede zou meeknipperen ben ik akkoord, dan moet de trein stoppen, maar dat heb ik nooit gelezen.

Misschien een bijkomende vraag: wat ligt er voor en na de eerste bezetmelder, weer een bezetmelder of niet gedetecteerde stukken ?

Theo vanop de heide.
N+SX+kpl+kplRsd


Reageer op auteur: Ben
Gereageerd: 17 okt 2015 19:50:36
Bericht:

Jan,

Wim vroeg het eerder: wat zegt de logging over de stopmelder als de binnenkomst melder bezet wordt.......?

Fout zoeken pak je structureel aan en niet door er van alles bij te halen want dan verdwaal je.

Gr, Ben.


Reageer op auteur: janspoor
Gereageerd: 17 okt 2015 22:43:26
Bericht:

De logging zegt dat de bezet melder "bezet" is en als de loc deze heeft verlaten dat hij "vrij" is. Maar daarna begint het "geknipper". Ik heb nu van Wim begrepen dat dat valse meldingen zijn en dat er alleen op het eerste bezetsignaal gereageerd wordt. Maar inmiddels heb ik het (denk ik) opgelost (zie eerder bericht). Overigens heb ik hetzelfde verschijnsel in een ander blok ook al eens aan de hand gehad, net zoals Klaas zei. En nog even op de vraag van Theo: op de beginsectie volgt een niet-gedecteerd deel, gevolgd door de stopsectie. Wat mij betreft mag het draadje gesloten worden.

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: dentheo
Gereageerd: 18 okt 2015 11:03:50
Bericht:

Wanneer je hiermee bedoelt het vrijgeven van het vorige blok verleggen naar de tweede bezetmelder dan versta ik er niets meer van.
Dat mag geen invloed hebben op het stoppen...

Theo vanop de heide.
N+SX+kpl+kplRsd


Reageer op auteur: Wim Ros
Gereageerd: 18 okt 2015 11:31:43
Bericht:

Jan,

Dat bedoel ik dus met de hele wereld erbij betrekken en Jan en Alleman de schuld geven van iets in dit geval dus het vrijgeven van het VORIGE blok.

Het vrijgeven van het vorige blok heeft niets met het te vroeg stoppen te maken in het VOLGENDE blok, het blok waar de trein zich in bevind.

Het vrijgeven op de laatste melder is voor jouw situatie de juiste je werkt immers niet met volledige stroomafname in je treinen, alleen de loc neemt stroom af.

Knipperen wil alleen maar zeggen dat de melder bezet gemaakt wordt zal gebeuren als de wielen over de scheidingen gaan, of vuil zijn.
Dat is dus iets wat je volledig kunt negeren, en heeft totaal geen invloed op het geheel.
De conclusie dat het vrijgeven op de laatste melder de oplossing is lijkt mij onjuist.

Mvg
Wim.



Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: janspoor
Gereageerd: 19 okt 2015 10:12:27
Bericht:

Maar Wim, "de hele wereld erbij betrekken" dat is toch juist de bedoeling van dit forum (ook de betekenis van dit woord trouwens)? Ik constateer een probleem(pje) in Koploper waarvoor ik geen oplossing kan vinden of bedenken. Dan is het toch juist fijn om dit probleem aan andere Koplopergebruikers voor te leggen met de vraag of ze dit herkennen en er wellicht een oplossing voor hebben? Dat het probleem zich uitbreidt tot andere problemen of aspecten is logisch bij een ingewikkeld programma als Koploper. En dat ik ga experimenteren met "oplossingen" lijkt me ook logisch, ook al is zo'n oplossing in de ogen van een ervarener iemand een schijn oplossing. Maar goed, ik had al gezegd dat het draadje wat mij betreft mocht worden gesloten. Allen hartelijk dank voor alle reacties. We sporen verder.

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: hubertus
Gereageerd: 19 okt 2015 10:19:02
Bericht:

Ik denk dat Wim met "de hele wereld erbij betrekken" doelt op het feit dat je er zaken bij gaat halen die niks met je probleem te maken hebben.
Niet dat je er andere mensen bij betrekt.

En ik ben het wel met Wim eens dat het probleem dat je schetst niks te maken heeft met het moment van vrijgeven van het vorige blok.
Als dat al een oplossing is, heb je een symptoom bestreden, maar niet het onderliggende probleem opgelost.

Huub


Reageer op auteur: janspoor
Gereageerd: 19 okt 2015 17:06:17
Bericht:

OK, Huub, zo kun je het ook bekijken. Ik ben me er overigens van bewust dat ik een symptoom bestreden heb en ik ga ook verder met zoeken maar voorlopig kan ik in ieder geval weer even vooruit. Mij zijn een paar dingen weer duidelijk(er) geworden. Dank voor alle reacties.

Vriendelijke groet

Jan

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Reageer op auteur: janspoor
Gereageerd: 27 okt 2015 16:01:57
Bericht:

Ik zat zojuist de inzending van mijnheer Zuyderduyn te lezen en dat hij min of meer hetzelfde probleem ervaart. Bij mij is het ook weer gebeurd en ja, Wim, de rails en de wielen zijn goed schoon en ik beloof je dat ik er niet Jan en Alleman bij zal halen, maar het probleem is dat het niet iedere keer gebeurt en ook met communicatie logging kan ik er niet achter komen wat er fout gaat. Dus het probleem, nogmaals, is dat een trein de bezetmeldsectie van een blok in rijdt en daar stopt, terwijl in het baanontwerp het "waar in blok"-teken wel aangeeft dat hij in de correcte stopsectie zou zijn. Maar op de ECOS staat weld de inrijdsectie als bezet gemeld, evenals het communicatie-log. Wat kan er toch zijn? Gr Jan


Reageer op auteur: hubertus
Gereageerd: 27 okt 2015 16:30:47
Bericht:

Of de inrijsectie bezet is gemeld, is niet zo interessant.
Veel belangrijker is of de stopsectie ook bezet is gemeld.
Kun je dat zien in de logging?

Huub


Reageer op auteur: Wim Ros
Gereageerd: 27 okt 2015 20:50:27
Bericht:

Jan,

Als de stopsectie bezet gemeld wordt dan laat koploper de trein stoppen, die heeft het signaal gekregen dat de trein daar is.
Koploper doet alleen wat hem wordt opgedragen.
Logging mee laten lopen en kijken wat de melder doet vlak voor dat de loc gaat stoppen. Meer is het niet, en dan de oorzaak zoeken en oplossen. Op Eurospoor was een vereniging met een soortgelijk probleem, en daar kwam duidelijk naar voren dat de stopmelder een bezetsignaal gaf, terwijl de trein er nog niet was. Dat is wat er ook bij jouw gebeurd en wat er bij Zuyderduyn gebeurd.


Mvg
Wim.


Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: dentheo
Gereageerd: 27 okt 2015 22:02:53
Bericht:

Inderdaad.
Nog interessant voor foutzoekers is dat koploper reageert op het bezet "worden" van een bezetmelder, niet op het bezet zijn of blijven.

Theo vanop de heide.
N+SX+kpl+kplRsd


Reageer op auteur: Klaas Baas
Gereageerd: 29 okt 2015 09:23:47
Bericht:

Dag allemaal,

Bij mij hetzelfde probleem.
Ook ik heb het probleem opgelost door het blok later vrij te geven.
Ik heb de bezetmelding bekeken. Het volgende is mij opgevallen.
De schakeling van bezet naar vrij vv (door de wielen van de wagons)gebeurt niet voor elke as.
Als de trein sneller gaat rijden gebeurt het minder vaak.
Ik heb het probleem ook niet met korte treinen.
Met langere treinen wel.
Ik denk dat het volgende gebeurt.
Trein 1 vertrekt uit het blok en geeft het blok meteen vrij.
Trein 2 rijdt het blok binnen.
De bezetmelding van de stopsectie begint te knipperen.
Trein 1 gaat steeds harder rijden.
Als laatste knipper geeft de bezetmelder bezet.
Omdat trein 2 al in het blok aanwezig is ziet koploper de trein in de stopsectie en stopt ergens in het blok (voor de stopsectie).
Oplossing of later vrijgeven door trein 1 of later vertrekken van trein 2. Als er nog een andere oplossing is hoor ik die graag.

Klaas Baas


Reageer op auteur: Wim Ros
Gereageerd: 29 okt 2015 10:40:45
Bericht:

Klaas,

Op de eerste knipper geeft de melder al bezet, en alle latere knippers zijn niet meer van invloed op het gedrag of de werking. Lijkt mij dat je een verkeerde conclusie trekt.
Het later vrijgeven heeft alleen invloed op het blok waar hij vandaan komt. Heeft geen invloed op de stopmelder van het blok waarin hij is.

Mvg
Wim.


Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: Klaas Baas
Gereageerd: 29 okt 2015 10:55:11
Bericht:

Wim,

Het volgende heb ik in de logging gezien.

Trein 1 vertrekt uit het blok en geeft het blok meteen vrij.
Trein 2 rijdt het blok binnen.
De bezetmelding van de stopsectie begint te knipperen.
Trein 1 gaat steeds harder rijden.
Als laatste knipper geeft de bezetmelder bezet.
Omdat trein 2 al in het blok aanwezig is ziet koploper de trein in de stopsectie en stopt ergens in het blok (voor de stopsectie).
Wat is volgens jou de juiste conclusie

Hartelijke groet,

Klaas

Spoor N, Roco multimaus,s88XPressNetLi


Reageer op auteur: Blausee-Mitholz
Gereageerd: 29 okt 2015 11:07:46
Bericht:

quote:
Oorspronkelijk geplaatst door Klaas Baas


Trein 1 vertrekt uit het blok en geeft het blok meteen vrij.
Trein 2 rijdt het blok binnen.

Omdat trein 2 al in het blok aanwezig is ..........


Vooropgesteld ik rij 3-rail dus met massa detectie. Mijn hele blokken zijn gedetecteerd. Met 3-rail is ook de gehele trein gedetecteerd van kop tot staart.

Ik heb bij blok eigenschappen, bezetmeldingen de melders aangevinkt bij "bezet bij"

Daarmee bewerkstellig ik dat er geen enkele trein in een blok kan komen voordat de (voorgaande) gehele trein het blok verlaten heeft.
De (komende) binnenrijdende trein heeft dus een leeg blok voor zich.
(Zo gebeurt het in het echt toch ook .......)

Verder heb ik bij instellingen database -> algemeen-2 -> vertraging bezetmelding vrijgeven op 500 millisec staan. Hier mee voorkom je knipperende bezet melders.

Met deze twee instellingen heb ik dus geen last met de problemen die jullie ondervinden.

DEUVM ....!

Mvg, Johan


Reageer op auteur: hubertus
Gereageerd: 29 okt 2015 11:13:53
Bericht:

Klaas,

Als ik het goed begrijp, rijden er bij jou twee treinen tegelijk in een blok: de staart van de trein die al naar het volgende blok is (maar wel al het vorige blok op de eerste melder heeft vrijgegeven) en de kop van de trein die daar achteraan rijdt. Dan klopt jouw conclusie wel.

Maar dan gaat het dus om te vroeg stoppen van de tweede trein, niet van de eerste trein?

Huub


Reageer op auteur: Klaas Baas
Gereageerd: 29 okt 2015 11:22:57
Bericht:

Huub,

Het gaat inderdaad om het te vroeg stoppen van trein 2.

Bedankt voor je reactie

Klaas


Reageer op auteur: Wim Ros
Gereageerd: 29 okt 2015 11:25:35
Bericht:

Klaas,

Dan rij je dus met treinen die geen volledige detectie hebben, en dan MOET je het blok achter de trein vrijgeven op de laatste melder, anders krijg je het effect wat je beschrijft.
Maar dat is iets anders dan het probleem wat hier aan de orde is.

Mvg
Wim.


Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: Klaas Baas
Gereageerd: 29 okt 2015 12:21:51
Bericht:

Wim,

Bedankt voor je reactie.

Niet alle treinen worden volledig gedetecteerd.
Ik de vrijgave wijzigen.


Hartelijke groet,

Klaas

Spoor N, Roco multimaus,s88XPressNetLi


Reageer op auteur: janspoor
Gereageerd: 29 okt 2015 21:58:59
Bericht:

Geweldig bedankt Klaas! Nu komen we verder en blijkt de "spraakverwarring" dus onder andere te komen door het al dan niet gedetecteerd zijn van de hele trein. Bij mij is de situatie precies zoals jij beschrijft en het gaat dus inderdaad om het feit dat trein 2 soms te vroeg stopt. Het was mij ook al opgevallen dat het gebeurt met relatief lange treinen. De staart van de trein bevindt zich nog in de meldsectie (eerste bezetmelder), maar dat mag geen betekenis hebben. Wel is het zo dat trein 1 nog niet het hele blok heeft verlaten vóórdat trein 2 al de meldsectie (eerste bezetmelder) van datzelfde blok binnenrijdt. Dus was mijn "oplossing" om het blok later vrij te geven (bij de tweede bezetmelder cq de stopsectie) nog niet eens zo'n gek idee. Maar hoe het komt dat het de ene keer wel gebeurt en de andere keer niet met precies dezelfde treinen, snap ik niet. Ik had gedacht de logging simpeler te maken door tijdelijk alleen met twee locs te rijden maar nu snap ik waarom het euvel zich dan niet voordeed. Afijn, ik ben blij dat er in ieder geval iets is uitgekomen en ga verder met experimenteren. Bedankt voor alle reacties. Gr Jan


Reageer op auteur: Wim Ros
Gereageerd: 29 okt 2015 22:44:28
Bericht:

Het gaat dus niet om de trein die het blok binnen rijdt, maar het gaat om de achterop komende trein, en dat is dus een wereld van verschil, en dan is er dus geen sprake van stoppen op de eerste melder, maar te vroeg vertrekken van de tweede trein, die mag helemaal niet vertrekken, immers de voorgaande trein heeft het blok nog niet verlaten. En waarom het de ene keer wel goed gaat en de andere keer niet heeft te maken met het wel of niet generen van een bezetmelding. Maar eigemlijk doet koploper gewoon wat hij moet doen, alleen doet de gebruiker van koploper dat niet. Gewoon standaard vrijgeven van het vorige blok op de laatste melder van het volgende blok, en dan is er nooit een situatie, en werkt alles betrouwbaar.
Het is nu eenmaal geen racebaan en aan bumper kleven hebben we een hekel.

Mvg
Wim.




Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: janspoor
Gereageerd: 29 okt 2015 22:54:24
Bericht:

OK, Wim, dan zijn we er toch uit? Blijkt er al die tijd sprake van een spraakverwarring of misverstand of hoe je het ook noemen wilt. En natuurlijk is Koploper gewoon een computerprogramma dat alleen correct werkt als de input correct is, dat snap ik. En dat geldt natuurlijk ook voor dit forum: als de input niet correct of volledig is, zal de output ook hiaten vertonen. Gelukkig hebben sommige deelnemers aan dit forum engelengeduld en komen we er uiteindelijk toch uit. Dank daarvoor! Dus ik ga als de wiedeweerga het vrijgeven van (een aantal) blokken verzetten van eerste naar laatste melder.

Vriendelijke groet

Jan


Reageer op auteur: janspoor
Gereageerd: 30 okt 2015 11:12:46
Bericht:

In het grootbedrijf is het volgens mij overigens zo dat er altijd een leeg blok zit tussen twee blokken die bezet zijn, maar dat is op een kleinschalige modelbaan, zoals de mijne, nauwelijks haalbaar. Gr Jan


Reageer op auteur: Blausee-Mitholz
Gereageerd: 30 okt 2015 15:13:46
Bericht:

Jan ik schreef al dat een blok leeg moet zijn wil er een trein binnen kunnen rijden.
Met 3 blokken kun je prima rijden met twee treinen. Altijd 1 blok meer maken dan dat je treinen hebt. Gewoon een doorschuif systeem.
Wil je leuker rijden heb je meer lege blokken nodig dan je treinen op de baan hebt.
Ik heb hier in totaal 37 blokken op 19 treinen. Max aantal treinbewegingen tegelijk incl rangeerbeweging is 6.
Soms staat bijna alles stil op 1 na omdat die zo nodig verkeert spoor moet rijden
Dus het ene uiterst naar het andere uiterst.

Mvg, Johan


Reageer op auteur: janspoor
Gereageerd: 30 okt 2015 16:14:19
Bericht:

Inderdaad een doorschuifsysteem. Bij mij rijden 13 treinen in 29 blokken. Het waren er oorspronkelijk 30 maar met het hele probleem zoals hierboven beschreven heb ik er één blok uit gehaald en als het ware toegevoegd aan een wisselstraat omdat het zo kort was dat de meeste treinen er toch een stopverbod hadden. Ja, ik herken het probleem dat er soms 8 of zelfs 9 treinen tegelijk rijden (=bewegen) maar soms staat alles stil omdat er één alles blokkeert. Het blijft leuk om alles uit te vogelen.


Reageer op auteur: Blausee-Mitholz
Gereageerd: 30 okt 2015 17:58:14
Bericht:

De kunst is dat er 1 trein blijft rijden, daarna komt alles weer op gang.
Voorkomen van Deadlock heb ik onder de knie gebracht met logische acties. Werkt nu 100% betrouwbaar.
Treinenverloop is hier te complex om dat alleen met Deadlock functie in de blokken te ondervangen.

Koploper is net schaken ...... zorgen dat je niet mat komt te staan

Mvg, Johan


Reageer op auteur: janspoor
Gereageerd: 30 okt 2015 21:42:56
Bericht:

Deadlock meer patstelling


Reageer op auteur: Wim Ros
Gereageerd: 30 okt 2015 22:11:58
Bericht:

Als je de deadlock optie goed en slim gebruikt is het juist geen patstelling. ;)

Mvg
Wim.


Alleen de waarheid ligt in het midden

s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus


Reageer op auteur: janspoor
Gereageerd: 31 okt 2015 10:50:06
Bericht:

Dat bedoel ik ook: bij "mat" is er geen uitvlucht meer, bij "pat" kun je wellicht nog iets "forceren", in het geval van Koploper door inderdaad de mogelijkheden om deadlock te voorkomen te benutten. Toch werkt dat niet altijd zoals ik zou willen: zo geef ik aan dat een trein pas van blok 17 naar blok 29 mag rijden als blokken 13 en 30 beide niet bezet zijn. Dat gebeurt ook netjes, maar in de "verplichte" stilstandtijd in blok 29 kunnen treinen in tegenovergestelde richting toch blokken 13 en 30 gaan bezetten en zo een deadlock veroorzaken. Vr groet, Jan

Download Attachment: blokken-84.bck
264,83 KB


Reageer op auteur: Ben
Gereageerd: 31 okt 2015 11:23:03
Bericht:

Heb even meegekeken maar jij begrijpt het begrip "deadlock" nog niet goed.
De trein kan nog altijd naar 28.

Gr, Ben.


Reageer op auteur: Blausee-Mitholz
Gereageerd: 31 okt 2015 11:31:35
Bericht:

Pat is in dit geval ook mat.
Als jij moet gaan forceren grijp je al in dus heb je verloren en begint het spel opnieuw

Ik heb je baanplan niet bekeken maar als ik zo lees is de trein onderweg maar stop even. In die stoptijd wordt het bedoeld eindblok 13 of 30 door een andere trein bezet.
Als blok 29 bezet is door een bepaalde trein kun jij met logische actie afdwingen dat geen andere trein naar 13 of 30 rijdt.

Alleen met logische acties moet je wel goed weten wat je doen anders sta je meteen mat

Mvg, Johan


Reageer op auteur: janspoor
Gereageerd: 31 okt 2015 12:41:32
Bericht:

Beste Ben. Dank voor je reactie. Maak ik dan een denkfout als ik zeg "als de trein naar 29 wil gaan, moeten blokken 13 en 30 beide vrij zijn"? Ik weet dat de trein theoretisch ook naar 28 kan, maar dan is er geen probleem omdat de trein dan altijd naar blok 6 kan (eenrichtingverkeer). Het gaat dus specifiek om het voorkomen van een deadlock op blokken 13 en 30 als de trein van 17 naar 29 rijdt. Gr Jan


Reageer op auteur: KdeB
Gereageerd: 31 okt 2015 12:43:15
Bericht:

quote:
Oorspronkelijk geplaatst door janspoor

zo geef ik aan dat een trein pas van blok 17 naar blok 29 mag rijden als blokken 13 en 30 beide niet bezet zijn



Waarom moet blok 13 en 30 beide vrij zijn?
Het is zoals Johan al zegt je kan dit alleen oplossen met logische actie in je variabele routes oplossen.

Mvg
Koos

Met vriendelijke groeten
Koos de Bruin

Het wordt vanzelf weer kerstmis.
Marklin, Ecos2, Koploper, Crail, Windows XP.


Reageer op auteur: janspoor
Gereageerd: 31 okt 2015 12:43:29
Bericht:

Beste Johan. Leuk woordspel zo. Maar je hebt wel gelijk .... . Ik heb al eens naar het hoofdstuk "Logische acties" zitten kijken maar kan het nog niet helemaal bevatten, dwz wel de theorie maar hoe eea in praktijk te brengen is me nog niet duidelijk. Ik ga verder met de "studie". Bedankt voor je reactie. Gr Jan


Reageer op auteur: janspoor
Gereageerd: 31 okt 2015 13:13:33
Bericht:

Beste Johan. Het blijft een leuk (woord)spel. Maar je hebt gelijk, als het echt stil staat is het mat. Ik heb even naar het hoofdstuk "Logische acties" gekeken en hoewel ik de theorie wel begrijp, zie ik nog niet helemaal hoe ik een en ander zou kunnen toepassen op mijn database, maar we studeren gewoon verder. Vr groet, Jan


Reageer op auteur: janspoor
Gereageerd: 31 okt 2015 13:16:02
Bericht:

Beste Koos. Aanvankelijk had ik gekozen voor de optie "een van beide sporen 13 of 30" maar daar trokken treinen in tegenovergestelde richting zich niks van aan. Naar nu blijkt werkt het ook niet met de optie "beide sporen vrij". Dus wellicht moet ik toch naar "logische acties", maar .... zie antwoord aan Johan hierboven. Vr groet, Jan


Reageer op auteur: Ben
Gereageerd: 31 okt 2015 14:00:32
Bericht:

Een zetje in de richting.

Je kunt een logische actie maken met "Blok is bezet komend uit blok". Verderop geeft je aan: 17 > 29.

Dit betekent dat de logische actie "waar" is als in 29 een trein staat die uit 17 komt.

Je kunt nu een variabele route maken op basis van die logische actie die bijvoorbeeld bepaalde treinen niet naar bepaalde blokken laat vertrekken waardoor de trein in 29 vast komt te staan. Die route geldt dan alleen ALS de logische actie "waar" is.

Gr, Ben.


Reageer op auteur: KdeB
Gereageerd: 31 okt 2015 14:24:08
Bericht:

Wilde net een aangepaste DB plaatsen zie ik dat Ben het al heeft verwoord, toch bij deze, misschien wordt het wat duidelijker.
Heb jouw DB aangepast met logische actie en variabele route, 2 test treinen aangemaakt om geen last te hebben van andere variabele routes.
test trein1 staat in blok 29 komend uit blok 17
plaats testtrein2 in bv blok 19 en zal nooit naar blok 13 of 30 gaan wanneer in blok 29 een trein staat uit blok 17
Kijk bij de variabele route tabblad 'Richtingsverbod bv. 7->13(uit:18)
Koploper moet weten waar een trein vandaan komt (uit:18)
succes

Mvg
Koos

oh ja, je moet wel de versie 8.7 downloaden

Download Attachment: blokkenjanspoor.bck
266,13 KB

Met vriendelijke groeten
Koos de Bruin

Het wordt vanzelf weer kerstmis.
Marklin, Ecos2, Koploper, Crail, Windows XP.


Reageer op auteur: Ben
Gereageerd: 31 okt 2015 15:47:44
Bericht:

Heel goed Koos.


Reageer op auteur: janspoor
Gereageerd: 31 okt 2015 21:54:02
Bericht:

Dank Ben en Koos. Ik heb er net even naar gekeken, maar dat moet ik nog eens op mijn gemak doen en tot me laten doordringen. Ik houd jullie op de hoogte van mijn studievorderingen (if any ....). Vr groet, Jan


Reageer op auteur: janspoor
Gereageerd: 02 nov 2015 10:10:11
Bericht:

Beste Koos en Ben: Het is me duidelijk. Ik moest voor mezelf even duidelijk krijgen dat wat in computertaal "if ... then" heet, nu betekent if="logische actie aanmaken" en then=toepassen in "variabele treinroute". Zoals je in mijn database hebt kunnen zien bestonden mijn variabele treinroutes tot nu toe uitsluitend uit het vernoemen van het soort treinen dat er rijdt, maar ik zie dat ik op deze manier nog wat meer "variatie" kan aanbrengen. Zo wil ik graag dat personentreinen te allen tijde voorrang hebben op goederentreinen voor zover dat mogelijk is zonder dat daardoor alles stil komt te staan. Ik dank jullie nogmaals hartelijk voor jullie hulp. Vr groet, Jan


Reageer op auteur: KdeB
Gereageerd: 02 nov 2015 10:54:19
Bericht:

Jan

Voorrang van treinen regel je in de 'Voorrangsregeling' en niet met treinroutes en of logische acties.

Gr
Koos

Met vriendelijke groeten
Koos de Bruin

Het wordt vanzelf weer kerstmis.
Marklin, Ecos2, Koploper, Crail, Windows XP.


Reageer op auteur: janspoor
Gereageerd: 22 nov 2015 13:03:11
Bericht:

Inmiddels de logische actie zoals door jullie gegenereerd diverse keren in testmodus geprobeerd en dat gaat goed. Het is alleen wel zo dat als blokken 13 en 30 al bezet zijn als er vanuit blok 17 een trein naar blok 29 rijdt, deze logische actie niet werkt. Het werd tijd om zelf eens iets te proberen maar het lukt me niet: ik wil graag dat als olietrein (dubbeltractie BR218) in blok 22 komt, dat blok 1 vrij blijft uit tegenovergestelde richting, dus vanuit blok 27. Ik heb daartoe alle opties uitgeprobeerd vanaf loc staat stil tot loc rijdt van naar, en dan in variabele routes opgenomen dat er dan een rcihtingsverbod is voor treinen vanuit 28/29 via 27 naar 1, maar de testtrein "kachelt" vrolijk de verboden zone in. Om te voorkomen dat deze kan uitwijken naar 17-23-34-25-26 heb ik deze even handmatig geblokkeerd. Ik begrijp het kennelijk nog niet goed genoeg. HELP!!

Download Attachment: 20151031142230testlogischeactie.bck
256,6 KB


Reageer op auteur: janspoor
Gereageerd: 22 nov 2015 13:26:21
Bericht:

Hallo Koos en Ben (en anderen): ik ben even een nieuw draadje begonnen (Logische actie) omdat het niet echt meer met het probleem "onverklaarbare stop" te maken heeft.

Spoor N, Fleischmann Piccolo, Minitrix, Arnold, Roco, ECoS 2, RoSoft


Koploperforum Digitale Treinbesturing : http://www.koploperforum.nl/

© EKweb 2006

Sluit venster