LabVIEWForum.de

Hallo zusammen,

wenn die Überschrift noch nicht abgeschreckt hat, würde ich bitten mir auf die Sprünge zu helfen.

Ich bin gestern auf den folgenden Post gestoßen: https://www.labviewforum.de/Thread-Messuhr-nullstellen

Damit habe ich etwas gefunden was ich schon lange suchte, aber aus irgendeinem Grund bei Google immer verborgen blieb.
Ich hatte jetzt also endlich einen Ansatz gefunden wie ich von der unsäglich unzuverlässigen Herstellersoftware auf LabVIEW umschwenken könnte.

Es hat auch gleich alles out of the box funktioniert. Als ich aber an einem Testfähigen punkt in meiner Umsetzung ankam musste ich feststellen das nun nur noch bei jedem ersten auslesen nach dem Start ein Wert geliefert wird (abgesehen davon wird nicht in die txt gespeichert, aber das kann getrost ignoriert werde, das bekomme ich denke ich auch Sieber hin).

also probierte ich mal die Datenerhebungsschleife einzeln aufzubauen. Dass funktionierte, genauso wie die von GertW inspirierte Anordnung des Ursprungscodes, sowohl mit, als auch ohne Verzögerung von einer Minute.

Nur das komplett Programm blieb nach einer Messung stumm. Bei weiteren Nachforschungen sah ich das beim zweiten durchlauf keine Bits mehr im Buffet auftauchten, wo zuvor noch immer 8 waren.
Da hört allerdings schon mein Latein auf. ich habe absolut kein Idee wie diese Diskrepanz zustande kommt, ich gehe jedenfalls nach den abgeprüften parametern davon aus, das es sich nicht um einen Laufzeit Fehler handelt, da die Testschleifen genauso lange brauchen wie die im Programm.

Also setzt ich mal wieder mein ganz Hoffnung in die Expertise und Erfahrung hier im Forum.


Viel Grüße
Ksanto

Hallo Ksanto,

wenn du mich schon zitierst, dann doch bitte mit korrektem Namen!

Was mir an deinem "misst nicht" so auffällt:
Die FOR-Loop am Anfang:
- Du öffnest denselben COM-Port zweimal???
- Du packst die File-Referenz in ein Array - zweimal???
- Du packst (über den Schleifen-Iterator) die Werte 0 und 1 in ein Array.

Die While-Loop:
- Du indizierst dein 0/1-Array am Schleifenrand, das ergibt in den ersten beiden Durchläufen gültige Werte.
- Damit indizierst du sowohl die VISA- als auch die File-Referenz und arbeitest damit. Was passiert ab der 3. Iteration???
- Du indizierst ein Array of Timestamps mit 12 Elementen - es werden aber nur die ersten beiden verwendet…
Muss das alles so sein???

Beim "Messuhren.vi" läuft es ähnlich schräg:
- Auch hier hast du exakt zwei COM-Port-Referenzen in einem Array, die erste davon auch noch mit einem "leeren" Wert…
- Auch hier wird wild in diesem Array indiziert, ohne jemals zu prüfen, ob das indizierte Element überhaupt existiert…
- Hier wird ein Timeout-Case mit 1ms Delay aufgerufen: muss das so oft sein? (Vor allem, wenn der Inhalt des Event-Cases mindestens 1 Sekunde zum Abarbeiten benötigt - was lt. LabVIEW-Hilfe nicht empfehlenswert ist!)
- Warum kein eigenes Event für dein Enum? Die Registerkarte muss doch nur umgeschaltet werden, wenn der User am Enum rumspielt!
- Warum ein User-defined Event für den Button CC01? Der ist doch im Blockdiagramm direkt verfügbar!?
- Warum erstellst du Pfade mittels Stringfunktionen? Dafür gibt es BuildPath!
- Warum dieses riesige ConcatString, wenn der Vorgang mit FormatIntoString ("%s - SN %s - PID %s.txt") viel einfacher&übersichtlicher zu erledigen ist?

Danke für die Antwort Gerd,

Tut mir leid, kommt nicht wieder vor!

Ich habe die Lösung gerade selber gefunden, nachdem ich mich an ein Star Trek Zitat erinnerte:

Spock:“An ancestor of mine maintained that if you eliminate the impossible, whatever remains, however improbable, must be the solution.”
Naja, eigentlich von Sherlock Holmes/Arthur Conan Doil entliehen, aber ich bin halt ein Treky. ^^


Da ich ja so deutlich darauf hingewiesen habe das 8Bit an Daten vorhanden sind (zumindest ja beim ersten durchlauf), aber in der Vorlage, die ja ursprünglich so vom Mahr Service vorgeschlagen wurde, 9Bit abgefragt werden, was zwar einen Fehler wirft, der aber isoliert kein Problem verursacht (LabVIEW meldet sich auch in isolierter Situation nicht), habe ich den wert einfach mal auf 8Bit geändert.
Und siehe da, kein Fehler mehr und es wird sogar in die Datei geschrieben.

Ich hatte mich zu sehr darauf verlassen das das schon einen Grund haben wird wenn das ganze so vorkonfiguriert von Mahr gegeben wird.

Also, damit ist das entgeltliche Problem (sogar beide) gelöst.


Gerd: Ich werde in einem folgenden Post nochmal auf deine aufgeworfenen Fragen im einzelnen eingehen, ich wollte nur erst einmal die Lösung kund tuen.


Viele Grüße
Ksanto

Bearbeitet:
27.07.2017 - 09:22 Typo
27.07.2017 - 16:11 Typo

Hallo Gerd,

zum "misst nicht" VI:

Das war einfach ein Beispiel das ich schnell zusammengekoppelt habe (kurz vor Feierabend) wo ich Komponenten aus dem eingelochten Programm zusammengeflickt habe, wo ich zeigen wollte das mit der selben Set an Daten, nur der isolierten Datenerfassungsschleife, das ganze wie erwartet funktioniert.

Das ist im Grunde die Antwort auf alle fragen bezüglich dem.


Nun zum eigentlichen Messuhren VI:
Der reihe nach.

- Das werden sogar mal ein leere plus 11 gültige. ich habe momentan nur ein Uhr deswegen momentan nur ein gültige Referenz. Das dass Array mit einer Leeren beginnt liegt daran dass dies mein erster Einfall war wie ich umgehe, das LabVIEW sich weigert beim Befehl ersetzen/einfügen an einer bestimmten Position in einem leeren Array einfach diesen anzulegen und den Rest davor mit leeren zu befüllen.
Angelehnt an die Registerkarte (wo die Auflistung der Uhren erst mit dem zweiten Reiter beginnt), will ich überall gleich mit dem Index 1 für die Messdatenverwaltung arbeiten. Alles was im Zweiten Reiter zutuen hat (Index 1) soll überall am Index 1 stehen.

- Da weiß ich leider nicht was du meinst. Wie kann man denn vor dem indizieren wissen ob ein Element an einem beliebigen Index existiert? Das einzige ab vom indizieren was mir einfällt wäre jetzt die Größe des Arrays zu prüfen, davon weiß man zwar ob etwas drin ist, aber immer noch nicht wo.

- Ja das stimmt, den Timeout wollte ich später auch noch auf einen wert zwischen 20ms und 500ms setzen. Ich wollte nur in der Aufbau- und Testphase vermeiden Konfigurationen vorzunehmen, von denen ich noch nicht absehen kann welchen Einfluss sie auf den gesamten Ablauf haben. Ich mag halt nicht unnötig warten um zu sehen ob es so läuft wie geplant. ^^
Bis jetzt lief das Programm auch nur so 3 bis 10 komplette Durchläufe am stück. Sowas konfiguriere ich erst wenn jede Funktion einmal richtig (technisch) funktioniert hat und bevor es in die Langzeittestphase geht.

- Dem Umschalten des Reiter ein eigenes Event zu geben habe ich auch schon überlegt. Aber da dies dass erste war was ich vom Programm erstellt habe, ist es halt bis jetzt immer mit gewandert. Werde ich aber jetzt noch tuen!

- Den Botton kann ich Zwar direkt ins Blockdiagramm werfen, aber da kommen ja noch 10 (oder späte noch mehr) dazu. Deswegen finde ich es aufgeräumter die alle davor zu haben als damit das Blockdiagramm voll zu spammen.
Ich habe vor meinem letzten Projekt seitenweise Foren Threads gewälzt weil ich mich mit Event Driven State Machines (im Vorfeld erstmal einfach über die Even Struktur allgemein) auseinander setzen musste. Dabei stelle sich an vielen Stellen die Frage ob man nun die Events vor registriert oder nicht. Zusammengefasst war das dann oft ein design Entscheidung. So habe ich mich hier entschieden lieber alle Botton aufgereiht vor dem Eventcase zu haben als damit das Diagramm aufzublähen.

- Wenn ich das richtig verstand habe, geht es darum warum ich den Grundpfad erst in eine String wandle und nachdem ich ihn ergänzt habe (ConcatString: komme ich gleich auch noch zu) wieder in einen Pfad Wandler? Blanke Unwissenheit! Ich wollte etwas an einen Pfad anhängen und das war die Erste Möglichkeit auf die ich gekommen bin.

- Beim ConcatString ist das ähnlich, ich bin mir zwar bewusst das das auch mit "fancy" Formatstrings (mit einem FormatIntoString, danke, jetzt weiß ich zumindest wo ich mich bei Gelegenheit einlesen kann) geht, aber ich habe einfach in der Regel nicht die Zeit mir das anzueignen. Ich werde eigentlich fürs Planen und durchführen von Prüfabläufen und Prüfungen bezahlt und bin kein Programmierer (wie wohl nicht wenige hier).


Umso dankbarer bin ich das hier im Forum vor allem von dir Gerd und jg (zumindest zu meinen Fragen, ob aktiv oder passiv) kurz auf den punkt erklärt wird was Sache ist oder zumindest hinweise entne̱hmbar sind wo man sich informieren kann. Dass hat mich praktisch durch mein gesamte letztes LabVIEW Projekt gebracht.


Viel Grüße
Ksanto


Bearbeitet: 27.07.2017 - 14:30 Typo