Hallo,
ich habe ein Problem mit meiner C# Software, die Daten über eine
serielle Schnittstelle einliest, speichert und dann in einem Zedgraph
Diagramm dargestellt werden. Das Problem besteht darin, dass die Daten
im Hauptfenster mit nur kleiner Verzögerung (wegen der Schnittstelle)
dargestellt werden, sobald das Diagramm Fenster aufgemacht wird aber ein
zunehmender Delay entsteht.
Die Daten werden in Form1 gespeichert. Mittels Button wird dann die neue
aufgerufen. Ihr übergebe ich die eingelesenen Daten mittels
>Form2 f2 = new Form2(data);>f2.ShowDialog();
Komischerweise ist generell nach dem Starten des Diagramms ein
zunehmender Delay erkennbar (also auch wenn das Diagramm schon wieder
beendet wurde).
Vielleicht hat jemand nen Ansatz der mir hilft das Problem zu lösen.
Gruß
SePP
Zedgraph verbraucht je nach menge der punkte unterschiedlich lange um
datan anzuzeigen und es braucht lange. Wenn du dann noch glimbim
anschaltest (z.B farbverlauf, symbole) dann braucht er noch länger.
was für ein Delay entsteht genau? Die Daten aus der Schnittstelle werden
doch in einen Buffer geschrieben. Zeit ist gerade unter Windows sehr
relativ, gerade mit .net.
Klar ist zeit hier relativ und Daten werden gepuffert. Deshalb seh ich
ja eine Änderung auch erst viel später (nach 15s+ hab ich eine
Verzögerung von über 3s drin). Ich stelle z.Z. 7 Kurven (Ziel sind
eigentlich 10) mittels RollingPointPairList dar und haben eine Sample
Intervall von 100ms.
Vielleicht liegt es auch daran das mein Rechner zu lahm ist, aber davon
geh ich mal nicht aus (3Ghz Celeron mit 512mb sollten denke ich
reichen).
Habe mein Problem gelöst, nachdem ich mich nochmal mit der Seriellen
Schnittstelle beschäftigt habe. Hier wurden die Daten nur scheinbar
schnell genug erfasst. Zedgraph war NICHT an der Verzögerung schuld.
Habe auch nochmal ein paar Optimierung bei der Zedgraph Darstellung
gemacht und nun bin ich erstmal ganz zufrieden. :-)
Ist zwar nicht mehr aktuell hier, aber mich würde die Lösung schon
interssieren bzw. wie es verbessert wurde.
Ich habe momentan ein ähnliches Problem. Ich zeichne über 75min Daten
von der Seriellenschnittsetlle auf und das je Sekunde vier Datenpackete.
Es wird live mit ZedGraph gezeichnet. Am anfang läuft die Sache noch
flot, jedoch wird es gegen Ende langsam träge. Bis zu einer Sekunde
nachlauf drin.
Es läuft bei mir so ab:
im µC:
->Messdaten erfassen (1,5ms)
Loop
{
-> PC bereit?
-> Daten an PC senden
}
in VB:
Loop
{
->Daten von der Seriellenschnittstelle holen
->mit ZedGraph zeichnen
->µC sagen das neue Daten kommen können
}
Ein Datenpacket hat 2 Byte.
die Übertragung erfolgt mit 9600 Baud, somit 9600 Bit/s und d.h. könnte
ich ja in der Sekunde 533 von den Packeten schicken bzw. ein Packet in
2ms.
Macht allso alles mit Messung zusammen ca. 14ms und den Rest der Zeit
verbingt der µC mit warten auf den Rechner. Ist ja net grade prickelnd
wie ich finde, da man da locker mehr rausholen könnte.
Mein WehWeh bei ZedGraph ist nun, dass der mir wie Ox vorm Berg bei
jedem neuen Punkt alle davorgehenden Punkte auch neu zeichnet, was ja
nicht Sinn der Sache ist bei 18000 Punkten.
Ich könnte die Daten buffern, jedoch ists dann hin mit "live"
zeichen.... wobei es dann mehr live wäre als jetzt glaub ich.
so!Bin ich noch zu blöd und habe die Funktion, welche nur die neuen
Punkte zeichnet, nicht gefunden oder gibt es diese nicht und ich muss
mir einen eigenen Graphen programmieren der das kann.... bin aber nur
Bachelor(FH) und zu faul. Außderdem gefällt mir der schnickSchnack von
ZedGrpah der schon da ist.
Kurz zu den Daten die ich hochgeladen habe.
Die Daten wurden ohne Warten des µC aufgezeichnet! Also das Maximum was
bei der Lösung drin ist.
Das Bildchen soll mal zeigen wie der Spass ausieht. Die Text-datei zeigt
mein Problem schon eher.
Die ersten vier Spalten interessieren net. Die letzte Spalte ist die
Zeit in Sekunden. Es ist zu erkennen wie der Rechner da noch mitkommt,
da Zeiten doppelt auftauchen, geht man ganz zum Ende der Spalte schluckt
der schon ne Sekunde. Wenn man den Rechner noch mit was ablenkt schluckt
der noch mer Sekunden.
Jemand schon dahingehend mit ZedGraph erfahrung gesammelt und weiss wie
ich das zeichnen ohne Buffer schneller hinbekommen könnte?
Hi!
Ich grab den Thread mal aus, denk ich ist sinnvoller als einen neuen
Fred zu starten, da meine Frage genau hier anschließt: der TO shrieb:
"... Habe mein Problem gelöst, nachdem ich mich nochmal mit der
Seriellen
Schnittstelle beschäftigt habe. Hier wurden die Daten nur scheinbar
schnell genug erfasst..."
Ich habe genau dasselbe Problem, dass am Anfang alles super schnell
läuft und dann nach ca. 15 Sekunden 5 Sekunden Verzögerung auftreten und
so weiter.
Daher würde mich interessieren, was hier beim Einlesen der COM-Portdaten
zu berücksichtigen war/ist.
Vielleicht ist der TO ja noch hier unterwegs, oder jemand anderer weiß
Rat.
Danke, Sebastian
Hi, hab das gleiche Problem.
Sende mit 38400 Baud Daten an den PC - in einem beliebigen
Terminalprogramm z.b. Termie (geschrieben in C#) werden alle Daten
sofort angezeigt.
In meinem selbstgeschriebenen, mittlerweile etwas komplexeren Programm
kommen die oben beschriebenen Verspätungen zustande.
Allerdings bei einer Messung von z.b. ~45min beträgt die Verzögerung bis
zu einigen Minuten. Der uC sendet in dieser Zeit definitiv nichts mehr.
Wäre auch an einer Lösung oder Ansatz interessiert.
danke, grüße
Mat
Mat T. schrieb:> Wäre auch an einer Lösung oder Ansatz interessiert
Ein Ansatz wäre mal
Mat T. schrieb:> mittlerweile etwas komplexeren Programm
auf das nötigste zu reduzieren. Und dann ggf. mal den Code hier posten.
Hallo,
danke für den Tipp. Hab in einem anderen Forum ein ähnliches Problem
gefunden und es mit diesem Lösungsansatz versucht.
Mein Code vereinfacht dargestellt:
müsste meiner Meinung nach bei jedem Datenpaket das kommt ein Interrupt
auslösen bzw. in diese Routine springen.
Comport ist eingestellt auf '\n' Terminierung und der Controller schickt
es auch immer hinten dran.
So meine Theorie ...
Hab dann diesen Code gefunden und es jetzt so umgebaut und bisher
funktioniert das wie gewünscht.
Läubi .. schrieb:> Mat T. schrieb:>> Hab dann diesen Code gefunden>> Und hoffentlich auch verstanden warum das so funktioniert ;)
hehe, ich hoffs mal ;)
hab mir ja wie oben beschrieben erwartet, dass pro gesendetem Text mit
'\n' Abschluss einmal diese Empfangsroutine aufgerufen wird.
wenn während der Abarbeitung wieder Daten eintreffen, können die eben
auch schon ausgelesen werden.
oder so irgendwie :)
gruß Mat
Mat T. schrieb:> oder so irgendwie :)
Passt schon so irgendwie ;)
Das Problem wird einfach sein, das durchaus mehr als eine Zeile
empfangen wird.
Wenn du aber immer nur eine Zeile liest, kann sich ein Rückstau bilden,
was dazu führt das es für die Applikation so aussieht als würden die
Daten verspätet eintreffen.
Du solltest aber beachten, dass hierdurch die Empfangsfunktion
theoretisch beliebig lange in der Schleife verweilen kann.
Vermutlich wäre es besser, dass das Empfangen in einem Thread
geschieht. und dieser einfach wenn nix mehr EMpfangen wird schläft, und
einfach nur durch das "neue Daten Event" aufgeweckt wird.
glaub der Comport läuft eh in einem extra Thread, da ich zumindest nicht
direkt auf die GUI zugreifen kann und über Invokes gehen muss.
Hab auch schon überlegt, wenn sich z.b. der Controller aufhängt bzw.
Fehlsignale bekommt, kann er auch "relativ oft" ;) Daten senden, was
dann meine GUI abwürgen würde, zumindest wenns im gleichen Thread ist.
darübernachdenk
