Kommunikation von mehreren Netzteilen mit gleicher instr.lib parallelisieren

Hallo,

ich habe ein Problem. Ich habe 6 Netzteile, welche alle ihre eigene SubVi haben, die die Kommunikation regelt, um in der Lage zu sein, diese Parallel anzusprechen. (Jedes Netzteil hängt an einem anderen RS232 Port)
Jetzt musste ich aber feststellen, dass die Software trotzdem mit jedem zusätzlichen Netzteil je ca. 70ms langsamer wird. Beim besichtigen der einzelnen VIs stellte ich dann mit Schrecken fest, dass diese alle auf die gleichen SubVis zur Kommunikation zurückgreifen, welche in der instr.lib des Netzteilherstellers liegt.
Das hebelt natürlich die gesammte parallele Kommunikation aus.

Nun zu meiner Frage:
Gibt es einen eleganten Weg, die Instr.lib für jedes Netzteil zu kopieren?

Denn es handelt sich um ca. 6-8 VIs in dieser lib und diese alle einzeln per Hand zu kopieren und neu einzubinden dürfte Tage dauern.

Anzeige

Ohne die Bibliothek zu kennen, würde ich vorschlagen, dass du die betroffenen VIs auf ablaufinvariante Ausführung zu stellen.
Dann sollte die Kommunikation auch parallel ablaufen.

Hallo,

Im Anhang mal die VI-Hierarchie, wie sie bei allen 6 Netzteil-VIs aussieht. Mit ablaufinvarianter Ausführung habe ich mich noch nicht beschäftigt, ich werde dies testen. Falls dadurch wirklich mehrere Instanzen des SubVi erstellt werden, wäre es genau das, was ich brauche und der gewünschte elegante Weg.

Ändert eine Überführung in eine exe etwas an der Weise, wie SubVIs ausgeführt werden?

(19.05.2016 12:09 )Leticron schrieb:  ich werde dies testen. Falls dadurch wirklich mehrere Instanzen des SubVi erstellt werden, wäre es genau das, was ich brauche und der gewünschte elegante Weg.

Dem kann ich so zustimmen.

Aber Vorsicht bei der Umstellung:
Hier musst du genau kontrollieren. Sollten in den vom Hersteller gelieferten SubVIs z.B. globale Variablen verwendet werden, so kann die Umstellung zu Fehlern führen - respektive die Verwendung der umgestellten SubVIs.
Wenn sich Schieberegister-Variablen in den SubVIs befinden, kann es auch zu Fehlern kommen.

Kontrolliert werden sollte das SubVI "ReadWrite" (vorletzte Ebene, das SubVI mit den vielen Aufrufern).

In deinem Falle wäre eine echte Klasse so mit vollständiger Instanzierung aller Unterprogramme ideal.

(19.05.2016 14:53 )IchSelbst schrieb:  Aber Vorsicht bei der Umstellung:
Hier musst du genau kontrollieren. Sollten in den vom Hersteller gelieferten SubVIs z.B. globale Variablen verwendet werden, so kann die Umstellung zu Fehlern führen - respektive die Verwendung der umgestellten SubVIs.
Wenn sich Schieberegister-Variablen in den SubVIs befinden, kann es auch zu Fehlern kommen.

Kontrolliert werden sollte das SubVI "ReadWrite" (vorletzte Ebene, das SubVI mit den vielen Aufrufern).

Hätte ich deine Antwort vor 3 Stunden gehabt, hätte ich viel furstriertes Testen umgangen! Du lagst 2 mal richtig. Das einzige VI, welches Probleme gemacht hat (und natürlich das Nadelöhr war), war das Read/Write VI. Es hatte eine Schieberegister-Variable, welche ihm sagte, welche Sprache es verwenden soll. Ich habe lange gebraucht, bis ich herausgefunden habe, dass es an der Stelle nach der Umstellung nicht mehr funktionierte.

Nachdem dieser Fehler behoben wurde (habe die Sprache "Hardcoded" reingeschrieben und somit den Regler umgangen), läuft die ganze Geschichte beinahe schon gut. Leider etwas zu langsam. Die Hardware scheint aber am Anschlag zu sein. Schneller als 90ms für ein Querry mit RS232 scheint sie nicht zu schaffen.
Gibt es da noch "Tricks" um dies etwas zu beschleunigen?

(19.05.2016 15:32 )Leticron schrieb:  hätte ich viel furstriertes Testen umgangen!

hättest du wertvolle Erfahrungen nicht machen können ...

Zitat:Die Hardware scheint aber am Anschlag zu sein. Schneller als 90ms für ein Querry mit RS232 scheint sie nicht zu schaffen.

Einerseits sagt jeder, RS232 sei veraltet - andererseits wird sie aber immer noch fleißig verwendet.
Du musst zwei Sachen auseinander halten: Die Reaktionszeit des Endgerätes und diverse Arbeitszeiten vom Treiber. Als Reaktionszeit können 100ms durchaus ok sein. Als Arbeitszeit für den Treiber definitiv nicht.
Ich glaube, das Problem des großen Zeitaufwandes liegt nicht an der Hardware, sondern an der (Software-)Verwaltung eines RS232-Zugriffes (ob LV oder das OS die Probleme verursacht, weiß ich nicht). Ich hatte nämlich ähnliche Probleme beim Pollen mehrerer Schnittstellen. Letztendlich hab ich den direkten Aufruf des Lese-VIs nur dann gemacht, wenn ich gewusst habe, dass genug Zeichen im Puffer sind. Ich habe also zuerst per Property "Anzahl Zeichen im Puffer" gelesen und mit einem entsprechenden Wert verglichen. Nur bei genug Zeichen wird dann das Lese-VI aufgerufen.

(19.05.2016 15:32 )Leticron schrieb:  Gibt es da noch "Tricks" um dies etwas zu beschleunigen?

Hast Du die höchst mögliche Baudrate eingestellt? (Manchmal vergisst man die einfachen Möglichkeiten.)

Gruß Holger

(19.05.2016 15:32 )Leticron schrieb:  Gibt es da noch "Tricks" um dies etwas zu beschleunigen?

Die Default Baudrate von 9600 Baud benötigt 1 ms per Character. Das zählt sowohl für das Kommando als auch die Antwort des Instruments. Dazwischen kommt noch die Zeit die das Instrument benötigt um das emfangene Kommando zu dekodieren und eine enstprechende Antwort zusammenzustellen und in den Ausgangsbuffer zu schreiben. Das sind typischerweise die wichtigsten Faktoren bei einem solchen Instrument. Die VISA Software und die Hardware Treiber im Computer fügen da vergleichsweise unbedeutende Zeit hinzu. Die Baudrate kannst Du gemäss Datenblatt maximal auf 19200 Baud verdoppeln so dass da vielleicht 10 ms weniger anfallen aber der Löwenanteil dürfte doch echt die Antwortzeit des Instrumentes selber sein. Da werkelt typischerweise ein einfacher Embedded Controller vom Type 8051 oder vergleichbar drin. Der ist im Vergleich zu einem modernen PC ungefähr so schnell wie ein Dreiradvelo zu einem Ferrari.

Um das zu enkoppeln müsstest Du das Write-Read VI auseinander nehmen und als seperates Write und Read implementieren. Dann könntest Du zumindest teilweise die Serialisierung durch dieses VI entschärfen ohne diese selber ablaufinvarient machen zu müssen. Aber an der Datenübertragungszeit kannst Du nicht viel verändern ausser Du verwendest eine der GPIB oder LAN Optionen die es für diese Geräte gibt. Aber das ändert so oder so nichts an der Antwortzeit des Instrumentes selber. Die wird nur schneller durch einen kräftigeren Prozessor aber das kostet Geld und eine programmierbare Speisung ist normalerweise nicht als Funktionsgenerator gedacht! Die gibt es zwar zu kaufen, aber die sind in einer ganz anderen Preisregion dann die TDK Geräte.