Hei Leute Ich hab ein Problem mit einer Applikation. Ich habe ein Programm geschrieben das unter anderem eine ModbusTCP-Kommunikation beinhaltet. Die Werte die ich aus den Modbus-Registern lese werden in einen Graph geschrieben und auf dem Gerät von dem ich die Daten habe alle 200 ms aktualisiert. Das heisst ich lese alle 200 ms Daten von diesem Gerät. Leider kommt es vor, dass diese Daten mehrfach in einer 200 ms Frequenz gelesen werden und ich dann 2(bzw auch manchmal 3) mal die gleichen Daten im Graph darstelle. Dies muss ich verhindern können! Hat jemand von euch eine Idee wie ich das Ganze verhindern kann? Momentan lese ich nur mit einem Timer alle 200 ms Werte(Ich muss auf eine Mutex warten, da ich ja auch schreiben kann, und will, und habe daher die Latenz). Kann mir bitte jemand helfen und mir einen Lösungsansatz liefern? Ich bin am verzweifeln. Gruss und Danke im voraus Farin
>Momentan lese ich nur mit einem Timer alle 200 ms Werte(
naja
push anstelle von pull verwenden
ansonsten:
ist ja 200ms zu wenig
wenn sich der wert alle 200ms ändern kann, musst du (min. alle 100ms
abfragen)
um zu erkennen, ob es immer noch die selbe messung ist, müsste halt
irgendwas mitgeschickt werden (zeit, zähler)
wenn beides nicht geht, geht es eben nicht..
(ausserdem ist TCP eh nicht echtzeitfähig, ...)
bei 200ms also vielleicht besser einfach immer den durchschnitt aller
werte die inerhalb einer sekunde kommen ausrechnen
und sich mit einer genauigkeit von 1 sekunde begnügen
Das geht leider nicht. Ich habe als Vorgabe eine Applikation die funktioniert, dessen Code aber nicht zur Verfügung steht. Genaueres: - Ich sollte alle 200 ms 4 Werte pro Signal lesen. (Dies ergibt eine Genauigkeit von 50 ms. Die Werte werden vom Gerät gesetzt) - Ich MUSS alle 200 ms lesen und habe als Identifikation der Pakete nur eine Modbus-Paket-id - Ich darf aber mal ein Paket löschen, wenn es duplizierte Information enthält. Ich weiss dass es irgendwie gehen muss! Bin ja sicherlich nicht der erste, der ein solches Problem hat... ;-)
ich würde mir irgendwie mehr Gedanken um fehlende Pakete, als um doppelte machen..
Fehlende Pakete sind eigentlich egal. Die Kommunikation ist soweit ausgereift, dass diese nicht auftreten bzw. für das Endprodukt egal sind.. Der Punkt ist, dass die Pakete die Fehlerhaft sind folgende Fehler zeigen(Bei Signalen die von 0 auf 1 wechseln beispielsweise!) -----___--_________ -----|--|-|-------- -----|--|-|-------- _____|--|_|-------- ... Dieser Sprung zurück ist inakzeptabel, da er das Resultat verfälscht und Missverständnisse aufkommen lässt. Das möchte ich verhindern. Unbedingt! Verlorene Information ist mir in erster Linie egal, da das Resultat auch ohne sie komplett wäre. Einzig doppelte Daten verfälschen es. ;-)
> dass die Pakete die Fehlerhaft sind folgende
doppelt oder fehlerhaft..
mir ist das jetzt zu dämlich..
wärst du in der Lage, dein Problem zu formulieren, hättest vermutlich
selber schon die Lösung..
Raphael B. schrieb: > Das geht leider nicht. Ich habe als Vorgabe eine Applikation die > funktioniert, dessen Code aber nicht zur Verfügung steht. Irgendeine Hilfe/annahme muss aber auch dieser Code haben. Entweder das Gerät schickt eine Messwert Identifikation mit, die dir gestattet festzustellen, dass du jetzt 2 mal hintereinander dieselben Messwerte oder alte gekriegt hast, oder der Code trifft die Annahme, dass sich der Wert nicht so schnell ändern kann, wie das in deiner Grafik zu sehen ist. Ist der Wert von 0 auf 1 gewechselt und fällt 50ms später wieder zurück auf 0 um gelich daraufhin wieder auf 1 zu gehen, dann ist das ein Fehler, weil das physikalisch gar nicht möglich ist (d.h. die Plausibilitätskontrolle der Daten filtert dieses kurzfristige Zurückfallen aus) Andere Möglichkeiten hast du nicht. Du kannst ja nicht zaubern.
Außerdem scheint mir das Fehlerbild auch nicht zur Beschreibung zu passen, doppelte Daten könne doch nicht eine peak sondern bestenfalls eine "Verlängerung" der Achse bewirken, auch ist mir schleierhaft wie man "ausversehen" etwas zweimal lesen kann, entweder das Gerät schickt alle 200ms etwas, dann kommt auch nur alle 200ms was an, oder man fragt alle 200ms ab, wo kommen dann die doppelten Daten her?
Also ich versuchs noch einmal... Ich frage bei einem Gerät ca alle 200 ms Daten an(Dies ist aufgrund von .Net Environment nicht sichergestellt) Pro Anfrage erhalte ich vier Werte die an einen Graphen angefügt werden. Das Problem ist, wenn diese 4 Werte doppelt kommen, können solche Peaks enstehen und das möchte ich gerne verhindern. Sorry für die ungenaue Fehlerbeschreibung. Wie gesagt der einzige Indikator der mir bleibt, ist eben diese Modbus-ID sonst nichts... Hat niemand eine Idee wie das zu handeln wäre? =/
Raphael B. schrieb: > Das Problem ist, wenn diese 4 Werte doppelt kommen Wieso doppelt? Wenn sich der Wert ändert sind sie doch nicht doppelt, woher sollen den die doppelten Werte kommen wenn das Gerät nur auf Aufforderung sendet? Das kann doch höchstens passieren wenn es so was wie ein automatische Resend gibt weil du kein ACK sendest...
Das Passiert wenn ein Windoof Timer ein mal länger braucht (beispielsweise 300 ms) und auf den nächsten Tick kürzer braucht(ca. 50 ms) das heisst diese Daten werden dann doppelt gelesen. Got it?
Folgende Sequenz:
1 | 1 2 3 4 6 7 8 |
Nun liest du:
1 | 1 |
2 | 2 |
3 | 3 |
4 | 3 <- wegen "doppelt" |
5 | 4 |
6 | 6 |
7 | 7 |
8 | 8 |
Wie kann es nun durch "doppelt lesen" zu einem peak nach unten kommen welcher nicht in der Orginalsequenz enthalten ist? Ansonsten solltest du dein Konzept überdenken wenn dich ein Jitter im Timer dermaßen aus der Bahn wirft, was spricht den dagegen das Gerät kontinuierlich auszulesen + Timestamp und später die Daten dann nur in 200ms Abständen auszugeben? Raphael B. schrieb: > wenn ein Windoof Timer Selber doof würde Windows wohl sagen... Weder Timer noch das Netzwerk könne eine konstante Rate garantieren und nach deiner Beschreibung ist da noch was anderes faul...
Raphael B. schrieb: > Das Passiert wenn ein Windoof Timer ein mal länger braucht > (beispielsweise 300 ms) und auf den nächsten Tick kürzer braucht(ca. 50 > ms) Dann nimmt man nicht die nachrichtenbasierten Timer, sondern die deutlich stabileren Multimediatimer. Die sind ausreichend robust, daß Aussetzer in dieser Größenordnung nicht auftreten, und die Timerauflösung kann auf 1 msec gesetzt werden (mit der Win32-API-Funktion timeBeginPeriod). Wenn dann immer noch Probleme auftreten, liegt das am .Net-Geraffel oder deutlich überhöhter Auslastung des Rechners, auf dem das ganze läuft.
Rufus Τ. Firefly schrieb: > Wenn dann immer noch Probleme auftreten Liegt der Hund vermutlich ganz woanders begraben, wie oben schon geschrieben, wie kann es durch doppelte Werte zu Schwankungen im Signalverlauf kommen? Zumal 200ms wenn es blöd läuft ja schon durch das Netzwerkdelay aufgefressen werden, ein Timer ist hier meiner Meinung nach total unsinnig, wahrscheinlich wird auch noch schön jedes mal ein Socket aufgemacht und wieder geschlossen...
Sorry Leute ich bin wohl schlecht im Erklären... ich bekomme folgende Packete 1234 => Ein Packet! 5678 => Noch eins... . . . und das ganze kann unter Umständen(mithilfe des Win32 MultimediaTimers) so aussehen: 1234 1234 5678 und das ergibt leider hässliche Peaks. und ja ich MUSS 4 Werte auf einmal lesen. =/
Raphael B. schrieb: > Sorry Leute ich bin wohl schlecht im Erklären... ich bekomme folgende > Packete > > 1234 => Ein Packet! > 5678 => Noch eins... > . > . > . > > und das ganze kann unter Umständen(mithilfe des Win32 MultimediaTimers) > so aussehen: > 1234 > 1234 > 5678 heißt das jetzt, das in einem Paket mehrere Messwerte ein und deselben Sensors enthalten sind? Das würde das beschriebene Verhalten erklären. Oder sind 1, 2, 3, 4 verschiedene Sensoren? (Wie man sieht, sind reale Werte und reale Bezeichnungen immer besser als etwas zurecht gemachtes. Irgendeinen Grund für ein Misverständnis gibt es immer)
Genau es sind 4 Messwerte Pro Sensor pro packet... Einfach immer 4 auf ein Paket die eine LInie weiterzeichnen....
Ich hab keine Ahnung vom Modbus. Aber hast Du schon den Nagle-Algorithmus vom TCP ausgeschaltet?
In C# gibt's ein Property dafür: http://msdn.microsoft.com/de-de/library/system.net.sockets.socket.nodelay.aspx
So nun ist endlich mal klar wie die Daten aussehen. Wenn du aber sagst, das Verluste "egal" sind, vergleich doch einfach das vorherige mit dem nächstem Paket... Wenn P1 = P2 and P2[0] < P1[3] werfe paket weg...
Dies ist aber schecht wenn signale einenulllinie verfolgen.. :/
Raphael B. schrieb: > Dies ist aber schecht wenn signale einenulllinie verfolgen.. :/ nur wenn 0 < 0 gilt... daher auch die zweite Bedingung
Raphael B. schrieb: > Dies ist aber schecht wenn signale einenulllinie verfolgen.. :/ Wenn das Signal eine 0-Linie verfolgt und daher alle Werte ständig gleich sind, kann es auch keinen Peak geben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.