| Auteur |
 Onderwerp  |
Pagina: 1 2 (of 2) |
|
phdirk
Netherlands
2556 Posts |
 Geplaatst - 11 dec 2013 : 16:07:04
|
Hallo Carel,
Je zet de kwestie wel lekker dik aan  .
Het is natuurlijk lastig om zo op afstand na te gaan wat er exact aan de hand is.
Ik zou toch eens de belasting van je PC monitoren en ook de belasting in Koploper via [Algemeen]=>[Systeeminformatie] en/of [Communicatielogging digitaal systeem] en dan proberen na te gaan of er een correlatie is tussen het optreden van de door jou beschreven problemen en de belasting van de verschillende systemen. Ik vermoed namelijk toch dat daar ergens een probleem zit en dat één van de onderdelen tegen zijn limieten aanloopt en de keten is nu eenmaal zo sterk als zijn zwakste schakel.
Met beste groeten
Dirk
HO=TC |
 |
|
|
rjr
Netherlands
144 Posts |
Geplaatst - 11 dec 2013 : 16:33:07
|
Ik heb geen marklin, dus beetje vreemd dat dat bij mij de oorzaak zou zijn van soms te ver doorrijden.
Laten we wel zijn, koploper is een programma dat op een computer draait, net als elk ander programma. Heeft dus resources nodig van de computer, en als de computer te druk is met andere dingen kan dat niet. Kan een virus programma zijn die even in de weg zit, kan wezen dat de processor gewoon niet de capaciteit heeft, kan wezen dat het geheugen niet voldoende is en er te veel geschreven/lezen van disk moet worden.
Per slot van rekening heeft koploper niet voor niets de optie, minder resources gebruiken. Minder gebruiken moet gevolgen hebben voor het programma, ergens moet dat terug komen.
Aan de andere kant geeft het ook aan dat koploper dus wel resources gebruikt, en die kunnen dus ook gewoon te beperkt zijn.
Koploper heeft dan nog de eigenschap dat het tijdkritische opdrachten geeft. Als je in een tekstverwerker wat invoert, en het duurt zo nu en dan eens 2 seconden voor het op beeld is is dat niet zo erg.
Als je trein op de cm nauwkeurig moet stoppen dan is het wel vervelend als het commando de ene keer een seconde later binnen komt dan de andere keer. Nu rijden ze niet zo snel, maar het geeft verschil.
Nu is dit vanaf het begin voor koploper zo geweest, dus is dat iets waar je met programmeren rekening mee houd. En dat is volgens mij heel goed gelukt, dat zie je wel aan de vele banen die er mee rijden, en waar toch eigenlijk alles wel goed verloopt. Maar dat dit soort problemen nooit aan koploper in combinatie met de computer kunnen liggen is onzin. Als de computer niet de benodigde capaciteit heeft, of veel te druk is met andere dingen dan zul je dat toch merken aan het treinen verloop. En dat kan zijn als koploper zelf druk is, en dus veel treinen rijden dan wel veel wissels geschakeld moeten worden. Maar kan ook als koploper relatief rustig is waardoor de computer zijn tijd anders gaat indelen.
Wat dan een goede computer is? Ja dat vragen onze klanten ook regelmatig, maar daar is geen simpel en eenduidig antwoord op te geven. Hangt er heel erg vanaf wat je met de computer doet, hoe groot de baan is. Een computer die enkel en alleen koploper draait zal minder nodig hebben dan een computer waarbij je ook wel eens iets op internet doet. Dit laatste vergt eigenlijk ook al wel iets van anti virus software. En die blijkt ook regelmatig voor onverklaarbare problemen te kunnen zorgen. En wat voor niet gevraagde programma's krijg je mee als je op internet rond kijkt.
Laat het duidelijk zijn, ik geef koploper hier zeker niet de schuld van alle bovengenoemde problemen. Ik denk dat het heel goed geschreven is, en ook op heel veel systemen, ook kleinere/lichtere versies, genoeg kracht overhoud voor een goed verloop. Als je echter wel dit soort problemen hebt, hou dit dan ook eens in de gaten. En kijk ook eens na wat koploper allemaal moet doen.
In het begin was het bij mij een ovaal met 11 opstelsporen. max 1 trein die rond kon rijden, en als die stopt kon de volgende vertrekken. De baan is groter en groter geworden, met meer kritische punten over waar een trein moet stoppen. Sinds kort ook de draaischijf aangestuurd via koploper. Daar is het zeker van belang dat de trein op tijd stopt. Baan is vergroot, extra boosters gekomen, extra decoders gekomen, extra terugmelders gekomen, maar mijn PC is nog altijd dat oudje dat ik nog had staan toen ik jaren terug met de baan begon.
Dus als je dit soort problemen hebt, hou het dan ook eens in je achterhoofd, wat voor systeem heb ik, en wat vraag ik daar allemaal van. Zou hij dat aan moeten kunnen, of is deze naar de huidige maatstaven toch al wel heel erg oud? En is het dan eenvoudig eens een te testen met een nieuwere/sneller systeem? Het totaal kan nooit sneller worden dan het traagste onderdeel, dat kan een interface zijn tussen centrale en computer, kan een centrale zijn, maar kan ook de computer zijn.
Groet,
Roelco |
|
|
|
Wim Ros
Netherlands
6230 Posts |
Geplaatst - 11 dec 2013 : 17:10:23
|
Carel,
Misschien tijd voor andere systemen en andere software, wie weet wordt je daar vrolijker en wijzer van.
Verder vind ik dat je wel heel erg overdrijft, als ik je bericht lees, dan krijg ik de indruk dat het geheel niet werkt en alles een beetje belachelijk wordt gemaakt.
Ik neem je berichtgeving dan ook met een tonnetje zout.
Mvg
Wim.
Alleen de waarheid ligt in het midden
s88SD16-n s88XPressNetLI LocoNet-Interface s88LN xTreme Keerlus |
|
|
|
carel richters
Netherlands
348 Posts |
Geplaatst - 11 dec 2013 : 17:22:57
|
Hallo Dirk en Roel,
Dirk, ik heb niet zoveel last, behalve dat doorrijden, van de door mij beschreven "problemen". Ik was alleen benieuwd of iemand een verklaring zou vinden voor een verschijnsel, dat tegengesteld is aan wat ik verwacht. Jij zoekt het in de bedrading en wijst naar de middelen om dat te onderzoeken. Ik ga kijken, of ik daarin wat kan vinden. Een monitorprobleem lijkt mij onwaarschijnlijk. Ik gebruik er nog maar een.
Roelco, jij wijst in zijn algemeenheid op de groei van een baan en de oude computer, die daarmee gen gelijke tred heeft gehouden, als ik dat zo mag samenvatten. In veel gevallen zou dat best eens kunnen opgaan. Omdat ik nog niet zo'n oude computer gebruik, denk ik in mijn geval meer aan wat Dirk zegt, dat ik tegen een capaciteitprobleem voor wat betreft de stroomvoorziening oploop. Die heeft ook geen gelijke tred gehouden met de groei van mijn baan. Maar of dat wat van doen heeft met het wisselende aantal cm doorrijden vraag ik me af. Op een draaischijf is dat heel vervelend. Dat probleem delen we. Ik heb wel een Märklin centrale (CS1R), waar, naar ik aanneem, wel een Märklin interface in zit, maar die kan ook van ESU zijn. Als we allebei last hebben van dat onregelmatig doorrijden, terwijl jij in ieder geval geen Märklin interface hebt, vraag ik me ook af, of dat de oorzaak kan zijn.
Mvrgr
Carel |
|
|
|
carel richters
Netherlands
348 Posts |
Geplaatst - 12 dec 2013 : 00:52:34
|
Hallo Wim,
Ik heb gezegd in reactie op alles wat ik in dit draadje heb gelezen, dat ik de daarin beschreven verschijnselen herken. Daarom spreekt dit draadje mij aan. Drie dingen vielen mij met name op:
vertraging in de commando's vanuit KL; daarvan merkte ik op, dat ik die vertraging met name bij het zetten van een wisselstraat juist niet bij een drukke bezetting merkte, maar bij een bezetting van 1 loc. Dat vind ik vreemd, omdat ik dat andersom zou verwachten. Ik zocht alleen naar een verklaring hiervoor. Naar een verklaring zoeken voor iets wat je merkt, maar niet verwacht, heeft niets met de waardering voor het programma te maken.
Het tweede, dat opviel was het spanningsverlies, dat als mogelijke oorzaak voor een vertraging zou kunnen zorgen. Ik merkte op, dat ik daar op een heel andere manier last van had, nl het verlies van K83 decoders door spanningsverlies. Dit heeft niets met KL te maken of de waardering voor KL.
Het derde was het doorrijden in cm. Daarvan merkte ik op, dat dit bij mij wisselend is en dat heb ik als hinderlijk omschreven met name op een niet al te grote draaischijf, omdat een loc de ene keer wel juist stopt en een ander keer niet. Dat is het enige wat je als negatief voor KL zou kunnen aanmerken. Maar als je een ding als hinderlijk ervaart, wil niet zeggen, dat je het een waardeloos programma vindt.
Ik begrijp dus niet helemaal, wat jij bedoelt, dat ik maar andere software moet gebruiken.
Mvrgr
Carel
|
|
|
|
Barry
Netherlands
126 Posts |
Geplaatst - 12 dec 2013 : 13:13:34
|
L.S.
Bij enig zoekwerk op dit forum, kom ik een oud draadje (28/01/2010) tegen, waarin een reactie staat van Paul Haagsma m.b.t. het CPU-gebruik.
quote:
Wat zeker meespeelt: hoeveel treinen (eh trams) willen eigenlijk verder rijden maar moeten steeds controleren of een volgend blok vrij is. Als dit meer wordt (en deze rijden dus niet eens) is het voor Koploper zwaarder.
Het ligt dus ook zeker aan de baan/schaduwstation hoe Koploper functioneert.
Mvg,
Paul
Paul geeft hier (mijns inziens) duidelijk aan, dat de opbouw en lay-out van een baan wel degelijk invloed heeft op het CPU-gebruik.
Een voorzichtige conclusie is, dat de performance ven een computer niet de bepalende factor is bij eventueel doorschietende treinen of het te laat schakelen van wissels.
Het is veel meer de lay-out van de baan en hoeveel commando's nodig zijn om alles goed te laten werken. Zeker als daarbij ook nog de nodige commando's naar seinen moeten worden gegeven en allerlei andere acties in gang moeten worden gezet. Dit gekoppeld aan een vaak relatief kleine oppervlakte van een baan (en dus relatief kleine blokken en secties) en kans op fouten neemt toe.
Ik heb het op mijn eigen baan eens uitgeprobeerd.
Als ik de gehele baan laat berijden, kan ik maximaal 9 locs laten rijden, zonder dat er fouten ontstaan.
Als ik de helft van mijn schaduwstation en een aantal blokken op de baan zelf uitschakel (dus minder wissel- en seincommando's), kunnen er 16 locs (waarvan ook nog 2 in tractie, dus 18 locs) rijden. Doordat deze dan met iets meer regelmaat op elkaar moeten wachten ( daar blokken bezet zijn) zie je het CPU-gebruik wel behoorlijk oplopen. Maar geen fouten.
Dit klopt geheel met het beeld, dat Paul in 2010 al heeft geschetst.
Mijn voorzichtige conclusie (ook naar mijn eigen baan kijkend): de lay-out en afmetingen van de baan en het aantal commando's (in tijd gezien), dat nodig is om alles goed te laten verlopen, lijken meer bepalend dan het programma Koploper of de computer.
Wat weer de stelling van Paul onderschrijft: Koploper kan uit de voeten met (relatief) oude computers.
Ook: een ketting is zo sterk als de zwakste schakel. En misschien zijn we dat wel zelf, daar we veel te veel vragen van onze treinbaan op een veel te kleine oppervlakte.
Zelf nu bezig met een nieuw ontwerp te maken voor een baan en neem deze ervaringen (en alle opmerkingen in dit draadje) zeker mee bij het maken van de lay-out. Ongetwijfeld komen er dan weer andere zaken boven, maar dat houdt de hobby zo interessant.
En Koploper blijft een fantastisch programma.
Groeten,
Barry
N-spoor, Epoche III / Koploper (Vista Premium, Dual-Core) / ECoS / LokPilot / Kuehn / Uhlenbrock / SwitchPilot / Lenz / BMD16N-SD
I just want to celebrate another day of living |
|
|
|
phdirk
Netherlands
2556 Posts |
Geplaatst - 12 dec 2013 : 16:20:43
|
Hallo Carel,
Ik ben denk ik niet helemaal duidelijk geweest in mijn antwoord. Ik zit namelijk ook veel meer in de richting van Roelco en Barry te denken, namelijk dat één van de onderdelen van het systeem aan zijn limieten zit. Dat kan de PC zijn, in combinatie met wat Koploper er, gezien de grootte van de baan van vraagt of de interface (jouw CS1R). Daarom mijn suggestie om de belasting van de verschillende systemen eens te bekijken en na te gaan of er een verband is met het optreden van storingen.
Met beste groeten
Dirk
HO=TC |
|
|
|
PaHaSOFT
3413 Posts |
Geplaatst - 12 dec 2013 : 19:03:38
|
Wat ik mis in deze hele discussie: kijk eens bij algemeen / systeem informatie. Wat is dan bij een werkende omgeving het aantal cycli per seconde?
Je kan hiervan ook een grafiek zien: algemeen / statistiek. Selecteer dan even het window met de grafiek. In het menu bewerken kan je optie "Aantal cycli" aanzetten. Hoe verloopt deze grafiek? Wat is ongeveer de minimale waarde?
Zelf hanteer ik als ondergrens ongeveer 300. Ik draai zelf nog op Windows98 met 'hele oude' Pc en ik rij met 28 treinen op een testtraject. Geen enkel probleem.
Mvg,
Paul. |
|
|
|
Barry
Netherlands
126 Posts |
Geplaatst - 12 dec 2013 : 19:20:08
|
@Paul,
Helder wat je zegt.
Voor de beeldvorming: mijn gemiddelde van de cycli staat op 1400. Hij komt nooit en te nimmer onder de 1300. Eerder gaat het naar een gemiddelde van 1500
Vanuit die hoek kan het dus geen enkel probleem zijn.
Vrolijk verder zoeken wat de eventuele fouten veroorzaakt.
Lang dezelfde locs laten rijden en voldeonde remrecords opbouwen, maakt okk, dat het aantal fouten minder wordt.
Geduld is dus een schone zaak.
Groeten,
Barry
N-spoor, Epoche III / Koploper (Vista Premium, Dual-Core) / ECoS / LokPilot / Kuehn / Uhlenbrock / SwitchPilot / Lenz / BMD16N-SD
I just want to celebrate another day of living |
|
|
|
carel richters
Netherlands
348 Posts |
Geplaatst - 12 dec 2013 : 20:26:59
|
Hallo Dirk,
Ik denk, dat ik n.a.v. Het antwoord van Barry begin te begrijpen, hoe de vork in de steel zit. Voor mij was belasting altijd identiek met drukte op de baan. Ik begin nu te begrijpen, dat dit niet de belangrijkste factor hoeft te zijn. Van belang is waarschijnlijk het aantal afvragingen/ handelingen dat het programma moet doen om de juiste opdracht te geven. Dat verklaart voor mij, waarom in mijn geval van een enkele locomotief op de baan op een bepaald punt, het zo lang duurt voor de wisselstraat wordt gezet. De loc moet daar wachten tot de wisselstraat is gezet, terwijl alle blokken vrij zijn. Niet de drukte van het verkeer op de baan is hier van belang, maar de gecompliceerdheid van het sporenplan . Vanuit verschillende kanten kan dat punt bereikt worden. Dat betekent veel afvragingen alvorens de wisselstraat gezet kan worden. Het bezet of niet bezet zijn van de blokken zal daarbij van ondergeschikt belang zijn. Die afvragingen moeten gedaan worden en of de uitkomst bezet of vrij is van een blok heeft geen invloed op de duur van de afvragingen. Als daar nog allerlei seinen bijkomen en andere handelingen, die al of niet verricht kunnen worden, dan neemt de systeembelasting nog meer toe en kan ik mij die vertraging voorstellen.
Daarmee heb ik nu het antwoord op deze vraag gevonden. Ik wil graag, als iets tegen kom wat ik niet begrijp, of iets is tegengesteld aan wat ik verwacht, begrijpen, waarom dat zo is. Misschien druk ik me dan verkeerd uit, omdat ik het niet begrijp, hoe het in elkaar zit. Hoe beter ik het programma begrijp, hoe beter ik er mij kan omgaan en hoe mooier het dan voor mij is. Dan weet ik ook, wat ik er aan doen, dan wel of ik het wil accepteren of een andere oplossing moet zoeken. In dit geval accepteren.
Overigens verklaart dit naar mijn idee niet - ik blijf hardnekkig - het wisselend over- of onderschreiden van het aantal cm doorrijden. Ik houd me aanbevolen voor de verklaring hiervan, nog liever in dit geval de oplossing hiervoor: hoe voorkom ik die onregelmatigheid.
Mvgr
Carel |
|
|
|
carel richters
Netherlands
348 Posts |
Geplaatst - 12 dec 2013 : 20:48:09
|
Hallo Paul en Berrry,
Ik ben geen computerdeskundige, alleen een gebruiker. Terwijl ik mijn antwoord aan Dirk zat te schrijven komt Paul intussen met zijn verwijzing naar het aantal cycli. Daar wil ik best naar kijken, maar het zegt mij niets, in zoverre, dat ik hieruit afleid, dat het een maatstaf is voor de belasting van het systeem (de processor?).
Als iemand het mij kan uitleggen, begrijp ik wat het inhoudt en krijgt het ook betekenis voor mij en mogelijk vele anderen.
Overigens zie ik een aanmerkelijk verschil tussen wat Paul en Berry hanteert. Wijst dit laatste op problemen? Waarom is het bij Paul zo laag? Hangt dat samen met de inrichting van de baan?
B.v. dank en mvrgr
Carel |
|
|
|
PaHaSOFT
3413 Posts |
Geplaatst - 12 dec 2013 : 21:52:41
|
Carel,
Als je nu eens goed leest: ik draai op een oud beestje van denk ik 15 jaar oud. Waardoor zou dan het verschil ontstaan? Juist de snelheid van de processor.
Het aantal cycli zegt alleen dat Koploper per seconde zoveel keer de centrale verwerking routine doorloopt. Eigenlijk zou zelfs nog een getal van 100 voldoen.
Mvg,
Paul. |
|
|
|
PaHaSOFT
3413 Posts |
Geplaatst - 12 dec 2013 : 22:02:20
|
quote:
Oorspronkelijk geplaatst door carel richters
Dat betekent veel afvragingen alvorens de wisselstraat gezet kan worden. Het bezet of niet bezet zijn van de blokken zal daarbij van ondergeschikt belang zijn. Die afvragingen moeten gedaan worden en of de uitkomst bezet of vrij is van een blok heeft geen invloed op de duur van de afvragingen.
Echt onvoorstelbaar hoe dit bedacht kan worden; klein tipje van de sluier:
- Koploper kijkt eerst of van de mogelijk te kiezen blokken een blok vrij is. Dit is een snelle controle. Als de blokken al bezet zijn, hoeft er ook niet gekeken te worden naar wisselstraten
- Pas als een vrij blok is gevonden kijkt Koploper of er een vrije wisselstraat gevonden kan worden. Alleen controle op wissels en dergelijke en NIET op lijnen in het baanoverzicht
- Wanneer vrij blok en vrije wisselstraat is gevonden, zal Koploper volgend blok reserveren en de wisselstraat zetten. Als dit het aansluitende blok is van waar de trein staat, dan mag de trein pas vertrekken als alle wisselopdrachten door Koploper zijn verzonden. Pas dan is met redelijke zekerheid aan te nemen dat de wisselstraat goed staat. Dan wordt het sein van onveilig afgehaald en na de vertrekvertraging (instelbaar door gebruiker) zal de trein in beweging komen.
Snelheid van wisselstraat zetten maakt ook uit hoe je instellingen zijn: bijvoorbeeld: tijd opdrachten en rusttijden; altijd geven van de opdracht of alleen als de wissel in een foutieve stand staat.
Er zijn zoveel factoren die iets bepalen dat het bijna niet meer te doen is (voor mij) om specifieke support te geven (en dat doe ik dan ook niet meer). Vaak is het een combinatie van iets zien gebeuren, instelling(en) die ergens een verklaring voor geven. Ik trek me verder weer terug uit deze discussie.
Mvg,
Paul. |
|
|
|
phdirk
Netherlands
2556 Posts |
Geplaatst - 13 dec 2013 : 16:31:00
|
Hallo Carel,
Ik denk dat je nu in de goede richting zit te denken. Het heeft volgens mij met de algehele belasting van de systemen te maken. Het aantal cycli is een indicatie of dat nog lukt. Als dat aantal inzakt, is er sprake van een zodanige belasting dat mogelijk signalen achter gaan lopen. Dat kan, zoals al eerder in dit draadje is aangegeven ook gevolgen hebben voor het doorrijden in cm. Als daar de signalen voor de snelheidsstappen (en dus de afname van de snelheid) niet op tijd doorkomen, zal het aantal cm doorrijden niet kloppen.
Overigens zal een niet meer kloppende ijking van de snelheid ook problemen met het doorrijden in cm veroorzaken, namelijk te ver wanneer de werkelijke snelheid inmiddels hoger is dan de geijkte snelheid en te kort in het omgekeerde geval.
Met beste groeten
Dirk
HO=TC |
|
|
|
dentheo
Belgium
1758 Posts |
Geplaatst - 13 dec 2013 : 19:22:48
|
Dirk,
Ik mis in deze redenering wel de snelheid van de IB of twincenter, die moet toch ook een rol spelen. Die moeten de signalen van KL toch doorgeven (vertalen ?) en zullen toch ook hun grenzen hebben.
Piept een centrale als ze niet meer kan volgen ?
Theo vanop de heide.
N+SX+kpl+kplRsd |
|
|
|
carel richters
Netherlands
348 Posts |
Geplaatst - 14 dec 2013 : 00:30:20
|
Hallo Dirk,
Dat een niet kloppende ijking invloed heeft op het aantal cm doorrijden is duidelijk en dat doet het, want bij mij is geen enkele ijking echt zuiver, maar dat betekent, dat je voor elke loc proefondervindelijk het aantal cm moet vinden en als je ze gevonden hebt, zouden ze niet mogen afwijken en dat gebeurt wel. Dus dat zou met het inzakken van de cycli te maken moeten hebben. Ik heb daarnaar gekeken en bij mij bewegen die zich tussen 830 en 850. Dus m.i. Is van inzakken geen sprake.
Wat de vertraging in het zetten van de wissels betreft, als de niet wordt veroorzaakt door de hoeveelheid informatie,die moet worden onderzocht , alvorens de wisselstraat wordt gezet, wat is de oorzaak dan? Paul verwierp dit in de allervriendelijkste woorden, die hij maar bedenken kon, en ging toen een tipje van de sluier oplichten, waarvan ik weinig begreep. Ik meende enig zicht te krijgen in wat er aan de hand is, naar volgens Paul, raakt dit kant noch wal. Daar zit ik dan met mijn goede gedrag en pogingen om te er achter, hoe het precies in elkaar zit en goed inzicht te krijgen hoe problemen werkelijk opgelost worden De heren, die het weten kunnen, behandelen je als oud vuil en trekken zich terug in hun ivoren toren. Ik houd er een vervelend gevoel aan over en het zijn telkens dit soort dingen, die je het plezier in Kl ontnemen. Niet mogelijkhede |
|
|
|
carel richters
Netherlands
348 Posts |
Geplaatst - 14 dec 2013 : 00:48:56
|
| De vorige reactie werd voortijdig afgebroken. Ik wilde zeggen: niet de mogelijkheden op zich ontnemen je het plezier, maar de vaak onduidelijke manier waarop deze gerealiseerd moeten worden en vervolgens het sneue antwoord, dat de zelf gekroonde koning van dit forum en de werkelijke koning je in de hoek zetten, als ze merken, dat je van een ander niveau bent, dan waarop zij zich wanen. |
|
|
|
hubertus
Netherlands
1958 Posts |
Geplaatst - 14 dec 2013 : 08:31:48
|
Zoals al eerder aangegeven, als je twijfelt of koploper opdrachten doorgeeft en op tijd, laat de communicatielogging meelopen.
Mbt je wisselprobleem, als je op 7 meter al een merkbare spanningsval hebt, zou ik de bedrading onder je baan eens nakijken.
Mbt het niet steeds even ver doorrijden van je locs, hoe komt de bezetmelding tot stand? Als dat door rail/wielcontact is, kun je er gevoeglijk van uitgaan dat het een contactprobleem de oorzaak is (bijv. vuile rails en/of wielen).
Je oordeel over de hulp van anderen, laat ik voor jouw rekening. Ik ervaar het in ieder geval niet op die manier.
Huub |
|
|
|
Schuif
Netherlands
70 Posts |
Geplaatst - 14 dec 2013 : 09:52:31
|
Heren,
als "starter" van dit draadje heb ik de discussie met belangstelling gevolgd, en we zijn inmiddels erg in detail getreden met zelfs een reactie van Paul, de maker van het door ons allen zo gewaardeerde koploper.
Ik begon met: doorschieters, en langzamer rijdende loc's bij veel bedrijf;
na het volgen van deze discussie, en andere draadjes ben ik tot de volgende oplossing gekomen voor MIJN probleem;
doorschieters;
- uiteindelijk slechts met 3 van de 20 loc's; dus deze opnieuw geijkt en de remvertraging volledig teruggedraaid (want het zijn toevallig 3 loc's met wat "oudere Märklin" decoders; en heb met 2 loc's het probleem niet op kunnen lossen; nieuwe ESU decoders in de loc en....... EUREKA; probleem van doorschieters wel opgelost
spanning/langzaam rijden;
- mijn baan met zo'n 80 wissels en ongeveer 150 m1 rails erop heb ik nu op veel meer plaatsen aan een ringleiding gehangen, zonder gebruik te maken van een booster; gewoon de ECOS II die nu op de baan zo'n 18 tot 20 volt geeft; ik heb deze wel iets opgedraaid aan de ingaande voeding
- tijdens het rijden en volgen van cycli en communicatieloggingzie ik geen afwijkingen behalve:
"loc zal 28 cm doorrijden" Hé??????
ik heb echter op "bijzondere eigenschappen" ingevuld dat de loc -/- 15 cm moet doorrijden bij VOORUIT, en -/- 10 cm bij ACHTERUIT;
Vraag:
- wat heb ik verkeerd in KL ingegeven?
MvG
Erik |
|
|
|
hubertus
Netherlands
1958 Posts |
Geplaatst - 14 dec 2013 : 10:20:50
|
Waarschijnlijk niks.
Zoals je het aangeeft, een negatief getal bij doorrijden, zal de loc het aantal opgegeven cm doorrijden plus de lengte van de locomotief.
In jouw voorbeeld, stel de loc is 20 cm, dan zal deze vooruit 35 cm en achteruit 30 cm doorrijden.
Huub |
|
|
|
phdirk
Netherlands
2556 Posts |
Geplaatst - 14 dec 2013 : 15:16:13
|
Hallo Theo en Carel,
@Theo,
Je hebt helemaal gelijk. Ik bedoelde inderdaad te zeggen dat alle componenten van de keten een rol spelen, dus ook de interface. Helaas is die het slechtst van alle te volgen, althans bij een TC of IB. Daar merk je niets aan, hooguit een reset of iets dergelijks. Ik herinner me nog het experiment van een paar jaar geleden om de Loconetaansturing via de RS232-poort te doen. Daarbij bleek dat de IB?TC een slecht luisteraar was, om het maar zo te zeggen.
@Carel,
Als de geijkte snelheden gaan afwijken van de werkelijke, bijvoorbeeld door het vuil of oud worden van een motor, problemen in de decoder, dan zullen de doorgereden afstanden ook niet meer kloppen.
Ik vind de suggestie van Erik ook heel nuttig. Ik zie bij mij ook bij sommige treinen dat er veel minder problemen zijn met het scherp rijden dan met anderen en ik begin nu te denken dat het merk en type decoder daar ook wel iets mee te maken kan hebben.
Tot slot denk ik dat alles wat hier gezegd is over belasting van de verschillende systemen elkaar niet bijt. Zo lees ik ook de bijdrage van Paul, waarin hij schetst hoe Koploper werkt. Het is een kwestie van bepalen wat er moet gebeuren via een bepaald algoritme en dat betekent altijd belasting voor een systeem. De combinatie van de verschillende algoritmes en protocollen en de snelheid waarmee de data verwerkt kunnen worden blijven dan bepalend. Als je met een Nederlander, een Rus, een Engelsman en een Chinees door de stad wandelt en deze mensen je continu vragen stellen over de bezienswaardigheden van de stad, is de kans groot dat je een afslag mist en daardoor een verkeerde straat inloopt.
Met beste groeten
Dirk
HO=TC |
|
|
| Pagina: 1 2 (of 2) |
Onderwerp |
|
|
|
1,2,3 enz tot 7 maar dan?
