Liebe WDP-Entwickler,
ich kämpfe bei meiner Moba derzeit im ZFA-Betrieb mit zwei Problemen, zu denen ich mir Auskünfte, oder besser Lösungen, von den WDP-Entwicklern erhoffe.
1,) Ich muss leider immer wieder mal Weichenfehlstellungen konstatieren, für die ich keine Erklärung habe. Es kann 100 oder noch mehr Runden alles gut gehen, bis wieder mal eine falsch stehende Weiche per Kurzschluss (da DCC 2-Leiter) die Automatik stoppt. Im Gleisbild stehen diese Weichen nach meiner Beobachtung aber immer richtig, .
Alle Weichen schalten mit der Maus, mit dem Handregler, und bei "Stellen und Fahren" immer korrekt. Nun muss ich die Problemursache finden, denn es macht so keinen Spass.
Dazu benötige ich jetzt unbedingt exakte Angaben von den Programmentwicklern über die Zeitabläufe wenn Weichen geschaltet werden. Dazu interessieren:
a) wie oft sendet das Programm einen Weichenstellbefehl für eine bestimmte Weiche, bei Schaltzeitverlängerung = 0? Nur einmal, oder grundsätzlich mehrfach? Wenn ja, wie oft?
b) was passiert bei einer gewählten Schaltzeitverlängerung? Wird nur der Weichenstellbefehl mehrfach wiederholt, oder schickt das Programm einen binären Zeitwert mit, auf den der nachgeschaltete Decoder reagiert (ich denke nein)?
c) wie lang ist die kürzeste Pause zwischen zwei Weichenstellbefehlen innerhalb einer Fahrstrasse, wenn für die betreffenden Weichen keine Schaltzeitverlängerung eingetragen ist?
d.)in welcher Reihenfolge werden Weichen innerhalb einer Fahrstrasse geschaltet, fortlaufend in Fahrtrichtung?, oder geordnet nach Weichenadresse, also niederste zuerst, oder nach welcher anderen Regel?
Anhand der Kenntnis der hier gefragten Daten denke ich dem Geheimnis der Fehlschaltungen auf die Spur kommen zu können. Meine Weichendecoder sind derzeit bei Eingang eines Weichenstellbefehls auf eine Bestromungszeit von 256 msec programmiert. Ich kann das in Inkrementen von 64 msec ändern (derzeit kürzest mögliche Bestromungszeit, kann ich aber auch modifizieren)
Meine ROCO-Weichen schlagen nach meinen Messungen innerhalb von 15 bis 20 msec um, und dann schaltet die Endabschaltung ja sowieso den Strom ab.
Bitte liebe Programmentwickler versorgt mich mit den benötigten Daten. Danke
2.) Es kommt bei mir immer wieder mal vor, dass eine Lok am Ziel-ZNF nicht anhält, sondern mit der Geschwindigkeit weiterfährt, mit der sie am Ende des Bremsabschnittes in den Halteabschnitt eingefahren ist. Die zurückgelegte Fahrstrasse wird dabei frei gegeben, und die Loknummer steht schwarz im Ziel-ZNF. Also alles so, wie es sein sollte. Nur die Lok hält nicht, und wenn die nachfolgenden Weichen zufällig richtig stehen, fährt die Lok so über die halbe Anlage. Das hat nichts mit "Durchrutschen" zu tun!
Interessant ist, dass dabei im Lokcontrol die Tachonadel auf Null steht, und Sollwert- und Istwertbalken ebenfalls auf Null stehen! Ein rascher Blick auf den LENZ-Handregler zeigt aber sehr wohl eine kleine Fahrstufe an (bei mir zwischen 6 und 9 von 28, je nach Lok). Stoppen kann ich die ausgerissene Lok sowohl mit der Stoptaste des Handreglers, und auch mit der Stoptaste des Lokcontrols, obwohl ja hier gar keine Fahrstufe angezeigt wird!
Bei allen meinen Loks ist der Analogmodus ausgeschaltet, keine reagiert auf Gleichspannung am Gleis. Alle drei Booster (LENZ LV102, Ausgangsspannung geregelt) zeigen im Oszillogramm eine hervorragende Symmetrie des Gleissignals von +/- 16,5 Volt. Ich kann hier keine Ursache für das Weiterlaufen der Loks erkennen. Es scheint so zu sein, dass das Lokcontrol den Stopbefehl am Ziel-ZNF erhält, der Lokdecoder aber nicht??!!
Die Decoder in meinen (weniger wertvollen) Testloks, derzeit 13 Stück aktiv auf der Anlage, haben LENZ-Decoder
Die Typen sind LE130, nur kurze Adressen, und LE130XF, kurze und lange Adressen, aber alle mit noch niederfrequenter Motorregelung. Betroffen vom Problem sind Loks mit kurzen, und mit langen Adressen, querbeet.
Wer kennt dieses Problem auch, und hat eine Lösung, oder eine Erklärung?
Mit besten Grüssen
Jochen
Hallo Jochen ,
jetzt nur wegen 2.)
Kann es sein , das das Weiterfahren der Lok bei eine FS mit Profil passiert?
Mit welcher Lok und Fahrstrasse ist das "Weiterfahren" mit Lok-Control auf 0 zuletzt vorgekommen?
Sollte sich seit dem letzten Updload der Komplettsicherung mit der Datenpflege noch was an Fahrstrassen und Lokdaten Gleisbild oder Profilen geändert haben, dann lade auch bitte noch eine aktuelle Datensicherung ohne Lokbilder und Symboltabellen hoch.
Wenns irgenwie geht , dasnn versuche mal das Probllem exemplarisch auf eine einzige Fahrstrasse rekonstrierbar zu isolieren. Solte das gehen, test auch bitte mal , ob es ein einem (ggf. nciht mehr aktuellen ) Profil liegt, meint ob es ohne Profil nicht auftritt.
Danke und Grüße
Frank
Hallo Frank,
Deine Fragen sind rasch beantwortet: Ich habe bislang keinerlei Profile angelegt, ausser bei einer Fahrstrasse, wo ich mal ausprobieren wollte, wie es mit einem Lokpfiff vor dem Tunnel funktioniert. Dazu habe ich den Bremsabschnitt der Fahrstrasse genommen, und es funktioniert. Und am Ende dieser FS gibt, und gab es auch nie ein Problem mit weiterfahrenden Loks, die halten sollen, bis die nächste FS gestellt wird.
Sonst gibt es keine Profile mehr, und auch keinerlei Matrix-Einträge. Das alles macht erst Sinn, wenn die Grundfunktionen in Ordnung sind.
Eine Beobachtung habe ich allerdings gemacht,und dort ist es auch am einfachsten zu bemerken, bzw. wenn´s passiert ist, zu rekonstruieren. Diese neuralgischen Punkte sind zu 99% die Enden von Folgefahrten, also nach der Einfahrt am Ende eines der Bahnhofsgleise (1 BHF), bzw der Schattenbahnhofsgleise (2 SBHFé). Die Loks hätten dort am Ausfahrsignal halten sollen, fahren aber langsam weiter. Einen Schwerpunkt der insgesamt 5+5+6 Gleise kann ich nicht benennen, es passiert überall einmal, und ebenso sind fast alle Loks irgendwann einmal betroffen.
Und, wie gesagt, eine Lok kann hundert mal per Folgefahrt in ein BHF´s-Gleis einfahren, und hält wie sie soll, und bei 101. Fahrt hält sie nicht. Ich denke irgendwie wird der Stop-Befehl nicht sauber an die Lok(s) gesendet, warum auch immer.
Meine Beobachtung, dass im Lok-Control alles auf Null steht, die Lok aber trotzdem unkontrolliert weiter fährt, ein Click auf die Stoptaste des Lok-Control diese aber stoppen kann, müsste für die Entwickler doch ein nützlicher Hinweis sein.
Könnte hier auch ein Problem der LENZ-Zentrale vorliegen, die den Stop-Befehl ja auf´s Gleis schicken muss, ihn aber vom Programm nicht verstanden hat?
Mal schauen ob einer der Entwickler das Problem lösen kann, es wäre dringend notwendig, denn die auch vorhandene Weichenproblematik zusammen mit dem Weiterfahr-Problem machen einen zuverlässigen Betrieb unmöglich.
Mit freundlichen Grüssen
Jochen
Hallo Jochen,
Zitat von: Jochen Blank in 20. April 2009, 22:09:27
Meine Beobachtung, dass im Lok-Control alles auf Null steht, die Lok aber trotzdem unkontrolliert weiter fährt, ein Click auf die Stoptaste des Lok-Control diese aber stoppen kann, müsste für die Entwickler doch ein nützlicher Hinweis sein.
Könnte hier auch ein Problem der LENZ-Zentrale vorliegen, die den Stop-Befehl ja auf´s Gleis schicken muss, ihn aber vom Programm nicht verstanden hat?
wenn der Regler im Lok-Control auf "0" steht, dann hat WDP den Befehl auch gesendet. Ich kann hier zum Lenz-System nicht viel sagen, für mich sieht es nach Deiner Beschreibung so aus, dass die Zentrale aus irgend welchen Gründen, bei schneller Folge von Befehlen, nicht alle 100%tig abarbeitet. :-[
Hallo Jochen,
haenge mal einen zweiten Rechner mit einem Schnittstellen-Sniffer zwischen dem MoBa-Rechner und der Lenz-Zentrale. Diese Methode verschafft Dir die Gewissheit ob WDP schuldig ist oder nicht.
Reine Softwarloesungen mit Schnittstellen-Treiberueberwachung, gleichzeitig auf einen Rechner, sind auch nicht immer das Gelbe !
Hallo Karl,
ich habe gerade Jochen per PN drum gebeteten, um dieses nicht gerade ressourcenschonende Verfahren hier nicht anzupreisen, und damit ich die Hexdaten hinterher lesbar konvertieren kann.
In dieser Situation kommt man wohl anders nicht zu klaren Verhältnissen.
Viele Grüße
Frank
Hallo Jochen,
zu 1a) Eigentlich nur einmal, es sei denn der Befehl wird nicht quittiert, dann nach einer gewissen Zeit (habe ich nicht im Kopf) nochmal und das ganze maximal 10 mal bis mindestens einmal eine Quittung reinkam.
zu 1b) Ne, WDP schickt einen Einschaltbefehl und nach der Schaltzeit einen Ausschaltbefehl (wobei selbst beim Wert 0 WDP eine gewisse Minimalzeit den Strom immer anlässt, Zeit habe ich auf Anhieb auch nicht parat). Das heißt also die im Dekoder eingestellte Schaltzeit muss größer oder gleich der maximal genutzten Schaltzeit in WDP sein.
zu 1c) Das dürfte so ~100ms zwischen dem Einschaltbefehl der ersten und der zweiten Weiche sein
zu 1d) In der Regel von oben links nach unten rechts im Gleisbild.
Wobei sich alles gesagte erstmal nur auf Lenz beziegt, also bitte nicht verallgemeinern. Mehr kann und möchte ich hier auch nicht sagen, das würde für das Forum zu sehr ins Detail gehen.
Grüße
Markus
Hallo Jochen,
hast du mal einen Versuch gestartet die Weichen von der Fahrstrasse 2-fach schalten zu lassen? Den Stopbefehl gebe ich auf meiner Anlage im Schattenbahnhofsbreich auch zweimal. Beim Ereichen des Haltekontakts und dann 2 sec. später um Licht an der Lok auszuschalten, wird auch der Stopbefehl nochmals gesendet.
Wünsche dir gutes Gelingen.
Gruß
Thomas
Hallo, Jochen,
es ist zwar ein alter Hut, aber hast Du die minimale Schaltzeit zwischen Befehlen auf wenigstens 10ms stehen? Der nicht ausgeführte Stop-Befehl machte mich stutzig. Wenn ich diesen Wert auf 0 setze, kann ich auf solche Effekte warten.
Vielleicht kannst Du mal in dieser Richtung experimentieren.
Freundliche Grüße aus LE
Dieter
Hallo Dieter !
Wie stellt man denn die minimale Schaltzeit zwischen Befehlen ein ? Ist das eine Lenz- Besonderheit ?
Das Durchfahren von Loks in Folge-FS'en habe ich auch zuweilen. Ich nehme an, dass nach dem Umbau auf andere RM- Erfassung [Kabasoft] die Erfassung stabiler wird und die Loks im Bremsabschnitt absolut zuverlässig erkannt werden.
Ich werde den Verdacht nicht los, dass dort der Hund begraben liegt.
Mit einem Sniffer oder gar Logikanayser, - da kann man gleich Entwicklungsarbeit leisten... für Normalsterbliche nicht umsetzbar, - finde ich. Aber ich werde den Thread aufmerksam verfolgen bzw. auf der Schulung im Mai die Frage dazu stellen.
Gute Nacht zusammen !
Mein Lötkolben ist schon kalt, - und ich ebenfalls müde :D
Gruß Harald
Hallo Harald,
mit einem zweiten Rechner, den haben ja viele im Haus, und zwei seriellen Schnittstellen an diesem Rechner. Zweitrechner zwischen dem MoBa-Rechner und Zentrale geschaltet, notiert der Rechner die Kommunikation. Software gibt´s dafür auch zuhauf von "van Lau" im Internet, zumindest fuer den Hobbybetrieb, z. B. BinTerm.
Mit dem "Mitschneiden" des Protokolls zur Fehlersuche macht man sich auch nicht strafbar, Reengeneering kann man eh auch anders machen.
Nix mit MoBa-Entwicklungssysteme fuer mehrere Millionen Euronen. ;)
Intermodellbau Dortmund ist dieses Jahr nicht drin, Freitag keenen Urlaub, Sa und So ist´s mir zu voll.
So, jetzt aendere ich meine Lage Richtung "Horizontale", (ohne Hintergedanken), ist Zeit, nachher geht der Trott wieder los.
Hallo Karl, hallo MoBa - Freunde !
Das war mir nicht bekannt, dass es solche "Mithörprogramme" gibt. Aber eigentlich ist das auch nur die halbe Wahrheit...
Gut nun kann ich den Telegrammstrom auf der seiellen Verbindung mithören,- und wie interpretiere ich den ? Und vor allem, - wie setzt die Zentrale das auf dem Energiedatenbus, Eingang zu den Boostern etc., um ?
Versteht Ihr wie ich das meine ?!
Gruß Harald
Guten Tag, liebe Diskutanten,
zu diesem Thema möchte ich mal eine Vermutung einbringen, die ich aufgrund der
genannten Probleme - Schaltzeit und Weiterfahrt der Lok trotz "Halt" - angestellt habe.
Da ich kein PC-Freak bin, möchte ich hier ein Sicherungsprogramm, wie z.B. Norton, als Fehlerquelle vermuten, das im Hintergrund den Arbeitsspeicher so belasten, dass die von WDP gesendeten Befehle in der Zentrale verzögert oder garnicht ankommen.
Ich selbst hatte gelegentlich ähnliche Ereignisse wie von Jochen geschildert, habe mich aber nicht weiter
damit beschäftigt, da es beim nächsten Start wieder normal lief. Habe aber für mich die Erklärung mit den
bei mir im Hintergrund laufenden Sicherungen, die laut Windows Task-Manager den Arbeitsspeicher auf meinem
Laptop gelegentlich stark belasten, gefunden.
Hallo zusammen,
immer wieder haben wir die Empfehlung ausgesprochen, dass auf einem Moba-PC, wo es auf zeitkritische Reaktionen ankommt, keine anderen Programme im Hintergrund laufen sollten.
Zu diesem Programmen gehören insbesondere die Antivirenprogramme, die Internetverbindungen mit automatischen Updatefunktionen, Sicherungsprogramme usw.
Wenn man also auf eine gut funktionieren Modellbahnsteuerung Wert legt, dann sollten diese Programme nicht zusammen mit einer Moba-Steuerungssoftware laufen.
In der Industrie oder Medizintechnik wäre dies nicht vorstellbar, denn dort kommt es doch auch auf sofortige Reaktionen der Soft- und Hardware an.
Daher verstehe ich nicht, dass man bei der Moba-Steuerung diese nicht erforderlichen Programme im Hintergrund laufen lassen muss und dann aber gleichzeitig der Moba-Steuerungssoftware die Schuld gibt. Sucht sie doch einmal bei Euch und nicht immer, wie das ja heute so üblich ist, immer bei den anderen.
Wenn ich mit meiner Moba fahren, dann brauche ich keine Internertverbindung, keine Antivirenprogramme oder sonstige im Hintergrund laufende Programme, die den sehr interessanten Moba-Betrieb auf meiner Anlage trüben. Alles zu seiner Zeit und nicht immer alles gleichzeitig und dann mit den nicht gewünschten Auswirkungen. Bei mir läuft die Moba immer einwandfrei und ohne Fehler (außer denen, die ich selbst eingebaut habe oder bei den Betatests einbauen muss, um z. B. Fehler zu finden).
Denkt einmal über meine Zeilen nach, und so wünsche ich allen viel Freude mit der Modellbahn. :) :)
Hallo Karlheinz !
Grundsätzlich stimme ich Dir nahezu uneingeschränkt zu, - aber dann würde ich auch konsquenterweise auf Linux oder z. B. HP-UX [Unix-Maschine], zurückgreifen. Da gibt es solche Probleme nicht.
Aber Alternativ kann man auf dem gleichen Rechner auch zwei Betriebssysteme installieren z. B. Win XP für den allgemeinen "Kram" und W2K für die MoBa und nur dafür. Das wäre doch ein Weg.....
Oder die im Hintergrund gestarteten Programme vor Betrieb der MoBa entsprechend terminieren.
Es geht ja hier nicht um Schuldzuweisungen..... ;D sondern wir wollen alle unseren möglichst uneingeschränkten Spaß :D :D
Gruß Harald
Hallo Harald,
ZitatGrundsätzlich stimme ich Dir nahezu uneingeschränkt zu, - aber dann würde ich auch konsquenterweise auf Linux oder z. B. HP-UX [Unix-Maschine], zurückgreifen. Da gibt es solche Probleme nicht.
und wie willst Du dort WDP zum Laufen bringen? ???
Hallo zusammen,
ich fange jetzt mal bei den letzten Beiträgen an, um zumindest in einem Punkt Klarheit zu schaffen: Auf meinem Moba-Rechner, wie er im Profil beschrieben ist, läuft nichts, aber auch garnichts, ausser WDP. Betriebssystem ist Windows XP, Home Editition, SP 2. Es ist auch keine Internet-Verbindung, und kein Netzwerkanschluss vorhanden. Ganz einfach: Stand Allone.
@ Markus
Danke für Deine Auskünfte, aber leider sind sie doch ein bisschen mager. Ich habe natürlich damit gerechnet, dass ich die gewünschten Daten in Form einer PN erhalte, von wem auch immer. Vor allem Deine Aussage: " mehr kann, und möchte ich hier nicht sagen" betrübt mich etwas. Natürlich interessieren solche Details, die ich wissen möchte, nicht alle Forumsteilnehmer, aber wie wäre es denn etwas präziser mit einer PN?
@Frank und Karl
Ich werde Eure Vorschläge mit einem Schnittstellen-Sniffer realisieren, aber mit einem extra PC. Das erachte ich auch für sicherer. Da muss mein Sohn mit seinem Laptop anrücken, weil ich meinen Büro-PC laufend anderweitig benötige. Ich werde über Ergebnisse berichten. Frank, Dir schicke ich noch eine PN.
@ Dieter
Meine Sendepause steht auf 10 msec, habe aber erfolglos auch schon 30 msec ausprobiert, wobei ich bis heute nicht genau weiss, von wem an wen da eigentlich eine Sendepause verordnet wird, und wie diese im Gesamtsystem wirkt.
@Thomas
Dir habe ich schon am Telefon geantwortet. In manchen Fahrstrassen kann man den Trick mit zweifachem Weichenstellimpuls realisieren, und da funktioniert das auch bestens, ist aber nicht in allen FS anwendbar.
Herzliche Grüsse an alle, bis demnächst
Jochen
Hallo Karlheinz !
Das habe ich aber doch garnicht in Abrede gestellt.
ZitatIn der Industrie oder Medizintechnik wäre dies nicht vorstellbar, denn dort kommt es doch auch auf sofortige Reaktionen der Soft- und Hardware an.
Nur wenn Du auf Applikationen aus der Medizintechnik oder z. B. Automatisierungstechnik abzielst, dann muß man auch konsquenterweise geeignete Betriebssystem auswählen und die Produkte dafür entwickeln. Windows ist nun mal für eine breite Anwenderschicht entwickelt worden um eine hohe Marktdurchdringung zu erreichen.
Da ich selber beruflich mit Leitsystemen befasst bin, sind mir die Probleme u. a. mit MS- Windows Betriebssystemen und den ganzen mit auf den Rechnern aufgesattelten Programmen und Appikationen, sehr wohl bekannt.
Folgerichtig sind Automatisierungskomponenten und Umgebungen natürlich nicht zu dem Preis einer MoBa- Steuerung erhältlich ;D .
D. h. den MoBa- Rechner "abspecken" oder eine Stand-Alone- Maschine für genau diesen Zweck benutzen.
Gruß Harald
Hallo, Jochen,
entschuldige, dass ich mich erst heute melde.
Zur Sendepause:
Bei den meisten Zentralen ist die Vorgabe ain WDP 0 ms. Es ist die Pause zwischen 2 Befehlen, die an die Zentrale geschickt werden. Bei Lenz ist die Voreinstellung 10 ms i. a. ausreichend. Meine Rückfrage bei der Lenz-hotline brachte keinen Aufschluss. Man war der Ansicht, dass keine Pause erforderlich sei. Fakt ist, dass bei Einstellung von 0 Befehle verloren gehen. Die Lok hält dann manchmal eben nicht am signal, obwohl der Schieberegler in WDP auf 0 steht. Am LH 100 war eben nicht 0, also fährt die Lok weiter. Das konnte ich eindeutig reproduzieren. Der nur verlorene Stop-Befehl ist vermutlich ein Trugschluss, da merkt man es nur am besten. Bei mir sind die 10 ms allerdings ausreichend.
Da Du den Wert auf 30 erhöht hast, kommt das Ganze aber wohl aus einer anderen Ecke.
Freundliche Grüße aus LE
Dieter
Hallo Dieter,
Es ist bei genau so, wie Du es auch beschrieben hast: Im Lok-Control steht alles auf Null, die Lok(s) halten aber nicht am Ziel-ZNF. Dirk meinte, dass, wenn alle WDP-Regler af Null stehen, WDP den Befehl auch gesendet hat. Ich glaube ihm das, und vermute, dass der Fehler in oder an der LENZ-Zentrale liegt, die den Stopbefehl nicht an die Booster gesendet hat, warum auch immer. Der Beweis ist ja, dass in der beschriebenen Situation am Handregler LH100 noch eine bestimmte Fahrstufe abzulesen ist, die auch zur Lokgeschwindigkeit passt.
Was die Auskünfte von der LENZ-Hotline anbelangt, bin ich auch absolut nicht zufrieden. Man antwortet zwar zeitnah, der sachliche Inhalt der Auskünfte ist aber eher mager. Ich möchte hier nicht weiter ins Detail gehen.
Wenn es etwas Neues zu berichten gibt, melde ich mich wieder.
Viele Grüsse aus dem heute sehr stürmischen Schwabenland.
Jochen
Hallo, Jochen,
mir fällt bzgl. der Weichen gerade noch etwas ein:
Hast Du mal probiert, wie die betreffenden Weichen bei Anklicken im GB schalten im Vergleich zur Betätigung via Handregler. Ich habe an einem 8-fach Roco-Decoder Weichen mit Motorantrieb. Dieser Decoder hat die unangenehme Eigenschaft, dass er keine einstellbare Schaltzeit hat. Mit der Lenz-Zentrale gab es keinerlei Probleme. Bei einer Zentrale mit IB-Emulation schalteten diese Weichen nicht mehr sauber (nur beim Handregler klappte es). Bei der IB kann man in WDP aber die min. Schaltzeiten vorgeben (aber nicht bei Lenz). Ein ordentlicher Decoder läßt aber auch eine Einstellung zu. Vielleicht kannst Du dort mal drehen.
Auch der Strombedarf der Weiche kann Ursache sein. Speist Du die Weichen übrigens mit DCC-Strom oder mit Fremdspannung. Beim erstgenannten Fall ist es durchaus möglich, dass infolge steigender Last die Boosterspannung so weit sinkt, dass manche Weichen nicht mehr sicher geschaltet werden.
Ich hoffe, dass ich Dir ein bisschen WE-Beschäftigung geben konnte.
Viel Spass und beste Grüße aus LE
Dieter
Hallo zusammen,
ZitatBei der IB kann man in WDP aber die min. Schaltzeiten vorgeben (aber nicht bei Lenz).
"aber nicht bei der Lenz-Zentrale", hätte es heissen müssen ;). Beim Lenz wird die Schaltzeit im Decoder hinterlegt, ist aber nur für Motorweichen oder Lichtsignale erforderlich.
Bei Jochen sind die Schaltzeiten auch im Decoder hinterlegt.
Viele Grüße
Frank
Hallo Dieter,
Frank war wieder einmal schneller, und hat die Fragen, die sich Dir stellten, schon zum grossen Teil beantwortet.
Natürlich schalte ich meine Weichen mit externer Wechselspannung aus einem steifen Ringkerntrafo, bei dem die Spannung nicht zusammen bricht.
Zur Digitalsignal-Versorgung meiner Weichendecoder-Boards (ich habe 36 Weichenanschlüsse auf einer Doppeleuropakarte) habe ich einen extra Booster LV100 eingesetzt, der nicht an die E-Leitung angeschlossen ist. Von hier aus ist alles wasserdicht. Ich schaue mir aber jetzt nochmal die Software meiner Weichendecoder ganz genau an, ob ich darin vielleicht doch noch einen bislang nicht entdeckten Wurm finde. Das wär natürlich gut, wenn das die Lösung aller Weichenprobleme bringen würde. Ich werde ggf. (ehrlich) darüber berichten, wenn ich da was finde.
Das Problem mit den weiterfahrenden Loks besteht immer noch. Ich habe vor eine zweite Zentrale einzusetzen, vielleicht ist das doch ein Timingproblem (LENZ-seitig), dass der Stopbefehl nicht an die Lok(s) weiter gegeben wird. Auch über diesen Versuch werde ich wieder berichten.
Schönes Wochenende und viele Grüsse
Jochen
ZitatMeine ROCO-Weichen schlagen nach meinen Messungen innerhalb von 15 bis 20 msec um, und dann schaltet die Endabschaltung ja sowieso den Strom ab.
ZitatNatürlich schalte ich meine Weichen mit externer Wechselspannung aus einem steifen Ringkerntrafo, bei dem die Spannung nicht zusammen bricht.
Wechselspannung - Periode = 20 ms, eine Halbwelle pos. 10 ms, eine Halbwelle neg. 10 ms.
Schaltzeit der Weichen <= eine Periode.
Hallo Jochen,
demnach dürftest Du absolut keine Probleme mit den Weichen-Schaltzeiten haben, die Rocco-Weichen scheinen kaum eine physik. Masse, keine Reibung, kaum Weg usw. zu haben, anscheinend aber einen wahnsinnig hohen Strom.
Irgendwie scheint mir das hier alles im Thread groesstenteils unglaubwürdig.
(Na ja, wenn´s "gemessen" wurde muss ich es wohl glauben) ;)
Hallo Karl,
alle unsere MA-Weichen , aber nur die am Wechselstrom, Schalten mit limitierter Bestromungszeit von 100 ms (also max. 5 Perioden) ! So kurz ist die Schaltzeit z.B. per Default am LS150 eingestellt. Und RoCo-Line Weichen schalten aus Erfahrung am schnellsten , leisesten und Widerstandsärmsten. Die 25 ms (~ eine 50Hz Periode) liegen aus meiner Sicht durchaus im Bereich des Glaubwürdigen.
Was diesen Thread etwas undurchschaubar macht, ist das hier (so bzw. zu) viele Dinge gleichzeitig angegangen werden.
Beim Lenz-System hätte es auch die Möglichkeit gegeben, z.B erst mal ein zweites Interface an das eine XpressNet der derselben Zentrale anzuschliessen.
Ich glaube Jochen möchte vorrangig sein System ans Laufen bringen, und die "Ursachenforschung"
aufs notwenige Einschränken. Für mich genauso glaubwürdig.
Viele Grüße
Frank
Hallo,
bei 50 Hz ist eine Periode immer noch 20 ms und nichts anderes.
Es lohnt sich hier nicht noch Antworten zu geben, da irgendwie, wenn auch laienhaft, alles scheinbar verteidigungsmaessig in Halbwissen und oft auch in sog. unverstaendlichem Fachwissenoberchinesisch geschrieben wird.
Na, dann viel Spass bei der "Ursachenforschung", ich halte mich ab jetzt heraus.
Hallo,
vielleicht gestatten Sie den Hinweis auf die Ausgangsfrage. Jochen Blank hat geschrieben:
Zitate:
ich kämpfe bei meiner Moba derzeit im ZFA-Betrieb mit zwei Problemen
Alle Weichen schalten mit der Maus, mit dem Handregler, und bei "Stellen und Fahren" immer korrekt.
Zitate Ende.
Es handelt sich demnach um ein Problem der Weichenschaltung nur bei Anwendung der ZFA.
Viel Spaß bei der Ursachenforschung.
Hallo Karl,
ich weiss nicht warum Du Dich in diesen Thread eingeklinkt hast, wenn Du sachlich nichts beizutragen hast. Polemik hilft nie weiter. Ich weiss ja nicht was Deine Profession ist, ich bin seit über 40 Jahren Elektronik-Ingenieur, und bewege mich mit meinen Aussagen immer auf dem Boden gesicherter Tatsachen. Vielleicht hast Du ein Oszilloskop, und kannst damit umgehen, dann schliess doch mal eine ROCO HO-Weiche an und schaue wie lange es dauert vom Einschalten bis die Endabschalter den Spulenstrom abschalten. Wenn Du richtig misst, wirst 15-25 msec sehen, bei Wechselspannung so ungefähr eine Periode, bei Gleichspannung sind sie noch etwas schneller.
Extra für Dich füge ich hier ein Oszillogramm von der Ansteuerung einer endabgeschalteten ROCO-Weiche bei, und ein weiteres wie die Weichenansteuerung meiner Decoder bei einer Weiche ohne Endabschaltung aussieht: ca. 13 Perioden im 50 Hz-Netz, genau gesagt sind es 256 msec. Diese Zeit ist eigentlich unnötig lang, ich werde sie auf 128 msec verkürzen
Vielleicht liest Du nochmal meine früheren Beiträge, ob da was anderes drin steht. Um weitere physikalische Belehrungen überflüssig zu machen sage ich hier noch, dass ich schon weiss, dass Kraft = Masse mal Beschleunigung ist, und dass der Strom in einer Induktivität der Spannung nacheilt. Beide Dinge sind bei einem magnetischen Weichenantrieb relevante Daten.
An Beiträgen von WDP-Anwendern, die in der Sache weiterhelfen können, bin ich nach wie vor interessiert.
Beste Grüsse
Jochen
Hallo Kollegen !
Ich weiß ja nicht ob es von Belang ist, - aber mit dem Update auf 2009 Premium habe ich mir auch eine TAMS MC geleistet und dabei folgendes festgestellt:
1. TAMS upgedatet auf vorgeschriebene Firmware; TAMS Com-Schnittstellen Emulator von CD installiert; belegt bei mir Com 15; in der Systemeinstellung eingetragen und alle Loks für Fahrbetrieb konvertiert und in TAMS geladen.
2. Mit TAMS manuell gefahren >> alles einwadfrei die 185'er lief sauber und reagierte einwandfrei auf die Komandos.
3. Mit Windigipet manuell gesteuert >> es ging ca. 1 Minute gut danach fuhr die Lok mit geringer Geschwindigkeit weiter ohne auf irgendwelche Befehle zu reagieren !!
4. Systemeinstellungen geöffnet Com 15 stand auf 9600 Baud und FiFo Off, [Laut Hanbuch unerheblich da Kopplung über USB und WDP bestimmt mit Vorgegebenen 57600 Baud den Datenaustausch].
5. FiFo trotzdem eingeschaltet und Com Baudrate des Rechers ebenfalls auf 57600 Baud gesetzt.
6. Reboot Rechner, Neustart aller Zentralen, WDP gestartet und die Welt war in Ordnung !!!!
Wie ist das zu erklären ? Stimmen die Hinweise im Buch und TAMS- Angaben nicht ? Ggf. auch ein Hinweis für Kollegen Blank !? Wer weiss ?
Ich habe in meiner 25 jährigen Betriebserfahrung als Ing. Automatisierungstechnik auch allerlei Seltsame Dinge mit weitaus hochtechnischerem Gerät erlebt.... man lernt nie aus.... ;)
Gruß an Alle
Harald