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!
Vielen Dank für den Tipp!
Ehrlich gesagt, weiss ich nicht wieso diese Funktion verwendet wird, ich habe das Block Diagramm direkt aus den von Hameg gelieferten VIs übernommen.
Inzwischen habe ich das Block Diagramm um ein Array und eine FOR Schleife übernommen.
Der Trigger des Messgerätes steht auf Auto und die Messzeit auf 1s (also wird laut Manual jede Sekunde ein neuer Messwert gesendet). Diese Messwerte will ich nun in mein Array schreiben, ich müsste jetzt ja eigentlich sehen, wie sich mein Array innerhalb von 40s (N=40) füllt...Aber auch dieses klappt nicht.
Mit Glühlampe funktioniert es, aber dann werden nur "veraltete" Werte in mein Array geschrieben, was vermutlich wieder am Buffer des seriellen Ports liegt, wie von dir, GerdW, eben angemerkt...
Kann ich den VISA Read Block so anpassen, dass er mir nur vom Messwert gesendete Daten ausgibt? Also dass die Daten nicht per Befehl angefragt werden, sondern dass meine VI auf Daten die gesendet werden, wartet?
Ich merk schon selber, dass ich eigentlich noch viel zu planlos bin, aber ich arbeite mich ja parallel zu diesem Problem noch anhand von "Einführung in LabView" in die Problematik ein.
da Du an die Schnittstelle nix schreibst, sondern nur liest, nehme ich an, dass das DMM von sich aus sendet.
In diesem Fall musst Du natürlich dafür sorgen, dass Du nur dann Messwerte übernimmst, wenn auch welche gesendet werden, also prüfen, ob im SS-Puffer überhaupt was liegt.
In deinem Fall denke ich mal, dass die gesendete Antwort sofort wieder mit NIX überschrieben wird, weshalb du nur im relativ langsamen Highlight-Mode was zu sehen bekommst.
Marko
28.12.2012, 17:22 (Dieser Beitrag wurde zuletzt bearbeitet: 28.12.2012 17:25 von GerdW.)
Zitat:ich müsste jetzt ja eigentlich sehen, wie sich mein Array innerhalb von 40s (N=40) füllt...Aber auch dieses klappt nicht.
Immer noch falsch, da du die Kommentare aus meinem letzten Beitrag nicht berücksichtigt hast!
Nochmal die Frage: Wieviele Bytes stehen sofort nach Absenden des Gerätebefehls im Empfangsbuffer der seriellen Schnittstelle?
Mal Schritt für Schritt:
Du sendest einen Befehl zum Gerät.
Dann fragst du ab, wieviele Bytes im Buffer stehen: direkt nach Absenden des Befehls sollte der Buffer leer sein!
Du sagst deinem VISA-Read also: Lese 0 Bytes (in Worten: null)!
Du wunderst dich über leere Strings als Antwort...
Jetzt machst du das 40 mal: Immer nur gucken, wieviele Bytes im Buffer stehen und dann den Buffer lesen. Das wird nie gut gehen!
Edit:
Ich nehme an, die durch das Anzeigen der Werte verdeckte Funktion ist "InitArray". Wozu erzeugst du dort ein Array mit 10 Einträgen des gerade gelesenen Strings???
@Marko:
Wenn der ReadBuffer leer ist, wird auch nichts angezeigt. Warum er leer ist, habe ich jetzt schon mehr als einmal gesagt...
Doch, deine Kommentare habe ich berüchsichtigt, da es dazu aber soviele Infos gibt, bin ich immer noch am lesen und versuchen zu verstehen.
Also ich denke mal im Empfangsbuffer der SS stehen direkt nach senden des Befehls 0 Byte, es sei denn, die automatisch vom Messgerät gesendeten Messwerte werden dort auch gespeichert?
Ja, das ist ein InitArray, jedoch ist keine Konstante angelegt, sondern die Laufzahl der Schleife, damit jeweils die nächste Zeile des Arrays beschrieben wird (s. Anhang).
Noch mal zum Verständnis: Wo sende ich einen Befehl an die Schnittstelle/Messgerät? Meinem Verständnis nach wartet das Programm nur auf Messwerte? Da ich ja nur ein VISA Read durchführe?!
Also so wie auch Marco es verstanden hat. Oder ist mein Read Befehl dann falsch, gibt es einen Befehl,der "auf Werte wartet"?
Leider werde ich nicht so recht fündig, was die Beiträge von Lucki angeht, die du mir empfohlen hattest...
Die INIT-Array-Funktion haste wohl falsch verstanden.
Du baust mit jedem Schleifendurchlauf ein 1D-Array, das soviele Werte enthält, wie der Schleifenindex groß ist, also beim 7. Durchlauf 6 Elemente, die alle identisch sind.
Marko
28.12.2012, 22:21 (Dieser Beitrag wurde zuletzt bearbeitet: 28.12.2012 22:22 von LVNeuling.)
OK dann habe ich das völlig falsch verstanden...
Irgendwie komme ich nicht voran. Es tun sich einfach immer mehr Fragen auf, als ich Antworten finde.
Ich glaube ich fange nochmal ganz vorne an.
Ich nutze das "Basic Serial Write And Read.vi" um kann auch Messwerte aus meinem Gerät auslesen. Soweit, so gut!
Ich habe mir auch schon aufgemalt, wie mein Programm ablaufen soll, jedoch hapert es gewaltig an der Umsetzung.
Hier einmal die Schritte die Ablaufen müssen (ich habe vor, mit den vom Hersteller bereit gestellten VIs zu arbeiten, diese muss ich doch dann im Programmablauf als SubVI ansehen, oder?):
###################################################
OPEN VISA -->
Beginn einer While Schleife bis manuell beendet -->
Set_Meas_Time.vi [500ms] -->
Set_Trigger.vi [auto] (alle 500ms wird der neue Messwert ausgegeben) -->
Set_Sensor-Comp.vi [front] (Front Anschluss des Gerätes auswählen als Referenzmessstelle für Thermoelemente) -->
MUXChannel.vi [CH 1] -->
Set_OHM4WIRE.vi (Widerstand Probe 1) -->
READ VISA -->
Messwert speichern unter R1 -->
MUXChannel.vi [CH 2] -->
Set_SensorTh.vi [Thermoelement Typ K] -->
READ VISA -->
Messwert speichern unter T1 -->
MUXChannel.vi [CH 3] -->
Set_SensorTh.vi [Thermoelement Typ K] -->
READ VISA -->
Messwert speichern unter T2 -->
MUXChannel.vi [CH 4] -->
Set_OHM4WIRE.vi -->
READ VISA -->
Messwert speichern unter R2-->
Rücksprung zum Anfang der While Schleife
####################################################
Jetzt sollten parallel zum Ablaufen der Schleife aus den gemessenen Werten jeweils 2 x-y Graphen erstellt werden für Widerstand über Zeit.
Ich hoffe jemand kann mich an die Hand nehmen und mir erklären, wie ich am besten anfange.
Ich verlange auf keinen Fall, dass mir jemand ein fertiges Programm schreibt, nur finde ich irgendwie keinen Einstieg und vor lauter LabView Funktionen qualmt mir schon der Kopf...
Und hier die fehlenden VIs...
dein Ausgelese scheint ja prinzipiell schonmal zu funktionieren, zwar nur im Highlight-Mode, aber das liegt ja nur daran, dass Du für die Senderoutine viel zu schnell liest und damit den tatsächlich gelesenen Wert wieder überschreibst.
Versuch dochmal, bei dem Eigenschaftsknoten, der dir die Anzahl der Bytes, die im SS-Puffer zu liegen, zu prüfen, ob überhaupt was im Puffer liegt. Wenn nicht, wartes du einfach 100ms und versuchst es erneut. Liegt was im Puffer, wartest du 20ms und liest dann den Rest aus und hängst ihn hinten an. Die so gelesene Antwort kannst du mit Built Array in ein Array legen oder du autoindizierst eine Schleife, wodurch dann auch ein Array entsteht.
Dann kannste dich um die graphische Darstellung kümmern.
Inzwischen funktioniert es auch ohne den Highlight Modus, und zwar mit "Basic Read And Write.vi" und einem delay before read von 500 ms (weniger ginge auch, aber dann kommen teilweise komische Werte und 500 ms ist schnell genug, meine Messzeit beträgt ja auch nur 500ms).
Der Hersteller gibt an, dass zwischen 2 Befehlen 35ms liegen müssen.
So habe ich quasi "Live" die Anzeige des Messgerätes auch in einer VI, beide werden im Abstand von 500ms aktualisiert.
Im Buffer liegen auch immer 10Byte parat.
Was mir noch ein Rätsel ist: Wann wird der CR Befehl an den String in den oben angehängten VIs angehängt?
Laut Manual besteht ein Steuerbefehl immer aus 5 ASCII Zeichen, in den VIs sind dann meist die ersten 3 fix und eine 4. wird je nach Auswahl im Frontpanel angehängt. Aber wann kommt der CR Befehl (also das 5. Zeichen)? Macht das der VISA READ Baustein eigenständig?
28.12.2012, 23:11 (Dieser Beitrag wurde zuletzt bearbeitet: 28.12.2012 23:14 von Trinitatis.)
Ich kann deine VIs nicht öffnen, weil zu neue LV-Version, aber ich vermute mal, dass der Zeilenvorschub als Trennzeichen zwischen 2 Sendungen zu verstehen ist. So kannst du für den fall, dass mehrere Antworten im Puffer liegen mit CR eine Separierung vornehmen, sozusagen lies, bis CR.
Wenn Du einen Befehl sendest, wirst Du dieses Zeichen wohl hinten anhängen müssen.
Die read / write-Funktionen machen das nicht von sich aus.
MarKo
Ich wäre im übrigen auch vorsichtig mit festen Wartezeiten im 500ms-Bereich oder größer, nur weil es in deinem konkreten Fall gerade passt. Besser ist immer in kleinen Intervallen oder eventgesteuert zu lesen.
Marko
29.12.2012, 17:58 (Dieser Beitrag wurde zuletzt bearbeitet: 29.12.2012 18:02 von LVNeuling.)
So ich habe eure guten Ratschläge beachtet, soweit ich es umsetzen konnte...
Momentan sieht es auch recht gut aus. Allerdings bekomme ich ab und an ein VISA Read Timeout. Jedoch sehr sporadisch und ich weiss nicht, woran es liegt.
Bytes at Port habe ich mal weggelassen, dann doch aber wieder eingefügt, um mir die anstehenden Daten nur anzeigen zu lassen.
Sicherlich könnte man vieles schöner und einfacher machen, aber bin halt blutiger Anfänger.
Ich habe mir aus einem anderen Thread hier im Forum mal versucht Infos zusammen zu suchen, wie ich meine gelesenen Strings in ein Array packen kann.Das haut aber noch gar nicht hin, ich habe es auch nur nachgebaut, ohne eigentlich zu wissen was ich tue.
Das Programm sieht jetzt etwas merkwürdig aus, da er immer den gleichen Kanal wählt und die gleiche Messung vornimmt, das wird aber noch verändert und es haut auch bereits hin.
@ GerdW: Ich habe Beiträge von Lucki gefunden, in denen er empfiehlt BytesAtPort wegzulassen und stattdessen einfach eine Konstante angibt, auf wieviele Bytes der Read Befehl warten soll, bzw. vorher ein CR Befehl erhält. Ich denke, das hast du gemeint, oder?
Ich hänge mal noch den Screenshot von dem Programmteil an, wo ich mir den Aufbau des Arrays geklaut habe, so zum Verständnis (Array.jpg).
Ausserdem meine bisher fertig gestellte VI.
edit: Laut Manual wird beim String 0161 der Trigger auf Single gesetzt und ein Messwert angefordert, der direkt nach erhalt des Befehls gesendet wird. Deswegen immer am Ende 0161.
