Hallo allemaal,
In het verleden heb ik al meer problemen gehad met Koploper en Ecos. Dat zou opgelost zijn met de nieuwe versie van Ecos 4.01, waarin ESU een speciale voorziening had aangebract tbv KL, die in de Ecos moet worden aangevinkt.
In de eerste plaats geeft KL steeds een melding, dat deze moet worden aangevinkt, terwijl hij is aangevinkt.
Verder zie ik in de Ecos, dat zich constant mfx locs aamelden, terwijl ze aanwezig zijn in de Ecos. Op dat moment kan ik in Kl niets met de loc doe, die zich weer staat aan te melden. In de Ecos kan ik niet zien welke loc dat is. Ik zie alleen, dat een loc zich staat aan te melden. Als het aanmelden is gebeurd en ik kijk naar de synchronisatie, dan zie ik, dat aan beide zijden dezelfde loc staat en moet ik in het menu onderhouden locomotieven in KL de locs koppelen vanuit de centrale, waarna als het goed is de zaak weer in overeenstemming is. Overigens was dit voor versie 4.01 ook al het geval. Niet in alle gevallen echter is de overeenstemming te bereiken. Dan zegt Kl, dat de loc vanuit de centrale naar KL is overgebracht, maar dat er twee locs met hetzelfde adres zijn en dat de onderste niet actief is gemaakt en dat is dan de loc, waaraan een aantal logische actie, telacties en specifieke acties verbonden zijn. Die moeten eerst allemaal verwijderd worden voor de loc verwijderd kan worden en voor de nieuwe loc moeten deze allemaal weer worden aangemaakt. Zeer tijdrovend en frustrerend.

Daarnaast treedt dit probleem nu ook op bij niet mfx locs, hetgeen voorheen niet het geval was. Deze zijn niet te koppelen en moeten dus allemaal verwijderd worden en opnieuw ingebracht.

Ook kan het gebeuren, dat een mfx loc ineens een andere richting uit gaat rijden met alle gevolgen van dien, of zich niets aantrekt van de opdrachten uit KL., bijvoorbeeld uit een blokgroep vertrekt, terwijl hij moet wachten op een trein, die nog op en ander spoor van de blokgroep moet arriveren. De verschijnselen treden plotseling op gedurende het automatisch rijden zonder dat er enige andere handeling aan ten gronslag ligt.
Het aanmelden van Mfx locs vindt voortdurend plaats. Vroeger was de oplossing de vebinding tussen KL en Ecos onmiddellijk verbreken, als dit gebeurde, synchroniseren, locomotieven koppelen en het probleem was opgelost. Nu stopt het steeds opnieuw aanmelden van mfx locs niet, ook niet na het verbreken van de verbinding, opnieuw synchroniseren en koppelen.

Ik ervaar de versie 4.01 van de Ecos en de aanpassing voor KL niet als een verbetering. Zijn er meer mensen, die hier last van hebben en wat is de oplossing? Dit is echt niet leuk werken met De Ecos en KL.
Waar ligt het aan aan Kl of aan de Ecos. Ik weet het niet. Weet Walter misschien wat er aan de hand kan zijn?

Mvrgr
Carel
Ca

Met versie 4.0.1 van Ecos bedoel ik natuurlijk versie 4.1.0.
Mvrgr
Carel

Carel, om correcties in jouw bericht aan te brengen is daar de onvolprezen knop "verander"...

Of gewoon een "reactie" op je eigen draadje.

groet
Harald

Hallo Carel,

Ik heb dezelfde configuratie en gelukkig geen enkel probleem.
Ik weet dat Walter Wissels betrokken is geweest bij de totstandkoming hiervan.
Hij kan jou misschien verder helpen.


Mvg,

Peter Degeluidsman

Hallo Carel,

Oke eerst een heleboel dingen die je juist niet moet doen,

Als mfx locs zich (opnieuw) aanmelden is het beter om de communicatie met welk software programma dan ook niet open te hebben staan, dit geldt dus ook voor koploper.
Dubbele decoder adressen in de centrale vermijden.
Als alle locs in je centrale zijn opgeslagen en het aanmelden is voltooid, de centrale op de juiste manier afsluiten, als de backup batterijen leeg zijn of niet geplaatst zijn 5 seconden op de stopknop drukken.

Legacy modus aanzitten voor de Ecos/CS1Reloaded vanaf firmware versie 4.1.0 (en ook in de volgende versie 4.1.2 werkt dit correct.) zodat de decoderadressen doorgegeven worden aan koploper.
Geen synchronisatie van locs naar Koploper als deze daar al bestaan, maar zorgen dat locnaam lees kenmerk, decodernummer groter dan 0, en decodertype overeenkomen.
Nu pas verbinding maken vanuit Koploper (of andere) met de centrale
Voor mfx locs niet de optie synchroniseren gebruiken, maar in onderhouden locomotieven de locomotief koppelen.

Net als Peter heb ik geen enkel probleem en heb veel locs die zich automatisch met Railcom of mfx aanmelden zonder dat dit  conflicten geeft.

met vriendelijke groet,

Walter

Edit Walter locnaam aangepast naar kenmerk omdat hier verwarring over ontstaat.

Hallo Walter en anderen,
Bedankt voor jullie reactie. In antwoord op Walters reactie kan ik toevoegen, dat het probleem zich aanvankelijk na installate van 4.1.0 helemaal niet voordeed. Een paar dagen geleden manifesteerde zich dit plotseling tijdens het automatisch rijden. Enkele mfx locs waren niet meer met KL te besturen, een loc begon na een stop zelfs achteruit te  rijden en enkele niet mfx locs waren ook met KL niet meer te besturen. Wat doe je dan?  Je zet zo snel mogelijk de centrale uit en gaat met synchroniseren na, welke ongelijkheden er zijn. Toen vond ik een aantal mfx locs, waarvan in KL het objectnr op 0 was gezet evenals van enkele niet mfx locs. De mfx locs waren eenvoudig met koppelen in het onderhoudsmenu locomotieven van KL weer snel in het gareel te krijgen, maar niet de andere locs. Die moesten zowel in KL als in Ecos opnieuw worden ingebracht met alle bijbehorende acties in Kl, nadat ze eerst verwijderd waren.

Nadat alles hersteld was ging Ecos de mfx locs weer opnieuw inlezen, waarbij ik niet kon vaststellen welke locs dat waren, want alle mfsx locs waren gewoon zichtbaar in de Ecos, ook die opnieuw werden ingelezen.
Naderhand bleek uit het feit, dat een aantal locs  met KL niet aanspreekbaar waren welke locs dat waren. Hetzelfde gebeurde met enkele andere locs, waarbij het objectnr van die locs in KL op 0 waren gesteld. Dus die moesten zowel in KL als,in de ecos worden weggehaald en onieuw ingebracht met alle  ellende van dien.

Inmiddels heb ik wel een deel van de oorzaak achterhaald: het wijzigen van het kenmerk in KL betekent, dat deze niet meer overeenkomt met de naam van de loc in de ecos en dan gaat Ecos vreemd reageren. Kennelijk beschouwt Ecos het kenmerk in KL als de naam van de loc. Dit is natuurlijk vreemd, want een kenmerk is geen naam en het doel van een kenmerk is ook anders dan de naam.Wie daarvoor verantwoordelijk is, weet ik niet, maar fout is het wel en het heeft voor de gebruiker hele vervelende konsekwenties.

Mvrgr
Carel

Hallo Carel,

het aanmelden van locomotieven is niet afhankelijk van Koploper, zet tijdens het aanmelden van de locs de communicatie met Koploper uit,

het wissen van een loc kan lijden tot het opnieuw aanmelden van alle Mfx locs,

met vriendelijke groet,

Walter

Als reactie op je vervolgvraag van het Koploperforum,

Hallo Carel,

dan toch een antwoord ondanks dat het lastig om de discusie op 2 plekken te voerden, inderdaad kijkt Koploper naar het kenmerk en niet naar locnaam, dit heb ik op het 3railforum aangepast omdat dit blijkbaar niet duidelijk genoeg was,

Op het moment dat er een verschil is tussen kenmerk in koploper en naam in de Ecos en/of decoderadres en/of decodertype kan koploper deze loc niet aansturen,

Het vinkje bij Enable Legacymodus moet aangevinkt worden op de Ecos onder instellingen 3, anders stuurt de Centrale geen decoderadres terug naar de computer, dit is zelfs speciaal voor koploper en andere software programmatuur die op adres vergelijken door Esu ingebouwd.

Het 4 cijferige loc id vanaf nr. 1000 is geen vast gegeven, dit blijkt uit het feit dat je een loc wist, de centrale mogelijk aan alle locs met m4/mfx decoder een nieuw nummer kan toewijzen. Dit gebeurd maar sporadisch maar kan hele grote gevolgen hebben met synchroniseren op loc-id. Hier ben je ook al eerder tegen aan gelopen, en Koploper is hierop aangepast. (Ook in diverse andere treinbaanbesturingssoftware kan je tegen dit probleem aanlopen met hele grote gevolgen.)

Het is daarom mogelijk om in Koploper een verloren locomotief opnieuw te linken in koppel centrale in onderhouden locomotieven, hiervoor moeten dus eerder genoemde 3 items exact overeenkomen. Hiermee koppel je dus een reeds in koploper en reeds in de centrale bestaande locs aan elkaar.

Het opnieuw synchroniseren vanuit Centrale naar Koploper is dus niet nodig, en omgekeerd een mfx loc naar de centrale synchroniseren is vanaf koploper 8.6 onmogelijk, juist omdat deze zich daar zelf aanmeld.


Dat een opnieuw aangemelde locomotief zijn rijrichting heeft verloren moet je in de combinatie ecos en locomotief decoder zoeken en niet in Koploper,

met vriendelijke groet,

Walter


met vriendelijke groet,

Walter

Hallo Carel,

Op het gevaar af.
Een lok kun je in de ECoS op een tweetal manieren uitlezen en aansturen, te weten via het objectid of via het adres.
Een lok die wordt opgegeven krijgt door de centrale een objectid toegewezen. Hierbij geef je het adres, naam, enz op.
Een MFX of RailCom(+) lok wordt automatisch ingelezen, krijgt dus van de centrale een objectid toegewezen en hieronder wordt alles automatisch ingevuld.
Voorbeeld een ingelezen MFX decoder zie afbeelding:
Objectid = 1008, rechter kolom zoals die door de centrale is ingelezen.
Hierin zie je o.a. het protocol (MFX), adres (0), snifferadres(0), locdesc (stoom met intern plaatje nummer 68), funcset (F0 t/m Fx afhankelijk van aantal nullen of enen waarbij een 0 is functie uit en een 1 is functie aan). Verder nog o.a. snelheid (speed), richting (dir) of er een adresconflict is, enz. Links en in het midden zie je wat door Koploper ingelezen wordt.
Ook zie je dat bij een MFX decoder het adres wel degelijk 0 kan zijn. Verder is het mogelijk dat meerdere MFX loks hetzelfde adres kunnen hebben. Bij het aansturen van een MFX lok doet de centrale niets met het adres en kan dus gerust 0 of gelijk aan een ander adres zijn. Waarom er in Koploper bij een MFX lok toch een adresvergelijking plaats vindt snap ik niet, te meer dat je deze via het objectid wordt.
Hier zou moeten zijn: Soort decoder = MFX dan negeer adres(vergelijking). Je hoeft dan ook niets te wijzigen.
Zo ook met accessoire decoders, ook deze kun je via het objectid of via switch methode aansturen, verschil is dat in het ene geval de centrale het protocol neemt wat jij hebt opgegeven (DCC of MM) en dus een grotere vrijheid hebt, in het andere geval het protocol wat default bij de centrale is ingesteld.

Zie o.a. http://www.koploperforum.nl/topic.asp?TOPIC_ID=5062
Hier wil ik me verder niet mee bemoeien maar met een logging is eenvoudig te zien dat verschillende methodes worden toegepast.

O: 20000 addr[2] addrext[2g, 2r]
Z: set(11,switch[2r])
Z: set(20000,state[0])
en
Z: set(11,switch[DCC5g]) (DCC protocol)
Z: set(11,switch[MOT232r])  (Motorola protocol)


Mvg,
Peter

P.s. Nee, walter stuurt je nergens weg, hij probeert je juist zo geod mogelijk te helpen.

Hallo Freak,
Ik heb het  zo druk gehad met het uitpraten van de gerezen problemen op het Koploperforum, dat ik geen tijd meer had om op dit forum te kijken, vandaar deze late reactie. Inmiddels hebben Walter en ik de zaak op goede wijze afgesloten en is mij ook duidellijk, wat er aan de hand is en waarom. Ik weet nu wat ik wel en niet kan doen en daar gaat het mij om. Ik wil het hierbij laten en je danken voor de poging mij te laten zien, wat er aan de hand is.

Mvrgr
Carel