Koploperforum Digitale Treinbesturing Aktieve Gebruikers: 134 / Bezoekers Vandaag: 3273
Hoogste aantal aktieve gebruikers: 134
Google


Koploperforum Digitale Treinbesturing
Startpagina | Mijn bestanden | Profiel | Registreer | Recente onderwerpen | Leden | Zoeken | FAQ
Gebruikersnaam:
Wachtwoord:
Selecteer taal
Wachtwoord opslaan
Wachtwoord vergeten?

Modelspoorwijzer.net

 Alle forums
 Koploper
 Beginners
 Treinen blijven soms staan op eerste melder van blok.
 Nieuw onderwerp  Reageer op onderwerp
 Printversie
Volgende pagina
Auteur Vorig onderwerp Onderwerp Volgend onderwerp Pagina: 1 2 (of 2)

Martijn1974

Netherlands
61 berichten

Geplaatst - 21 sep 2015 :  17:50:56  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
Hallo,

Ik heb een beetje vreemd fenomeen op mijn baan, het gebeurt namelijk af en toe dat treinen bovenop de eerste melder van een blok stoppen. Alsof ze al in het blok staan.
Ik krijg geen meldingen van stilstaande treinen of zo.
Er komen gelukkig geen ongelukken van omdat de achterkant van de trein nog wel gedetecteerd wordt, maar het houdt de rest wel op omdat wisselstraten of voorgaande blokken bezet blijven.

Het is voorgekomen bij het rijden vanuit blok-32 naar blok-5, waarbij de loc stopt op detectiepunt 1.09 (begin blok-5) en dus blok-32 onnodig bezet houdt.

En bij het rijden van blok-5 naar blok-6, de loc stopt dan op detectiepunt 1.11 (begin blok-6) en dus onnodig blok 5 bezet houdt.


Blokken 5 en 6 zijn voor variabele treinroute 'Lang goederenvervoer', getrokken door de NS1637 en 653-05 MRCE.

Dit gebeurt niet consequent elke keer. Slechts af en toe.
Ik heb nog niet kunnen vinden waar dit door veroorzaakt wordt.
Heeft iemand een idee waar het in zit?

mvg,
Martijn.




Download Attachment: hanulveen.bck
190,68 KB

NS | H0 | DCC | ECoS-2 | Koploper v8.6 |

henk-de-boer

Netherlands
6 Posts

Geplaatst - 30 sep 2015 :  19:36:40  Toon profiel  Reageer met citaat
Hallo Martijn,

Bij mij gebeurt het wel eens dat ik een onterechte bezetmelding krijg omdat een isolatie niet goed is tussen twee secties.

Ook zou je nog even kunnen controleren als de trein te vroeg stopt wat de eerstvolgende bezetmelder is die hij verwacht (onderin de statusregel van je rijwindow)

Henk
Ga naar bovenaan de pagina

Martijn1974

Netherlands
61 Posts

Geplaatst - 01 okt 2015 :  06:49:13  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
Dankjewel voor de aanwijzingen.
Ik zal beide zaken binnenkort even controleren.

mvg,
Martijn.

NS | H0 | DCC | ECoS-2 | Koploper v8.6 |
Ga naar bovenaan de pagina

carel richters

Netherlands
291 Posts

Geplaatst - 01 okt 2015 :  11:05:00  Toon profiel  Reageer met citaat
Hallo Martijn,
Ik heb zelfs vrij regelmatig last van het probleem, waarvan ook jij last hebt en er is niets met de isolatie tussen twee secties aan de hand. Sterker nog als ik gebruik maak van een melder, die er tussen ligt, verplaatst het probleem zich na die tussenliggende melder en als ik vervolgens gebruikmaak van nog een tweede tussen liggende melder, dan stopt en keert een loc na die melder. Gebeurde het eerst af en toe, nu gebeurt het konsekwent in een blok.Dus een loc stopt konsekwent op de voorlaatste melder. Dat er geen problemen zijn met de isolatie blijkt ook uit het feit als een loc in de andere richting rijdtt, dan treedt het probleem niet op. Als er iets met de isolatie aan de hand zou zijn, zou er ook een probleem met die stopmelder in de andere richting moeten zijn en dat is niet het geval. Bovendien heb ik uitgebreid gekeken, of er iets met de isolatie aan de hand is, maar kan niets ontdekken. Als dat het geval zou zijn, moet ik voor of na de stopmelder op het voor af achter de stopmelder gelegen stuk rail een bezetmelding van die stopmelder in KL krijgen, als er een loc of rijtuig op een van die stukken rail staat, en dat is niet zo.

Ik heb van de nood een deugd gemaakt, toen ik merkte, dat er konsekwent op de voorlaatste melder werd gestopt (en in mijn geval ook gekeerd). Ik heb tussen de begin- en stopmelder een virtuele melder gezet en precies de afstand tussen de begin- en stopmelder opgemeten en deze afstand in de virtuele melder gezet. Het resultaat: de loc stopt en keert net na de stopmelder ( dus eigenlijk aan het eind van de opgegeven afstand in de virtuele melder). Het doel was een stel wachtende rijtuigen aan te koppelen en in omgekeerde richting weg te rijden. Dat lukt nu weer prima.

Deze oplossing lost het probleem niet op, dat weet ik ook wel. De Duitsers noemen dit zo mooi: "Kurieren am Symptom". De oorzaak weet ik echter niet. Ik weet wel, dat dit soort problemen meer optreedt in KL en dat je er een hoop tijd aan kwijt bent om het probleem te vinden en een andere oplossing te zoeken en te vinden. Ik kan er nog bij vermelden, dat in dezelfde route nog drie blokken zitten, waar een loc moet stoppen en keren en dat het daar steeds goed gaat, terwijl ik alle blokken precies hetzelfde heb ingericht. Verder gaat het in de testmode ook steeds goed. Daar wordt in alle vier de blokken op de juiste plaats gestopt en gekeerd. Alleen in de werkelijkheid treedt het probleem op. Dat zou kunnen wijzen op een isolatie probleem, maar nogmaals, ik kan dat niet vinden.

Ik weet niet, of er meer mensen, zijn, die van dit soort onverklaarbare problemen last hebben. Misschien heeft iemand de echte oplossing gevonden. Mijn oplossing werkt, maar neemt het probleem niet weg.

Mvrgr
Carel
Ga naar bovenaan de pagina

gardevil

Belgium
19 Posts

Geplaatst - 01 okt 2015 :  11:45:24  Toon profiel  Bezoek de homepagina van gardevil  Reageer met citaat
Hallo,

ook ik heb regelmatig last van dit probleem en heb voorlopig nog geen oplossing gevonden.
Het rare is dat in blok waar hij nu op de eerste melder stopt, dit vroeger wel perfect liep en stopte op de tweede melder, zonder dat er structurele meldingen zijn gebeurt aan de baan.

Ik ga wel het verhaal van de virtuele melder eens uitproberen, dat geeft misschien al een oplossing voor het symptoom, maar helaas niet voor de ziekte.

Als liefde blind is, waarom is lingerie dan zo belangrijk?
Ga naar bovenaan de pagina

hubertus

Netherlands
1161 Posts

Geplaatst - 01 okt 2015 :  11:51:35  Toon profiel  Reageer met citaat
Geen oplossing, maar wel iets waarmee je de oorzaak makkelijker kunt achterhalen.
Laat de communicatielogging meelopen en kijk daar wat er gebeurt op het moment dat het verkeerd gaat. Dan kun je veel gerichter zoeken naar het probleem.
Koploper is niet onfeilbaar, maar dit soort dingen is toch vrijwel altijd een fout in de baan of iets in de instellingen in koploper.

Huub
Ga naar bovenaan de pagina

dentheo

Belgium
1547 Posts

Geplaatst - 01 okt 2015 :  14:17:59  Toon profiel  Reageer met citaat
quote:
Oorspronkelijk geplaatst door gardevil

Hallo,

ook ik heb regelmatig last van dit probleem en heb voorlopig nog geen oplossing gevonden.
Het rare is dat in blok waar hij nu op de eerste melder stopt, dit vroeger wel perfect liep en stopte op de tweede melder, zonder dat er structurele meldingen zijn gebeurt aan de baan.




Ik weet niet of jij alle zaagsnedes mooi hebt dichtgepleisterd met epoxylijm ofzo. Indien niet, gebruik dan even je vingernagel om de zaagsnede vrij te maken. Onder temperatuurinvloeden willen rails wel eens een mm verschuiven in hun bedding (net zoals in het echt op 1/1).
Daarna heb je ineens terug twee bezetmelders ipv één lange...

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

Bewerkt door dentheo op 01 okt 2015 20:24:31
Ga naar bovenaan de pagina

gardevil

Belgium
19 Posts

Geplaatst - 01 okt 2015 :  20:08:39  Toon profiel  Bezoek de homepagina van gardevil  Reageer met citaat
Hoi Theo,

zal ik aan denken wanneer ik nog eens op zolder kom. Lijkt me logisch maar wordt zo makkelijk over het hoofd gezien.

Als liefde blind is, waarom is lingerie dan zo belangrijk?
Ga naar bovenaan de pagina

carel richters

Netherlands
291 Posts

Geplaatst - 01 okt 2015 :  20:35:36  Toon profiel  Reageer met citaat
Ja Theo, ik heb al mijn zaagsneden netjes met lijm dicht gesmeerd, dus daar kan het niet aan liggen en zoals geschreven in tegengestelde richting treedt het probleem niet op, noch in de drie overige blokken, waarin precies hetzelfde moet gebeuren. Maar als het rechtsom niet lukt, dan doe ik het linksom en dan lukt het wel, maar vreemd, vind ik het wel.

Mvrgr
Carel
Ga naar bovenaan de pagina

hubertus

Netherlands
1161 Posts

Geplaatst - 01 okt 2015 :  21:43:00  Toon profiel  Reageer met citaat
Carel,

Als ik jouw verhaal lees, is mijn eerste gedachte dat je een vaste route hebt die actief is.
Maar nogmaals, laat de communicatielogging meelopen om te kijken wat er precies gebeurt en ga aan de hand daarvan gestructureerd op zoek naar de oorzaak. Het heeft nooit veel zin om in het wilde weg dingen te proberen en oplossingen te bedenken, als je niet weet waar de oorzaak ligt. Die virtuele melder oplossing werkt natuurlijk heel leuk, maar het wordt daarmee nog lastiger het probleem te achterhalen.

Huub
Ga naar bovenaan de pagina

Martijn1974

Netherlands
61 Posts

Geplaatst - 02 okt 2015 :  07:08:39  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
Huub,

Bij zitten de blokken waar het om gaat inderdaad in een vaste route.
Het zijn ook de treinen die aktief die route volgen die af-en-toe op de eerste melder blijven staan, dus niet consequent.

Misschien leidt dit iets meer naar de oplossing.
Mijn rail overgangen zijn doormiddel van kunsstof raillasjes met een vertikaal schotje tussen de staven.

mvg,
Martijn.

NS | H0 | DCC | ECoS-2 | Koploper v8.6 |
Ga naar bovenaan de pagina

j.kos2

Netherlands
30 Posts

Geplaatst - 02 okt 2015 :  10:16:29  Toon profiel  Reageer met citaat
Echt, Huub heeft het al twee keer geadviseerd, kijk naar de logging, die vertelt je wat er gebeurd, van welke bezetmelders actief worden tot en met de eventuele andere acties die uitgevoerd worden. Anders blijft het raden. Zelf heb ik ook op die manier op het oog onverklaarbare zaken eenvoudig kunnen herleiden.
Als je zeker weet dat de isolaties in orde zijn, is dat de beste en snelste, en vooral eenvoudigste methode,

Mvrgrt,

Jan
Ga naar bovenaan de pagina

carel richters

Netherlands
291 Posts

Geplaatst - 02 okt 2015 :  14:12:14  Toon profiel  Reageer met citaat
Nadat de loc de hele week konsekwent na de binnenkomstmelder was gestopt ipv de stopmelder behalve als ik, zoals beschreven er een vituele melder had tussengeplaatst met de afstand tussen de 1e melder en de stopmelder, reed de loc vandaag door naar de stopmelder, stopte daar en keerde. Vanzelsprekend nadat ik de oude instellingen had teruggezet. Op de communicatielogging was dan ook niets bijzonders te zien.

Als iemand hier iets van maken kan, hoor ik het graag, maar ik ervaar het als onbetrouwbaar, zoals ik wel meer dingen als onbetrouwbaar ervaar. Voorbeelden: in dezelfde vaste route werd een wissel niet omgezet, waardoor de loc op een heel ander spoor uitkwam, dan bedoeld en dus ook niet deed wat hij doen moest: stoppen, ontkoppelen en weer doorijden; in een andere vaste route, die gelijktijdig wordt gebruikt, reed een loc op de draaischijf ineens 10 cm door ipv de opgegeven 1,5 cm.

Nagenoeg alle wissels worden vanuit de centrale rechtstreeks van stroom voorzien om spanningsverlies en daarmee slecht schakelen en beschadiging van de decoders te voorkomen (door ervaring wijzer geworden!). Dus daar kan het niet aan liggen. Aan de instellingen van de draaischijf kan het ook niet liggen, die zijn niet veranderd. De volgende keer ging het ook weer goed. Idem met die wissel. Maar als het de ene keer goed gaat en de andere keer niet, noem ik dat onbetrouwbaar. Of het dan aan KL ligt of ergens anders aan, weet ik niet. Ik kan blijven zoeken en communicatieloggings aanzetten en bekijken, maar a. het kost een hoop tijd, die ik graag ergens anders aan zou besteden en b. blijkt, dat als ik iets wil vaststellen er niets is vast te stellen, want dan gaat het goed, maar gaat iets anders, waarop ik in het geheel niet reken, fout en dat heb ik dan net niet ingesteld en heb ik het ingesteld, dan treedt het weer niet op.

Ik kan 101 dingen bedenken, waardoor het fout kan gaan. Tegen 97 dingen heb ik maatregelen genomen, zoals betrouwbare stroom voorziening, goede isolatie, waar nodig, bedrijfszekere contacten, goed functionerende decoders enz. maar een aantal dingen heb ik niet in de hand, de juiste werking van de computer, centrale, wissels (bekend is, dat Marklin aandrijvingen niet altijd betrouwbaar zijn) en KL. Wat die wissel betreft: ik zag, dat KL de rijweg juist had gezet, maar dat zegt natuurlijk niets over het werkelijk geven van het commando, de werking van centrale en computer en het uitvoeren van de opdracht door de wisselaandrijving en zelfs ook niet van de decoder, want ook bij goed functioneren kan het een keer voorkomen, dat hij weigeren.

Om het allemaal nog wat eenvoudiger te maken, toen ik constateerde, dat een loc in zijn vaste route, steeds na de beginmelder keerde, heb ik achtereenvolgens de tussenliggende melders als 2e, 3e en zelfs 4e melder ingesteld. Wat bleek, dat de loc telkens stopte na de 2e, 3e of 4e melder, dus steeds de melder voor de stopmelder. In feite was dat ook wat er gebeurde met de virtuele melder. Dat was de 2e melder tussen de begin- en stopmelder en dus ook de laatste melder voor de stopmelder. Misschien geeft dat enige duidelijkheid. Alleen ik weet niet, wat ik er mee moet beginnen, zeker niet nu de oorspronkelijke instelling plotseling weer goed functioneert.

Het was een heel verhaal, maar wel wat er bij mij aan de hand was/is.

Mvrgr
Carel
Ga naar bovenaan de pagina

phdirk

Netherlands
1762 Posts

Geplaatst - 02 okt 2015 :  14:55:31  Toon profiel  Reageer met citaat
Hallo Carel en Martijn,

In vaste routes kun je, als je in een blok wilt stoppen, opgeven op welke bezetmelder dat moet gebeuren om zo aan- en afkoppelen mogelijk te maken. Misschien zit wat jullie constateren in die hoek. Ik zou eens goed naar het stopgedrag in de vaste routes kijken.


Met beste groeten
Dirk
HO=TC
Ga naar bovenaan de pagina

carel richters

Netherlands
291 Posts

Geplaatst - 02 okt 2015 :  23:14:12  Toon profiel  Reageer met citaat
Hallo Dirk,
Fijn, dat je ons wilt helpen, maar helaas het zet geen zoden aan de dijk:
a. het is een onregelmatig optredend probleem;
b. ga er maar van uit, dat wij weten hoe wij KL op dit punt moeten inrichten, althans ik ben geen beginner;
c. en dat wij maatregelen hebben genomen, die ongewenste verbindingen uitsluiten.

Er is iets aan de hand, dat dit probleem veroorzaakt, waar meerdere mensen kennelijk last van hebben, zonder dat er een duidelijk aanwijsbare reden voor aanwezig is.

Zoals geschreven: ik kan er om heen werken, maar dat lost het probleem niet op.
Overigens heb ik vanmiddag de oude instellingen hersteld en er was niets aan de hand: een perfecte rit, het stoppen en keren gebeurde op de juiste plaats en het juiste moment.
Ik begin me af te vragen, of het opnieuw inbrengen van de oude instellingen niet zoiets is als resetten. Ik heb geen enkele verklaring voor het feit, dat het nu weer wel goed gaat, gisteren niet en morgen misschien weer niet of wel.

Met deze onzekerheid zal ik het voorlopig moeten doen.

Mvrgr
Carel

Ga naar bovenaan de pagina

hubertus

Netherlands
1161 Posts

Geplaatst - 03 okt 2015 :  10:00:01  Toon profiel  Reageer met citaat
Carel,

quote:
Nadat de loc de hele week konsekwent na de binnenkomstmelder was gestopt ipv de stopmelder behalve als ik, zoals beschreven er een vituele melder had tussengeplaatst met de afstand tussen de 1e melder en de stopmelder, reed de loc vandaag door naar de stopmelder, stopte daar en keerde. Vanzelsprekend nadat ik de oude instellingen had teruggezet. Op de communicatielogging was dan ook niets bijzonders te zien.

Wat liet de communicatielogging zien als het niet goed ging, waar zit het verschil?
Als het probleem in Koploper zit, is de kans groot dat er een trigger is die dat probleem veroorzaakt en op een of andere manier zichtbaar is in de logging.

Ik herken het probleem helemaal niet van mijn eigen baan. Zover er bij mij wel eens iets anders gebeurt, dan zou moeten, heb ik dat altijd terug kunnen leiden naar een verkeerde instelling door mijzelf of was het reproduceerbaar. Dus dan komt de vraag op, hoe kan het dat jij er regelmatig last van heb en ik niet?
Ik heb een oude database van je (zwiep6 van dec 2014) erbij gepakt om eens te vergelijken of je soms functionaliteiten gebruikt die ik niet gebruik. Maar daar kan ik niks van vinden, dus onwaarschijnlijk dat het daarin zit.
Qua instellingen zitten er wel wat verschillen, maar geen die op het eerste gezicht aan dit probleem te relateren zijn.
Het enige echte verschil wat ik eigenlijk zie, is dat jij (en Martijn ook) met een ecos rijdt en ik met een intellibox.
En dan houdt het voor mij ook op, want ik ken de ecos niet (en wil dat ook graag zo houden ).
Maar het is wel de hoek waar ik als eerste zou gaan zoeken.

groet, Huub

Bewerkt door hubertus op 03 okt 2015 10:01:02
Ga naar bovenaan de pagina

carel richters

Netherlands
291 Posts

Geplaatst - 03 okt 2015 :  11:17:32  Toon profiel  Reageer met citaat
Hallo Huub,
Mijn conclusie, dat het opnieuw inbrengen van de oude instellingen, mij doet denken aan resetten, slaat eigenlijk op de Ecos, want ik heb meerdere keren gemerkt, dat ik die moet resetten om bepaalde problemen op te lossen. Zo herkent deze soms een mfx loc niet of staat een loc soms plotseling stil zonder aanwijsbare reden. Het opnieuw opstarten lost het probleem op. Mogelijk heeft het opnieuw instellen van de oude instellingen hetzelfde resultaat. De tijd zal het leren.

De communicatielogging maakt mij niet veel wijzer, omdat ik deze niet had mee laten lopen toen het voortdurend fout ging en toen ik hem mee liet lopen nadat ik de oude instellingen terug had gezet, juist om te kijken, wat deze zou aangeven, ging het goed. Dus daar word ik niet wijzer van en verschillen kan ik ook niet aangeven.

Maar bedankt voor het meedenken. Overigens ik weet niet meer van wanneer die oude database dateert. Waarschijnlijk staat daarin ook de vaste route Demo Rangeerlocs pendelen. In blok 109 ging het fout. Kijk ook eens naar de instellingen in het Menu Blokken van blok 8 de bezetmeldingen komend uit blok 109. Als die route erin staat, dan moeten de instellingen nog overeenkomen met de huidige instellingen. Alleen het aanvinken van de bezetmeldingen in het Menu Blokken kan daarin niet helemaal correct zijn, maar dat is inmiddels hersteld.

Bij voorbaat dank en mvrgr
Carel
Ga naar bovenaan de pagina

Martijn1974

Netherlands
61 Posts

Geplaatst - 07 feb 2016 :  12:13:47  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
Ik heb diverse dingen geprobeerd maar het probleem blijft bestaan...

Ik schets het hier even:

Trein-2 gaat van blok 2 naar 3.



Zodra de eerste melder van blok-3 wordt geactiveerd wil hij het vorige blok vrijgeven. Blok-2 wordt groen (knippert tussendoor blauw naar gelang detectie op de wagens)


Na de 'staartblokkade' wordt het blok-2 geclaimd door trein-1, die dat blok vervolgens inrijd over de eerste melder. Trein-2 is nog niet volledig uit blok-2.


Doordat de achterste wagen van trein-2 de laatste melder tiggert van blok-2 (Koploper denkt dan dat dat de voorkant van trein-1 is)en dus stopt trein-1 op de eerste melder. Waarbij deze blok-1 bezet houdt.


Dit probleem doet zich nagenoeg alleen voor bij achter elkaar aan rijdende treinen. Vanuit stilstand bijna nooit vanwege de vertrek- en optrekvertragingen.

Nou ben ik er achter dat zodra er even geen detectie is op de laatste melder van een blok, deze direct wordt vrijgegeven voor de volgende trein.
Mijn 'staartblokkade' staat op 2 seconden.
De 'vertraging vrijgeven bezetmelding' staat op 500 milliseconden. Moet ik die hoger zetten?
'Vorig blok vrijgeven obv treinlengte' staat overal aangevinkt.

Ik heb lange inrij en stop detectiesecties (40cm) dus die zijn niet te kort.
Mijn 4-assige goederenwagens hebben om de wagen detectie, en mijn 2-assige goederen wagen om de twee wagens.
Zo is er eigenlijk altijd detectie op een sectie.
Ik ben een beetje huiverig om onder elke wagen detectie (10K weerstand) te plaatsen...bang om de centrale te belasten met bijna kortsluiting..of maakt dat niet uit?

Het stoppen op de eerste melder doet zich bij allerlei treinen voor, van lange goedrentrein tot plan-V.
Niet consequent, niet altijd het zelfde blok.



mvg,
Martijn.






NS | H0 | DCC | ECoS-2 | Koploper v8.6 |
Ga naar bovenaan de pagina

dentheo

Belgium
1547 Posts

Geplaatst - 07 feb 2016 :  12:40:59  Toon profiel  Reageer met citaat
quote:
Oorspronkelijk geplaatst door Martijn1974


Zo is er eigenlijk altijd detectie op een sectie.



Dat is duidelijk niet waar.
Anders zou de volgende trein niet vertrekken.
Ik zou twee dingen doen
1)vertraging vrijgeven van 500 op 1000ms zetten
2)detectie van de wagens nakijken. Ik weet niet hoe je de detectie gemaakt hebt, maar geleidbaarheid van lak verandert wel eens (vocht ?) en vervuiling van wieltjes helpt ook niet.

Theo vanop de heide.
N+SX+kpl+kplRsd
Ga naar bovenaan de pagina

hubertus

Netherlands
1161 Posts

Geplaatst - 07 feb 2016 :  13:07:13  Toon profiel  Reageer met citaat
Als je het vorige blok vrijgeeft op de tweede melder ipv de eerste, is je probleem toch opgelost of mis ik iets?

Huub
Ga naar bovenaan de pagina

Martijn1974

Netherlands
61 Posts

Geplaatst - 07 feb 2016 :  13:11:40  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
Ja, kennelijk vallen er gaten in de detectie.
Ik heb het op twee manieren gedaan;
http://hanulveen.nl/ombouwen/detectie-2-asser/detectie-2.html
en
http://hanulveen.nl/ombouwen/detectie-4-asser/detectie-4.html.

Kan je elke wagen voorzien van 10K weerstand? Of is dat teveel voor de centrale?

Ik zal de SMD weerstanden die op de enkele assen zitten eens nameten.
De wielen zijn schoon, dat heb ik recentelijk gecontroleerd.

Ik zal ook de vrijgavetijd aanpassen.


mvg,
Martijn.

NS | H0 | DCC | ECoS-2 | Koploper v8.6 |
Ga naar bovenaan de pagina

Martijn1974

Netherlands
61 Posts

Geplaatst - 07 feb 2016 :  13:27:49  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
quote:
Oorspronkelijk geplaatst door hubertus

Als je het vorige blok vrijgeeft op de tweede melder ipv de eerste, is je probleem toch opgelost of mis ik iets?


Ik heb twee hele lange goederentreinen, die niet geheel in alle blokken passen...levert dat geen problemen op dan bij vrijgeven op de tweede melder? De trein staat dan daadwerkelijk ook nog in het vorige blok.

mvg,
Martijn.

NS | H0 | DCC | ECoS-2 | Koploper v8.6 |
Ga naar bovenaan de pagina

hubertus

Netherlands
1161 Posts

Geplaatst - 07 feb 2016 :  14:19:04  Toon profiel  Reageer met citaat
Als je de treinlengtes en bloklengtes goed invoert in Koploper en bij aanvulling blokgegevens aangeeft dat bij een te lange trein het vorige blok bezet moet worden gehouden, levert dat geen probleem op.

Als ik naar je database kijk, zie nergens detectie van de wisselstraten en ik denk dat ook je blokken zelf niet volledig gedetecteerd zijn.
Je treinen zijn zoals je zelf aangeeft ook niet volledig gedetecteerd.
Dus je probeert gebruik te maken van de eigenschappen van volledige detectie, terwijl je die volledige detectie niet hebt, tenminste niet betrouwbaar. Dat gaat niet werken.

Huub
Ga naar bovenaan de pagina

janspoor

172 Posts

Geplaatst - 07 feb 2016 :  14:24:53  Toon profiel  Reageer met citaat
Hallo

Precies hetzelfde had (en heb) ik soms ook en ik heb dit toen ook op dit forum bespreekbaar gemaakt. Zie daarvoor bij 15 november 2015 onder "Onverklaarbare stop". Ik weet even niet hoe ik een "link" naar dit onderwerp kan plaatsen maar ongetwijfeld kun je het zo vinden. Misschien zitten in alle reacties nog bruikbare tips. Overigens heb ik het op mijn baan "opgelost" door een kort blok te verwijderen. Groet, Jan

*Zo ge't moakt, zo heddet!*
Ga naar bovenaan de pagina

Martijn1974

Netherlands
61 Posts

Geplaatst - 07 feb 2016 :  15:00:28  Toon profiel  Bezoek de homepagina van Martijn1974  Reageer met citaat
@Huub,

Mijn wissel zijn inderdaad ongedetecteerd.
Ook heb ik in een aantal blokken een ongedetecteerd middeldeel.
Dit is wel vaker toegepast heb ik voor de bouw gelezen.

Ik heb de lengtes van de blokken en treinen juist ingevoerd. En ook de optie van het vorige blok bezethouden staat in elke blok aan.

Ik was mij er niet van bewust op "eigenschappen van volledige detectie" te rijden. Ik dacht te rijden op basis van "Vrijgeven vorige blok o.b.v. treinlegte". Daarbij hoef je toch niet geheel gedetecteerd te zijn?

Maar goed. Inmiddels weet ik dat het geen kwaad (voor de centrale) kan om alle wagens en rijtuigen van detectie te voorzien. Dat ga ik eerst doen.
De wissels gedetecteerd maken kan nog wel, al is dat een klus waar ik liever mee wacht tot het laatst.

@Jan,
Ik ga je draadje even teruglezen.

mvg,
Martijn.




NS | H0 | DCC | ECoS-2 | Koploper v8.6 |
Ga naar bovenaan de pagina

hubertus

Netherlands
1161 Posts

Geplaatst - 07 feb 2016 :  15:13:56  Toon profiel  Reageer met citaat
Maar wat denk je te bereiken met het volledig van detectie voorzien van je wagens en rijtuigen? Je zult dan minimaal ook je wisselstraten van bezetmelders moeten voorzien, anders heeft dat niet veel zin.
Gewoon goede trein- en bloklengte invoeren in koploper en aangeven dat op de tweede melder (beter gezegd, de eerste melder die de trein tegenkomt waarbij de hele trein in het blok staat, op jouw baan zal dat meestal de tweede melder zijn) het vorige blok moet worden vrijgegeven.
En aangeven dat bij een te lange trein het vorige blok bezet moet worden gehouden. Dan werkt het keurig zonder dat je iets aan je wagens of rijtuigen hoeft te doen.

"Vrijgave vorige blok o.b.v. treinlengte" is trouwens om bij een korte trein het vorige blok eerder vrij te geven. Je kunt er de vrijgave niet mee uitstellen.

Groet, Huub

Bewerkt door hubertus op 07 feb 2016 15:51:28
Ga naar bovenaan de pagina
Pagina: 1 2 (of 2) Vorig onderwerp Onderwerp Volgend onderwerp  
Volgende pagina
 Nieuw onderwerp  Reageer op onderwerp
 Printversie
Ga naar:
Koploperforum Digitale Treinbesturing Problemen bij het forum? Stuur een email. Conrad
Bestel hier en steun het forum!
© EKweb 2006
Ga naar begin van deze pagina