Zitat von Gast_001Im ersten Fluke-Bild mit ohne Decoder, würde ich die Last als "induktiv" bezeichnen: Das Signal überschwingt gewaltig, und da ohne das der Herr Kühn in Reichweite wäre . Im zweiten Bild (Mit Decoder) sieht man, das unter zunehmender ohmscher Last sich die Verformungen ganz schnell normalisieren, so dass man in der Praxis keine Angst vor Induktivität auf leerem Gleis haben muss.
Mit ohmschen Lasten kann ich gerne Nachliefern. Was mich etwas stört, sind die auf den Anzeigebereich begrenzten Werteermittlungen.
Zitat von Gast_001 Im dritten Bild sieht man ein typisch kapazitives Verhalten. Hier würde ich im ersten Augenblick anfangen , mir Sorgen um die Funktion zumindest kurzflankiger Protokolle wie MM oder SX zu machen , aber dann würde ich drauf spekulieren, das sobald ein ohmscher Verbraucher (Lok) draufsteht , das Signal auch hierbei wieder eher rechteckig wird.
Das hatten wir hier schon einmal, mit dem Ergebnis daß unempfindliche Zentralen (z.B. 6021/Tams+B4) keine Funktionsstörungen ergeben. Ein anderes Problem hat sich nun gezeigt: normalerweise müßte beim künstlichen Kurzschluß mit einerm Schraubendreher ein Popup-Fenster auf die Überlastsituation hinweisen. Dies ist bei meiner Zentrale nicht der Fall. Daher an dieser Stelle die Frage, ob dies bei SW-Version 1.4.0. so üblich ist?
@Hubert: Du erwartest eine schnellere Zugriffszeit für eine Zentrale mit diesem Funktionsumfang? Wie willst Du dies realisieren?
Ich muss zugeben, das dieses ständige "hab ich jetzt die Schaltfläche getroffen und dauert's nur wieder etwas oder muss ich noch mal klicken" Gewarte auch etwas auf den Zeiger geht.
Ich kapier das auch nicht so richtig, eigentlich müsste die Büchse genug Rechenleistung haben um das schneller zu machen. Oder ist die in SW Java programmiert?
Zitat von SoulmanIch muss zugeben, das dieses ständige "hab ich jetzt die Schaltfläche getroffen und dauert's nur wieder etwas oder muss ich noch mal klicken" Gewarte auch etwas auf den Zeiger geht.
Das scheint prinzipiell ein Problem von Touch ist aber auch bei Mouse-Oberflächen Usus.
Wenn man nach dem Touch-Down (oder Klick-Down) sofort die Funktion ausführen will, blockiert sich der Programmier oder auch das OS die Möglichkeit auch ein anchliessenden Ziehen und dann erst auswerten ("drag/move") zu erkennen, da man das Event "Down" ja auf jeden Fall auswerten würde, auch wenn "nur" ein Drag and Up woanders eingegeben wurde.
Deswegen haben wir heute besonders am Touch erst die eigentliche Reaktion nach dem Up des Fingers (bzw. der Mouse-Taste). Mischformen : Wenn der Finger (bzw. die Taste) eine lange halbe Sekunde o.ä. nicht weitergezogen wurde sind auch üblich ("Timeout"). Alles in allem eine für eine Steuerung mit Echtzeitanspruch ziemlich klebrige Angelegenheit. Besonders wenn wir doch immer mal wieder die Untergrenze eines Timeouts ausloten, funkt nicht, und wir machen die nächsten male wieder was länger.
Beim Touch in der zeitkritischen Remote-Anwendung gibt es wohl deswegen ein Trend zur vermehrten aber dann differenzierteren Gesten Steuerung. Z.B. ein Knob, der bereits nach Schieben eines bestimmten Weges (in eine ansonsten ungenutze Richtung) reagiert, kann schneller reagieren, als einer der erst auf Loslassen oder Timeout reagiert.
Alte traditionellen MoBa-Steuerungen reagieren meistens sofort auf Touch-Down wenn ein dedizierter Knob vorhanden. Und auch für die überlebenswichtigen Lokfunktionen haben an der CS2 deswegen? eiegene echte Tasten.
Ich würde mal drauf achten, was am jeweiligen Touch alles verspätet oder erst nach loslassen reagiert. Mit scheint das bei einigen sonstigen Devices wie Smartphones (Spiele ausgenommen) zur Zeit ne beachtliche Menge.
Psychologisch wird auch das als schnell empfunden, was uns (unterbewusst) noch kalkulierbar scheint, auch wenn es etwas anstrengend(er) ist. Wenn ein solche Verzögerung konstant ist, kalkulieren wir sie mit zunehmder Gewöhnung ein, und sollten sie bald für schnell im Sinne von sofort halten, auch wenn sie absolut recht verzögert ist.
#56 von
wolfgang58
(
gelöscht
)
, 27.04.2011 02:00
Zitat von Gast_001
Zitat von SoulmanIch muss zugeben, das dieses ständige "hab ich jetzt die Schaltfläche getroffen und dauert's nur wieder etwas oder muss ich noch mal klicken" Gewarte auch etwas auf den Zeiger geht.
Das scheint prinzipiell ein Problem von Touch ist aber auch bei Mouse-Oberflächen Usus.
Wenn man nach dem Touch-Down (oder Klick-Down) sofort die Funktion ausführen will, blockiert sich der Programmier oder auch das OS die Möglichkeit auch ein anchliessenden Ziehen und dann erst auswerten ("drag/move") zu erkennen, da man das Event "Down" ja auf jeden Fall auswerten würde, auch wenn "nur" ein Drag and Up woanders eingegeben wurde.
Deswegen haben wir heute besonders am Touch erst die eigentliche Reaktion nach dem Up des Fingers (bzw. der Mouse-Taste). Mischformen : Wenn der Finger (bzw. die Taste) eine lange halbe Sekunde o.ä. nicht weitergezogen wurde sind auch üblich ("Timeout"). Alles in allem eine für eine Steuerung mit Echtzeitanspruch ziemlich klebrige Angelegenheit. Besonders wenn wir doch immer mal wieder die Untergrenze eines Timeouts ausloten, funkt nicht, und wir machen die nächsten male wieder was länger.
Beim Touch in der zeitkritischen Remote-Anwendung gibt es wohl deswegen ein Trend zur vermehrten aber dann differenzierteren Gesten Steuerung. Z.B. ein Knob, der bereits nach Schieben eines bestimmten Weges (in eine ansonsten ungenutze Richtung) reagiert, kann schneller reagieren, als einer der erst auf Loslassen oder Timeout reagiert.
Alte traditionellen MoBa-Steuerungen reagieren meistens sofort auf Touch-Down wenn ein dedizierter Knob vorhanden. Und auch für die überlebenswichtigen Lokfunktionen haben an der CS2 deswegen? eiegene echte Tasten.
Ich würde mal drauf achten, was am jeweiligen Touch alles verspätet oder erst nach loslassen reagiert. Mit scheint das bei einigen sonstigen Devices wie Smartphones (Spiele ausgenommen) zur Zeit ne beachtliche Menge.
Psychologisch wird auch das als schnell empfunden, was uns (unterbewusst) noch kalkulierbar scheint, auch wenn es etwas anstrengend(er) ist. Wenn ein solche Verzögerung konstant ist, kalkulieren wir sie mit zunehmder Gewöhnung ein, und sollten sie bald für schnell im Sinne von sofort halten, auch wenn sie absolut recht verzögert ist.
Grüsse Frank
Vielen Dank lieber Frank für die einprägsame und nachvollziehbare Beschreibung dieses komplexen Sachverhaltes.
(Leider musste ich beim Lesen durch gefühlvolles auf- und abscrollen mich permanent vergewissern, daß ich mich gerade nicht in einem Box- oder sonstigen Nahkampf-Forum befinde, sondern immer noch im Stummiforum! Deine Beschreibung war so sensitiv vorgetragen, daß ich bereits die Knöchel knacken ließ )
Hallo Frank, um die Verzögerung mit dem CS2-Touch zu umgehen, könnte ich mir folgendes vorstellen:
- die 6021-Zentrale durch ein WLAN-Modul aufwerten (Ansteckteil) - Ei-Fon, Ei-Pad (und sonstige Ei-Geräte) mit dem Softwareumfang der CS2 ausstatten (für 4,95 € )
Damit hätten die Modellbahner alle Möglichkeiten, je nach Gusto, entweder Knöpfchen drücken und Regler drehen und/oder wireless und mit Finger oder Stift auf dem Bildschirm zu steuern.
Leider ist es dafür zu spät, denn die CS2 wäre dann arbeitslos, und wer will das schon
Abschließend möchte ich mich noch entschuldigen, dass dieser Beitrag am Thema vorbeigeht und wünsche weitere interessante Diskussionen über die Modellbahn.
Zitat von SoulmanIch muss zugeben, das dieses ständige "hab ich jetzt die Schaltfläche getroffen und dauert's nur wieder etwas oder muss ich noch mal klicken" Gewarte auch etwas auf den Zeiger geht.
Das scheint prinzipiell ein Problem von Touch ist aber auch bei Mouse-Oberflächen Usus.
Moin Frank,
sorry, wenn ich das so hart sage, aber diese Aussage ist einfach nur falsch.
Es stimt zwar, das vele Geräte nur verzögert reagieren, aber - und das war hier die Kritik - die Ungewißheit "hab ich jetzt die Schaltfläche getroffen und dauert's nur wieder etwas oder muss ich noch mal klicken", ist kein prinzielles Problem von Touch & Co, wie man z. B. schön an der ECoS sehen kann. Der Anwender weiß immer, ob die ECoS auf den Druck einer Schaltfläche reagiert, weil die Schaltfläche selbst - und zwar sofort und ohne Verzögerung - anzeigt, ob die Anwenderaktion angenommen wurde.
Zitat von AndiDer Anwender weiß immer, ob die ECoS auf den Druck einer Schaltfläche reagiert, weil die Schaltfläche selbst - und zwar sofort und ohne Verzögerung - anzeigt, ob die Anwenderaktion angenommen wurde.
Dem stimme ich zu. Das galt und gilt sogar für die CS1 reloaded, deren betagter Hardware ESU mit dem Upgrade frischen Wind einhauchte. Die Oberfläche ist angenehm flink zu bedienen.
Hier haben die Märklin Entwickler noch erheblich nachzubessern!
Im Detail: Die meisten Entwicklungsumgebungen legen dem Programierer eine solche Verzögerung zwecks ehrhalt sontiger Gesten nahe. Das es auch anders geht , z.B. Spiele, habe ich ja auch geschrieben. Auch gibt es neuere Tpuch-Tastaturen, bei denen man das Wort in einem "abfährt" ansatt jeden Buchstaben einzeln anzutippen.
Ich wolle doch nur dazu aufforden, sein jeweiliges Gerät im Zweifelsfall oder auch nur zum Spass mal dahingehend zu testen, es muss nciht immer der Prozessor sein. Nix gegen die ECos
ZitatDer Anwender weiß immer, ob die ECoS auf den Druck einer Schaltfläche reagiert, weil die Schaltfläche selbst - und zwar sofort und ohne Verzögerung - anzeigt, ob die Anwenderaktion angenommen wurde.
So ist es. Auch beim Commander geht das sehr fix. Kein Problem. Die CS2 braucht z.B. ewig beim Aufruf der Lokliste. Grüße Tommes
vielen Dank für Deinen Beitrag, den ich noch etwas ergänzen möchte:
Zitat von HubertHallo Frank, um die Verzögerung mit dem CS2-Touch zu umgehen, könnte ich mir folgendes vorstellen: - die 6021-Zentrale durch ein WLAN-Modul aufwerten (Ansteckteil) - Ei-Fon, Ei-Pad (und sonstige Ei-Geräte) mit dem Softwareumfang der CS2 ausstatten (für 4,95 € ) Damit hätten die Modellbahner alle Möglichkeiten, je nach Gusto, entweder Knöpfchen drücken und Regler drehen und/oder wireless und mit Finger oder Stift auf dem Bildschirm zu steuern. Leider ist es dafür zu spät, denn die CS2 wäre dann arbeitslos, und wer will das schon
Mir persönlich gefiele es, wenn seitens Märklin eine reine Programmiereinheit für mfx-Modelle auf den Markt käme. Dies hätte den Vorteil, daß man weiterhin mit der Zentrale der Wahl (bei mir 6021 und TamsEC+B4) auch nach dem Programmieren sonst unzugänglicher Register fahren kann. Ferner gefällt mir die eingangs beobachtete Überempfindlichkeit der CS2 nicht. Doch das ist der Preis der Technik. Unter identischen Bedingungen sind soeben genannte Zentralen erheblich robuster.
Zitat von Hubert Abschließend möchte ich mich noch entschuldigen, dass dieser Beitrag am Thema vorbeigeht und wünsche weitere interessante Diskussionen über die Modellbahn.
Macht nix, immerhin hast Du neue Aspekte hereingebracht, die um einige Ecken auch mit Messungen (Beobachtungen ohne Meßgerät) zu tun haben
.
halbe Sekunde o.ä. nicht weitergezogen wurde sind auch üblich ("Timeout"). Alles in allem eine für eine Steuerung mit Echtzeitanspruch ziemlich klebrige Angelegenheit. Besonders wenn wir doch immer mal wieder die Untergrenze eines Timeouts ausloten, funkt nicht, und wir machen die nächsten male wieder was länger.
wenn ein dedizierter Knob vorhanden. Und auch für die überlebenswichtigen Lokfunktionen haben an der CS2 deswegen? eiegene echte Tasten.
