Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich befinde mich derzeit im Praktikum für mein Studium und muss auf ein Messgerät über die serielle Schnittstelle zugreifen. Bisher klappt an sich alles wunderbar, bis auf ein kleines, wenn aber auch sehr störendes Problem. Und zwar geht es um das Auslesen von Daten vom Messgerät zum PC per VISA-Read.
Die Kommunikation läuft so ab das vom PC ein Befehl gesendet wird. In meinem Fall der Befehl zum Auslesen der Messdaten. Dann sendet das Gerät eine Bestigung zurück inklusive der Messdaten und weitere Informationen wie z.B. den Messbereich. Die Daten liegen hierbei im ASCII-Format vor und müssen später noch bearbeitet werden. Hierfür werden die Daten in einem String gespeichert und später wird dieser stück für stück zerlegt. Mein Problem ist jetzt aber das der PC die Daten "zu schnell! liest. Sprich die Daten werden zu schnell gelesen, bevor das Gerät alles sendebereit hat.
Beim Auslesen werden vom Gerät insgesamt 5 Byte gesendet. Ich erhalte jedoch nur 1 Byte am Port.
Zur Zeit habe ich eine Lösung gefunden. Und zwar habe ich beim Senden des Auslesebefehls (VISA-Write) ein Delay von 10ms eingebaut, womit es auch super funktioniert. Nur irgendwie ist mir das ein wenig unsauber und ich habe auch schon über die Synchronisation bei Messdatenerfassung gelesen, jedoch noch nicht richtig implementieren können.
Kleine Zusatzinformation: ich verwende einen USB to serial Adapter von Logilink (Bez.: UA0042). Habe in Verbindung mit diesen Adaptern schon Informationen aus dem Forum erhalten. Das sie eine etwaige Verzögerung von etwa 15ms zur Folge haben.
Habt ihr evtl eine Lösung oder einen Vorschlag wie ich diese "Abstimmungsschwierigkeiten" beseitigen könnte?
Wie liest du die Daten? Wie hast du deine Schnittstelle konfiguriert? Hast du Termination Char eingeschaltet? Wie ist der Timeout fürs Lesen? Zeige mal dein Block Diagramm.
Also die Daten werden parallel zur Eingabe der gewünschten Funktion gelesen. Sprich es wird permanent am Port "gehorcht", ob etwas gesendet wird. Überprüft wird das ganze über "Bytes at Port". ISt der Wert größer als 0, dann kommt VISA-Read ins Spiel.
Die Schnittstelle ist mit der Standardkonfiguration belegt.
Baud: 9600
Datenbits: 8
Parity: 0
Stopbits: 1
Mit dem Termination Char weiß ich bisher noch nichts anzufangen, sprich was es damit auf sich hat. Das Lesen selbst hat nach oben genannter Vorgehensweise kein Timeout. (denke das du da auf die Ereignisstruktur hinaus willst?!)
Das Blockdiagramm ist schon recht groß. Habe es auch versucht über imageshack hochzuladen, aber irgendwie will das nicht so ganz klappen. Evtl. sind auf dem Firmenrechner hier nicht alle Programme installiert. (Flash-Player etc., bin kein Admin)
Falls es noch weitere Möglichkeiten zum hochladen gibt, so nenn mir bitte eine, damit ich das noch nachholen kann.
Edit: Sehe grad das ich ne File anhängen kann. Werde das Hauptbild aus dem BD einfach mal hinzufügen.
Und du verwendest tatsächlich LV7.1? Nicht vielleicht doch 8.2.1 oder höher?
Zitat:Und zwar habe ich beim Senden des Auslesebefehls (VISA-Write) ein Delay von 10ms eingebaut, womit es auch super funktioniert. Nur irgendwie ist mir das ein wenig unsauber
Eigentlich ist hier aber nichts dagegen einzuwenden. Außer:
Zitat:ISt der Wert größer als 0, dann kommt VISA-Read ins Spiel.
Ja, genau. Aber:
Warte halt solange, bis genau die Anzahl von Zeichen im Puffer ist, die du auch erwartest.
Zitat:(denke das du da auf die Ereignisstruktur hinaus willst?!)
Ereignisstruktur!? Seht gut, sehr gut. Mach das mal und zwar wie folgt:
Diese sieben VISA-Write-Cases machst du in eine Eventstruktur. Vorteil: keine lokalen Variablen der VISA-Referenz nötig. RaceConditions auf "EXE cmd" entfallen etc. etc. In Folge (also sequenziert mit der Eventstruktur) eines Tastendruckes kannst du dann einen IF-Case machen, in dem du (mit Timeout) auf genau die richtige Anzahl von Zeichen wartest.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Und du verwendest tatsächlich LV7.1? Nicht vielleicht doch 8.2.1 oder höher?
Jap, zu 100%.
' schrieb:Warte halt solange, bis genau die Anzahl von Zeichen im Puffer ist, die du auch erwartest.
Habe das mal probiert, aber das Problem ist, das er Antworten die länger als 1 Byte sind, nicht realisiert. Sprich er bekommt schon komplett falsche Informationen wieviel Byte am Port ankommen.
' schrieb:Diese sieben VISA-Write-Cases machst du in eine Eventstruktur. Vorteil: keine lokalen Variablen der VISA-Referenz nötig. RaceConditions auf "EXE cmd" entfallen etc. etc. In Folge (also sequenziert mit der Eventstruktur) eines Tastendruckes kannst du dann einen IF-Case machen, in dem du (mit Timeout) auf genau die richtige Anzahl von Zeichen wartest.
Ok, da werd ich mich mal dranmachen. Hätte aber noch paar Fragen dazu.
1. Warum sind keine lokalen Variablen notwendig? Ich muss doch den Port angeben und auch wiederübergeben oder?
2. Was sind RaceConditions? (Evtl. die folgenden Befehle die nach Senden des Startbytes und Empfang des Antwortbytes ausgeführt werden sollen?
3. Wie genau läuft das mit dem Timeout, dachte bisher das man da direkt eine Zeit eingibt, wie lange die Struktur auf ein Ereignis wartet?
' schrieb:Habe das mal probiert, aber das Problem ist, das er Antworten die länger als 1 Byte sind, nicht realisiert. Sprich er bekommt schon komplett falsche Informationen wieviel Byte am Port ankommen.
Naja, wenn du das sagst, wird schon was dran sein. So recht nachvollziehen kann ich das aber nicht. Kommen denn zuviele Zeichen?
Zitat:1. Warum sind keine lokalen Variablen notwendig? Ich muss doch den Port angeben und auch wiederübergeben oder?
Wieder übergeben brauchst du auf keinen Fall. Der Wert steht ja schon drinnen, in der Variablen.
Der Ausgang oben rechts ist für Sequenzierung (Datenfluß!) gut.
Die Eventstruktur befindet sich in einer While-Schleife, die (mindestens) ein Schieberegister hat. In einem solchen Schieberegister befindet sich die VISA-Referenz.
Zitat:2. Was sind RaceConditions? (Evtl. die folgenden Befehle die nach Senden des Startbytes und Empfang des Antwortbytes ausgeführt werden sollen?
RaceConditions sind Probleme beim Datenfluß. Wenn du parallele, also nicht sequenzierte Strukturen hast, kann keiner sagen, was zuerst abgearbeitet wird. Verwenden beide Strukturen nun eine Variable schreibenderweise, so kann man also nicht sagen, welcher Wert zuerst hineingeschrieben wird - und dann gleich überschrieben wird vom zweiten Wert. Der erste Werte geht also verloren.
Beispiel:
Du hast sieben parallele IF-Cases. Gesetzt der Fall du drückst jetzt zwei Buttons gleichzeitig, sodass auch zwei TRUE-Cases gleichzeitig gemacht werden, so passiert folgendes: In jedem der Cases wird ein String erstellt, der VISA-gesendet wird und auch in die Variable ExeCmd geschrieben wird. Welcher Wert steht nun am Schluss in ExeCmd? Der vom einen Case oder der vom anderen Case? Man kann also zu einem ganz bestimmten Zeitpunkt (nämlich nach Beendigung beider Cases) nicht sagen, welcher Wert in ExeCmd steht. Man kann nur sagen, dass einer der beiden verlorten gegangen ist. Um dieses Problem zu vermeiden, muss (direkt oder per Ablaufvorgabe) sequenziert werden.
Zitat:3. Wie genau läuft das mit dem Timeout, dachte bisher das man da direkt eine Zeit eingibt, wie lange die Struktur auf ein Ereignis wartet?
Ja, so ist es.
Die Eventstruktur hat einen Timeout-Anschluß, den ich immer mit 250ms beschalte. Dann wird alle 250ms der Timeout-Case abgearbeitet. Kommt ein Event früher, wird eben dieses abgearbeitet. Eine Eventstruktur befindet sich aber immer in einer While-Schleife. Sonst könnten nach dem ersten Event keine weiteren mehr verarbeitet werden. Folge aus der While-Schleife nun ist, dass es auch einen Event geben sollte, der die While-Schleife beenden kann.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:..So recht nachvollziehen kann ich das aber nicht. Kommen denn zuviele Zeichen?
Es kommt meistnur 1 Byte an. Das ist meistens das Identifzierungsbyte, also das das Gerät den Befehl vom PC erhalen hat. Alles was danach folgt, wie bsw. das Byte für die Temperatur oder die Messdaten geht verloren bzw. wird eben nicht gelesen. Das manuelle Timeout hat dabei wohl zur Folge das das Gerät genug Zeit hat die Daten bereitzustellen, bis der PC sie dann letztendlich liest.
' schrieb:Die Eventstruktur befindet sich in einer While-Schleife, die (mindestens) ein Schieberegister hat. In einem solchen Schieberegister befindet sich die VISA-Referenz.
Muss die Struktur dabei allein in einer While-Schleife stehen oder kann es neben dem anderen Programminhalt in der Scleife sein? Sollte ja an sich letzteres gehen.
' schrieb:RaceConditions sind Probleme ...
Also verursachen die RaceCondtions "nur" Probleme bei Wertzuweisungen, sprich evtl Doppelzuweisungen.
Abschließend noch kurz zum Timeout. Du setzt also von vornherein ein Wartezeit (in der dann auch alles Daten korrekt am Port anliegen) an einen TimeOut-Case.
Den Event zum Schließen der While-Schleife habe ich in Form eines "POWER"-Buttons realisiert.
' schrieb:Das manuelle Timeout hat dabei wohl zur Folge das das Gerät genug Zeit hat die Daten bereitzustellen, bis der PC sie dann letztendlich liest.
Naja, du musst dem Gerät schon genug Zeit geben, um alle Daten zu senden. Entweder machst du das, indem du eine bestimmte Zeit wartest (Wait, nicht Metronom) oder du wartest solange, bis die Anzahl der Daten im Port einen gültigen Werte erreicht hat. Du musst also um das Property AnzahlZeichenImPuffer quasi eine While-Schleife herum machen, die erst dann beendet wird, wenn genug Zeichen im Puffer sind (oder mit Terminator arbeiten, wenn das geht).
Zitat:Muss die Struktur dabei allein in einer While-Schleife stehen oder kann es neben dem anderen Programminhalt in der Scleife sein? Sollte ja an sich letzteres gehen.
Gehen tut das schon.
Allerdings ist die While-Schleife in erster Linie für die Eventstruktur da, nicht für den anderen Programminhalt. Der andere Programminhalt würde ja immer nach einem Event, also auch nach dem Timeout-Event gemacht werden. Ist der andere Programminhalt nicht sequenziert mit der Eventstruktur, kann man ihn auch gleich in den Timeoutcase legen. Ist der Programminhalt seqenziert, dann ist das ja auch sinnvoll, da der nachfolgende Programminhalt vom Ergebnis eines Evantcases abhängig ist.
Zitat:Also verursachen die RaceCondtions "nur" Probleme bei Wertzuweisungen, sprich evtl Doppelzuweisungen.
Wahrscheinlich zu mehr als 90%. Ich kann mir aber auch vorstellen, dass auch andere Strukturen betroffen sind. RaceCondition ist so gesehen also ein "Verfahren".
Zitat:Abschließend noch kurz zum Timeout. Du setzt also von vornherein ein Wartezeit (in der dann auch alles Daten korrekt am Port anliegen) an einen TimeOut-Case.
Nein. Ich würde in deinem Falle wie folgt vorgehen: Für jeden der sieben Buttons einen Eventcase. Nach der Struktur wird dann eine explizite Wartezeit (z.B. 100ms) gemacht und danach dann die Daten gelesen (alles per Datenfluß).
Zitat:Den Event zum Schließen der While-Schleife habe ich in Form eines "POWER"-Buttons realisiert.
Ja, gut.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Naja, du musst dem Gerät schon genug Zeit geben, um alle Daten zu senden. Entweder machst du das, indem du eine bestimmte Zeit wartest (Wait, nicht Metronom) oder du wartest solange, bis die Anzahl der Daten im Port einen gültigen Werte erreicht hat. Du musst also um das Property AnzahlZeichenImPuffer quasi eine While-Schleife herum machen, die erst dann beendet wird, wenn genug Zeichen im Puffer sind (oder mit Terminator arbeiten, wenn das geht).
Habe es mit einem TimeOut-Case und 50 ms gemacht. Alles läuft perfekt damit.
DAs Problem beim Warten auf die genaue Anzahl der <ports setztaber vorraus das man die Anzahl der Bytes kennt die ankommen. Ist bei mir zwar der Fall, aber die Anzahl ist halt von Befehl zu Befehl unterschiedlich. Da ich aber nur einen Read-Befehl bisher habe zum "Lauschen", müsste ich ja dann wieder eine Fallunterscheidung reinbauen usw. Denke so wie ich das jetzt habe ist das ne gute Alternative.
' schrieb:Nein. Ich würde in deinem Falle wie folgt vorgehen: Für jeden der sieben Buttons einen Eventcase. Nach der Struktur wird dann eine explizite Wartezeit (z.B. 100ms) gemacht und danach dann die Daten gelesen (alles per Datenfluß).
Das habe ich schon gemacht. Jeder Button löst bei "Mouse Up" seine entsprechende Funktion aus. Nur die Zeit habe ich wie schon gesagt direkt als Timeout verwendet.
Bin jetzt gradnoch dabei eine Fehlermeldung auszugeben wenn der Port nicht der richtige ist. Nach der Auswahl soll dann gleich noch ein Standardmessbereich gesetzt werden. Das macht aber noch ein bischen Probleme.
Achjaa, da fällt mir grad noch was ein. Das Gerät selbst nimmt Befehle in Form von ASCII-Zeichen an. Ich habe nun noch eine Funktion die es mir ermöglicht den EEPROM des Gerätes zu lesen oder zu beschreiben. Beim Lesen muss ich eine Adresse der gewünschten Information angeben.
Die relevanten Adressen laufen von 01-11.
Wenn ich nun Die Adresse "07" ansprechen möchte, dann reicht es ja sicher nicht wenn ich eine normale "7" an das Gerät sendeoder?! Falls ja, hab ich damit auch noch Probleme das genau so zu versenden.
' schrieb:Jeder Button löst bei "Mouse Up" seine entsprechende Funktion aus.
Warum verwendest du denn MouseUp?
Ich halte es für besser, den normalen ValueChange-Event zu verwenden. Stell den Button auf Latch ein. Dann geht der - wie es sinnvoll ist - eventgesteuert.
Zitat:Wenn ich nun Die Adresse "07" ansprechen möchte, dann reicht es ja sicher nicht wenn ich eine normale "7" an das Gerät sendeoder?!
Davon gehe ich aus.
Nimm das Formatier-Element aus der Stringpalette mit dem Format "%02d". (0 bedeutet: führende Nuller)
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
