Anzeige:
THEMA: Lastregelung DHP160
THEMA: Lastregelung DHP160
N-Jack - 03.12.10 09:44
Hallo,
ich habe/hatte ein Problem mit meinem Arnold ICE3 mit DHP160 Decoder in Verbindung mit Traincontroller. Dabei ging es darum, dass der Zug am Ende, bzw. am Anfang eines Blockes stehen blieb, obwohl dieser hätte weiter fahren müssen. Da der eine Block ein Gefälle hat, ist die Vermutung, dass der Zug schneller fährt als der Computer glaubt. Hinzu kommt, dass in diesem Block noch ein Zugfahrtwechsel stattfindet. Hier der Link des entsprechenden Threads im Freiwald/TC Forum:
http://www.freiwald.com/forum/viewtopic.php?f=5&t=14006
Die Frage, die sich jetzt mir stellt, gibt es hier evtl. Aspekte der Lastregelung beim DHP160. Ich habe die entsprechende Decodereinstellung auf 1 stehen, da die Anfahrverzögerung durch den Computer gesteuert wird. Ich habe auch die Triebwagen als schon den ganzen Verband ein gemessen. In anderen Blöcken verhält er sich auch so, wie er soll.
Ich hatte übrigens ein ähnliches Verhalten mit einem alten Arnold ET420. Hier liess sich das Problem lösen, indem ich für diesen Zug in dem Block eine Geschwindigkeitsbeschränkung eingerichtet hatte, damit die Grundgeschwindigkeit nicht zu hoch war. Bei dem ICE3 funktionierte dies nicht.
Schönen Gruß
Karsten
ich habe/hatte ein Problem mit meinem Arnold ICE3 mit DHP160 Decoder in Verbindung mit Traincontroller. Dabei ging es darum, dass der Zug am Ende, bzw. am Anfang eines Blockes stehen blieb, obwohl dieser hätte weiter fahren müssen. Da der eine Block ein Gefälle hat, ist die Vermutung, dass der Zug schneller fährt als der Computer glaubt. Hinzu kommt, dass in diesem Block noch ein Zugfahrtwechsel stattfindet. Hier der Link des entsprechenden Threads im Freiwald/TC Forum:
http://www.freiwald.com/forum/viewtopic.php?f=5&t=14006
Die Frage, die sich jetzt mir stellt, gibt es hier evtl. Aspekte der Lastregelung beim DHP160. Ich habe die entsprechende Decodereinstellung auf 1 stehen, da die Anfahrverzögerung durch den Computer gesteuert wird. Ich habe auch die Triebwagen als schon den ganzen Verband ein gemessen. In anderen Blöcken verhält er sich auch so, wie er soll.
Ich hatte übrigens ein ähnliches Verhalten mit einem alten Arnold ET420. Hier liess sich das Problem lösen, indem ich für diesen Zug in dem Block eine Geschwindigkeitsbeschränkung eingerichtet hatte, damit die Grundgeschwindigkeit nicht zu hoch war. Bei dem ICE3 funktionierte dies nicht.
Schönen Gruß
Karsten
HaNNoveraNer - 03.12.10 12:53
Hallo Karsten
Verstehe Dein Problem noch nicht richtig!?
Der Zug bleibt irgendwo in einem Block (was ist ein Block?) stehen, obwohl er weiterfahren müßte?
In diesem Block findet endet eine Zugfahrt und eine andere beginnt?
Ist ein Block ein Stop/Start Kontakt für die Fahrstraßen?
Sollen die Zugfahrten ineinander übergehen? D.h. der Zug am Ende der ersten Zugfahrt nicht anhalten, sondern gleich die 2. Zugfahrt fortsetzen?
Das klingt eher nach falschen Einstellungen im TC bei den Zugfahrten.
Erkennt der TC die Position des Zuges durch einen GBM oder nach Fahrzeit?
Kann nur Vermutungen anstellen, da ich den TC nicht habe.
LG
Thomas
Verstehe Dein Problem noch nicht richtig!?
Der Zug bleibt irgendwo in einem Block (was ist ein Block?) stehen, obwohl er weiterfahren müßte?
In diesem Block findet endet eine Zugfahrt und eine andere beginnt?
Ist ein Block ein Stop/Start Kontakt für die Fahrstraßen?
Sollen die Zugfahrten ineinander übergehen? D.h. der Zug am Ende der ersten Zugfahrt nicht anhalten, sondern gleich die 2. Zugfahrt fortsetzen?
Das klingt eher nach falschen Einstellungen im TC bei den Zugfahrten.
Erkennt der TC die Position des Zuges durch einen GBM oder nach Fahrzeit?
Kann nur Vermutungen anstellen, da ich den TC nicht habe.
LG
Thomas
Hallo Thomas,
für jemanden, der Traincontroller nicht kennt, ist es zugegebenermaßen etwas schwierig zu verstehen.
Ich versuche es mal kurz zu erklären, so dass es auch jemand versteht, der nicht mit TC vertraut ist.
Ich unterteile eine Strecke in TC in mehrere Abschnitte, also in Blöcke. Pro Block wird mind. 1 realer BM zugeordnet. In der Software habe ich jetzt die Möglichkeit Markierungen zu setzen, in diesem Fall ein Bremsmarkierung und eine Haltemarkierung. Im Prinzip sind dies virtuelle Melder. Diese Markierungen stehen in Relation zu dem dem Block zugeteilten realen Melder. Eine Bremsmarkierung hat einmal den Abstand, wo diese wirken soll und ein Rampe. Die Rampe ist die Strecke, in der die Geschwindigkeit verzögert wird. Erreicht der Zug die Haltemarkierung, wird der Stop ausgelöst, sofern dies erforderlich ist (z.B. keine Einfahrt in den nächsten Block oder ein planmässiger Halt). Der Abstand des Haltemelders zum Auslöser (Beginn des Blockes, bzw. da wo der reale Melder ausgelöst wird) ist üblicherweise der Abstand plus Rampe des Bremsmelders.
Damit dies funktioniert, muss jede Lok ein gemessen werden, damit der Computer das Fahrverhalten der Lok, bzw. der Züge kennt und eine ordnungsgemäße Berechnung der Fahrt durchführen kann.
Im aktuellen Fall gibt es jetzt auch die Vermutung, dass aufgrund der Tatsache, dass der Block, wo das Problem auftritt ein Gefälle aufweist, die Lastregelung des Decoders nicht richtig greift und der Zug daher minimal schneller ist als eigentlich vom Computer berechnet.
Da ich Züge in aller Regel nicht von Hand fahre, werden Zugfahrten definiert. Die starten in einem Block und enden in einem anderen Block. Je nach Anforderung kann ich aber Nachfolgezugfahrten definieren. Da es anscheinend zum oberen Problem kam, war eine Folgeursache, dass die nachfolgende Zugfahrt nicht gestartet werden konnte.
Ansonsten kann ich nur empfehlen den Thread im Freiwald Forum nachzulesen.
Ich hoffe, ich konnte dich aufschlauen.
Schönen Gruß
Karsten
für jemanden, der Traincontroller nicht kennt, ist es zugegebenermaßen etwas schwierig zu verstehen.
Ich versuche es mal kurz zu erklären, so dass es auch jemand versteht, der nicht mit TC vertraut ist.
Ich unterteile eine Strecke in TC in mehrere Abschnitte, also in Blöcke. Pro Block wird mind. 1 realer BM zugeordnet. In der Software habe ich jetzt die Möglichkeit Markierungen zu setzen, in diesem Fall ein Bremsmarkierung und eine Haltemarkierung. Im Prinzip sind dies virtuelle Melder. Diese Markierungen stehen in Relation zu dem dem Block zugeteilten realen Melder. Eine Bremsmarkierung hat einmal den Abstand, wo diese wirken soll und ein Rampe. Die Rampe ist die Strecke, in der die Geschwindigkeit verzögert wird. Erreicht der Zug die Haltemarkierung, wird der Stop ausgelöst, sofern dies erforderlich ist (z.B. keine Einfahrt in den nächsten Block oder ein planmässiger Halt). Der Abstand des Haltemelders zum Auslöser (Beginn des Blockes, bzw. da wo der reale Melder ausgelöst wird) ist üblicherweise der Abstand plus Rampe des Bremsmelders.
Damit dies funktioniert, muss jede Lok ein gemessen werden, damit der Computer das Fahrverhalten der Lok, bzw. der Züge kennt und eine ordnungsgemäße Berechnung der Fahrt durchführen kann.
Im aktuellen Fall gibt es jetzt auch die Vermutung, dass aufgrund der Tatsache, dass der Block, wo das Problem auftritt ein Gefälle aufweist, die Lastregelung des Decoders nicht richtig greift und der Zug daher minimal schneller ist als eigentlich vom Computer berechnet.
Da ich Züge in aller Regel nicht von Hand fahre, werden Zugfahrten definiert. Die starten in einem Block und enden in einem anderen Block. Je nach Anforderung kann ich aber Nachfolgezugfahrten definieren. Da es anscheinend zum oberen Problem kam, war eine Folgeursache, dass die nachfolgende Zugfahrt nicht gestartet werden konnte.
Ansonsten kann ich nur empfehlen den Thread im Freiwald Forum nachzulesen.
Ich hoffe, ich konnte dich aufschlauen.
Schönen Gruß
Karsten
Hallo Karsten,
ähnliches beobachte ich auf meiner Strecke auch, allerdings nur in einem von 4 Blöcken im Gefälle und nur mit einer Lok mit Fleischmann DCC Dekoder.
Ebenso kommt es bei Kurzschluss oder Überlastung zu, ich nenne es mal, Meldepausen, wobei ein Zug auf der Anlage dem Zug im TC etwas voraus ist, die virtuelle Stopstelle überfährt und sich als Geisterzug im nächsten Block wiederfindet.
Ich schiebe dann im TC die Züge einen Block nach vorne, dann pendelt es sich wieder ein.
In deinem Fall, ich verstehe es so, dass es nur EIN Zug in EINEM Block ist, würde ich probeweise mal die Bremsstrecke um 5 bis 10 Zentimeter verlängern.
Falls möglich würde ich ebenso probeweise den Dekoder durch einen anderen ersetzen, es kann auch am Zug, bzw. Motor selbst liegen.
LG Claus
ähnliches beobachte ich auf meiner Strecke auch, allerdings nur in einem von 4 Blöcken im Gefälle und nur mit einer Lok mit Fleischmann DCC Dekoder.
Ebenso kommt es bei Kurzschluss oder Überlastung zu, ich nenne es mal, Meldepausen, wobei ein Zug auf der Anlage dem Zug im TC etwas voraus ist, die virtuelle Stopstelle überfährt und sich als Geisterzug im nächsten Block wiederfindet.
Ich schiebe dann im TC die Züge einen Block nach vorne, dann pendelt es sich wieder ein.
In deinem Fall, ich verstehe es so, dass es nur EIN Zug in EINEM Block ist, würde ich probeweise mal die Bremsstrecke um 5 bis 10 Zentimeter verlängern.
Falls möglich würde ich ebenso probeweise den Dekoder durch einen anderen ersetzen, es kann auch am Zug, bzw. Motor selbst liegen.
LG Claus
Hallo Karsten,
ich kenne zwar den von dir verwendeten ICE3 nicht, aber mir ist unverständlich warum es mit anderen Loks/Zügen klappt und damit nicht.
- hat der ICE auch 2 Motorschwungmassen???
dann könnte das die Ursache für dein Problem sein.
Oder ist dein Block für den ICE zu kurz bemessen?
gruß
hajo
ich kenne zwar den von dir verwendeten ICE3 nicht, aber mir ist unverständlich warum es mit anderen Loks/Zügen klappt und damit nicht.
- hat der ICE auch 2 Motorschwungmassen???
dann könnte das die Ursache für dein Problem sein.
Oder ist dein Block für den ICE zu kurz bemessen?
gruß
hajo
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;