1x COM-Port, 2 x Write & 2x Read

Hallo liebe Community,

seit ca. einem Monat setze ich mich bzgl. meiner Masterarbeit mit LabVIEW auseinander.
Meine Kenntnisse sind dementsprechend nicht die ausgeprägtesten.
Für das euch folgende geschilderten Thema/Problem habe ich schon einige Posts durchgelesen, jedoch konnte ich leider keine Lösung meines Problems finden.
Ich bitte daher um Verzeihung falls es ein Doppelpost sein sollte.
Meine geschriebenen Kommentare im Screenshot bitte ich ebenfalls auszublenden, falls dies möglich ist^^

Also ich nutze die LabVIEW Version 2011 und zur zeit sitze ich daran, eine Steuerung für eine Pumpe zu schreiben.
Mittels Button möchte ich die Pumpe an/aus schalten können, die Steuerung von Local zu Remote ändern und bestätigen und andere Befehle senden und bestätigen können, wie zB die Frage nach Fehlern. Des weitern möchte ich einen Massenstrom einstellen können. Wird kein Button betätigt, so läuft die Pumpe mit ihren letzten Einstellungen weiter.
Dies funktioniert soweit alles sehr gut.

Mein Problem ist nun folgendes.

Ich möchte von der Pumpe "kontinuierlich", sobald ich den Knopf DRUCK LESEN AN betätige, den Druck abfragen und habe es, wie ihr im Screenshot oben rechts in der Case-Structure sehen könnt, auf diese Weise aufgebaut. Das ganze ist in einer While-Schleife, damit die Pumpe kontiuierlich fördert. Auf dem Screenshot ist diese nicht zu sehen.

Fall 1: Ist der Schalter "Druck Lesen" auf AUS gestellt, so läuft das Programm reibungslos und ich kann alle Befehle/Abfragungen ohne große Verzögerung tätigen. Soweit alles super.
Fall 2: Ist der Schalter "Druck Lesen" auf AN, so ist dies nicht mehr möglich. Es Bedarf ein öfteres klicken, bis sich endlich mal etwas tut, sprich, dass ein Befehl gesendet wird etc.

Ich habe schon versucht die Case-Structure an anderen Stellen einzupflegen und bin bisher zu keiner Lösung gekommen.

Habt ihr eine Idee und könnt mir hier weiter helfen?


Beste Grüße
Jann

Anzeige

Hallo Jann,

wenn du mit einer einzelnen Resource arbeitest, kannst du nur bedingt parallel darauf zugreifen. Dies gilt um so mehr, als deine "Pumpe" von dir Befehle empfängt und darauf antwortet!

Lösung:
- VI aufräumen und über eine vernünftige Programmstruktur nachdenken
- dann solltest du auch der Meinung sein, dass eine saubere Statemachine hier sehr hilfreich wäre!

Allgemeine Tipps:
- BytesAtPort ist zu 99.9% aller Fälle fehl am Platz! Deine "Pumpe" scheint ein TermChar zu verwenden, jedenfalls hast du die Kommunikation so konfiguriert und sendest Befehle damit. Deshalb: BytesAtPort durch eine genügend große Konstante ersetzen! Dann entfallen auch irgendwelche Wartezeiten zwischen Write und Read! (Dies wurde hier schon desöfteren diskutiert, einfach mal andere Threads zum Themenbereich "serielle Schnittstelle" lesen.)
- Wenn immer das gleiche TermChar beim Befehlsversand genutzt wird, sollte man diese mit einer VISA-Propertynode setzen und aktivieren!
- Wenn man die Schleife im Bild nicht sieht: Warum muss man die serielle Schnittstelle in jeder Iteration erneut initialisieren? Warum muss man den VISA-Buffer jedesmal löschen?
- Das Parsen des Druckwertes sieht auch übermäßig kompliziert aus. Ein ScanFromString sollte hier ausreichen! Gib mal ein Beispiel für einen typischen Antwortstring…

Hallo GerdW,

erstmal Danke für deine Hilfe.
Dass das Programm ein wenig unübersichtlich ist, ist mir auch bewusst.
Ich bin nun gerade dabei, es aufzuräumen und umzugestalten.

Das mit dem andauernd neu initialisieren finde ich auch nicht gut, da gebe ich dir recht! Das wird ebenfalls im Neuaufbau des Programms neu aufgesetzt.

Ein möglicher String sieht folgendermaßen aus:

Abfrage String/ Befehl: STATUS?
Ausgabe String/Befehl: STATUS:14895226,1,0,,1500,0,100,0,0,0,0,0,0,0,0,0,0,142696,0,0

Das Problem dabei ist, dass der String in seiner Länge variiert. Das bedeutet die Zahlen zwischen den Kommatar sind mal 1/2 Stellen lang sodass ich hier keinen festen Offset angeben kann.
Die Idee mit Scan for String kam mir auch schon .
Für mich ist in der Ausgabe des Strings der Wert 142696 von Wichtigkeit.
Hast du evtl. eine andere/einfachere/smartere Möglichkeit?

Das BytesAtPort habe ich aus dem LabVIEW Beispiel Write and Read, also Befehle Senden und Empfangen übernommen.
Wenn ich eine Konstante Zahl verwende, dann braucht mein VI schon länger zum lesen und Ausgaben des Strings, als es mit BytesAtPort der Fall ist.

Jemand eine Idee oder einen Vorschlag?
Wie gesagt, bin erst seit einem Monat dabei!


Grüße
Jann

Hallo Jann,

Zitat:Das BytesAtPort habe ich aus dem LabVIEW Beispiel Write and Read, also Befehle Senden und Empfangen übernommen.

Das heißt nicht, dass BytesAtPort sinnvoll ist…

Zitat:Wenn ich eine Konstante Zahl verwende, dann braucht mein VI schon länger zum lesen und Ausgaben des Strings, als es mit BytesAtPort der Fall ist.

Nein, es geht sogar schneller: Momentan musst du eine Wartezeit verwenden, um sicherzustellen, dass die Geräteantwort vollständig angekommen ist.
Ohne BytesAtPort bekommst du die Antwort aber sofort, nachdem sie vollständig (dank TermChar!) angekommen ist…

Zum String-Auswerten:
   

Hallo GerdW,

danke für die Rückmeldung!
Mit dem String konnte ich schon sehr gut umsetzen!
Danke dafür (:

Ich hab das Lesen des Strings/ des Befehls dann so bewerkstelligt, dass ich das BytesAtPort gelöscht habe und den Eingang von Serial-Read mit einer Constante versehen habe.
Dazu habe ich 2 Screenshots angeheftet.

Ist dies so korrekt, so wie du es meintest?

Hallo Jann,

das ist dann korrekt, wenn die Konstante größer ist als die erwartete Stringlänge der Antwort.

Hintergrund:
VISARead wird beendet, wenn
1. die gewünschte Anzahl der Zeichen vom Buffer (des seriellen Ports) gelesen wurde
2. das TermChar im Buffer gelesen wurde
3. nicht genügend Zeichen gelesen werden konnten und der TimeOut erreicht wurde
Du willst Fall 2, ohne das Fall 1 eintritt…

Anzeige

Das Problem was weiterhin noch besteht ist, dass ich nicht zeitgleich Befehle senden bzw abfragen und den Druck auslesen kann.
Ich hab mir überlegt, das Ganze in einer flachen Sequenzstruktur nacheinander abarbeiten zu lassen.

Also erst Befehl senden für neuen Massenstrom setzen und danach den Druck, der an der Pumpe anliegt, auslesen zu lassen.

Ist dieses Vorhaben sinnvoll oder gibt es da etwas schnelleres/besseres!?

Grüße
Jann

Hallo Jann,

Zitat:Das Problem was weiterhin noch besteht ist, dass ich nicht zeitgleich Befehle senden bzw abfragen und den Druck auslesen kann.

Korrekt. Du hast nur einen Kommunikationskanal und dein Gerät antwortet immer auf den letzten Befehl.
Also musst du selbst dafür sorgen, dass immer die Reihenfolge "Befehl senden und seine Antwort lesen" eingehalten wird!

Zitat:Ich hab mir überlegt, das Ganze in einer flachen Sequenzstruktur nacheinander abarbeiten zu lassen.
…
Ist dieses Vorhaben sinnvoll oder gibt es da etwas schnelleres/besseres!?

In Beitrag #2 hatte ich eine Statemachine empfohlen, das scheinst du überlesen zu haben…
(Eine Sequenzstruktur ist immer nur eine Krücke, um mit Gewalt den DATAFLOW durchzusetzen. Es gibt garantiert besseres dafür!)

Okay, das mit der flachen Sequenzstruktur, da gebe ich dir Recht.
Ich versuche das mit der State Machine zu bewerkstelligen.

Du hast im Beitrag #2 gesagt, dass meine Pumpe Termchar verwendet, bzw weil cih es so programmiert habe.
Darf ich dich fragen, woran du das gesehen hast, bzw woher du weißt welches der Termchar ist?
Ich habe nun schon einige Zeit hier im Forum verbracht, aber keine Lösung mittels TermChar gefunden, wie ich es aufzubauen habe etc. Bin da etwas ratlos und das entmutigt mich schon ein wenig.

Da wir das Kommunikationsprotokoll deiner Pumpe nicht kennen, wissen wir nicht wirklich, ob sie jede Nachricht mit einem Termination Character abschließt. Das musst du selber wissen .

Aber du hast es so programmiert, da du an den Eingängen "Enable Termination Char" und "Termination Char" nichts angeschlossen hast:
   
Das entspricht somit einem <LINEFEED> als Termination Character.

Gruß, Jens