Ignoriere Broken SubVIs

Hallo zusammen,

ich hab folgendes Problem, was mir ganz schön Nerven kostet:

Ich arbeite mit unterschiedlichen Geräten an einem Testsystem. Dafür gibt es Treiber, organisiert in einem Labview-Projekt.
Mittels Teststand erstelle ich Testsequenzen, die dann später am Testsystem laufen sollen.

Da ich/der Kollege/Person xyz nun nicht immer am Testsystem die Sequenzen entwickeln möchte/kann, sondern auch an einem beliebigen Rechner, soll der ganze Softwarestand auch dort bearbeitet werden können.
Die Konfiguration der einzelnen Testschritte realisiere ich über Teststand-Steptypes (welche dann ein VI öffnen).

Nun zum Problem: da nicht jeder sämtliche Hardware-Treiber auf den Rechnern installiert hat, sind die VI's "broken" (zerbrochener Pfeil) und ich kann das Konfigurations-VI nicht laufen lassen.

Mein Ansatz zur Lösung waren "Conditional Disable Structures" (Bedingte Deaktivierungsstruktur). Ich wollte eine Projektvariable nutzen, um die VI's gar nicht erst zu laden (oder eben doch).

Das Problem ist, dass Teststand (oder auch generell das VI aufgerufen von außerhalb des Projekts) die Projektvariable nicht kennt.


Ein weiterer Ansatz war der Aufruf der SubVIs über Referenz (damit ist das Haupt-VI immer lauffähig). Dies hat aber den Nachteil, dass die spätere Sequenz nicht performant läuft (Referenzaufrufe dauern zu lange).


Hat irgendjemand noch irgendeine Idee???

Vielen Dank und Grüße,
Jörg

Anzeige

Hallo Jörg,

installier doch einfach alle nötigen Hardware-Treiber auf dem Entwicklungsrechner!

Macht man das nicht immer so, dass man einen Entwicklungsrechner (mit allen nötigen Treibern/VIs) hat und einen Produktionsrechner, auf dem (vorzugsweise) eine EXE läuft?

Danke für die schnelle Antwort!

Allerdings ist dein Vorschlag keine Option, da Entwickler und Prüfprogrammersteller nicht die gleichen Personen (und somit der gleiche PC) sind. Wenn man dann Sequenzen für alle Testsysteme entwickelt, wären das sehr viele Treiber zu installieren (die man nie "in echt" braucht).

Weitere Ideen??

Hallo Jörg,

Zitat:Wenn man dann Sequenzen für alle Testsysteme entwickelt, wären das sehr viele Treiber zu installieren (die man nie "in echt" braucht).

Wo ist das Problem? Hat deine Festplatte zu wenig Speicherplatz frei? 2TB kosten weniger als 80€ heutzutage...

Irgendwie ist es doch immer wieder so, dass man mit bestimmten Fragen Grundsatzdiskussionen los bricht, eh man sich der eigentlichen Frage annimmt ;-)
Ohne jetzt zu weit ausholen zu wollen: Die Installation der Treiber ist bei den einzelnen Rechnern nicht gewünscht, die Forderung kommt auch nicht von mir.

Ich würde lieber nochmal der Frage nach VIs außerhalb des Projekts oder der Frage, ob es vielleicht grundsätzlich andere Ansätze gibt, nachgehen.

DANKE!!

Hallo Jörg,

um mit "broken links" aufgrund fehlender VIs umzugehen, hast du folgende Möglichkeiten:
1) Conditional Disable Structure: Funktioniert nur innerhalb von Projekten, da dort die nötige "Variable" definiert ist
2) Disable Structure (von Hand) einfügen: Dann hast du den Aufwand, diese auch wieder zu entfernen, bevor du deine VIs auf die Test-Maschine kopierst...
3) Call By VI-Server: Du hast den Nachteil, dass dies (je nach Art und Weise der Programmierung) zu längeren Laufzeiten führen kann.
1-3) Nachteilig ist, dass man am Entwicklungsrechner keine Rückmeldung der IDE zu anderen Fehlern in den fehlenden VIs bekommt...

Oder:
Man hat einen Entwicklungsrechner, der alle Gerätetreiber (bzw. deren VIs) installiert hat...

Tut mir leid, aber ich kann die Randbedingung "Programmiere bitte Hardware-Zugriffe, ohne die passenden Treiber/VIs zur Verfügung zu haben" nicht wirklich nachvollziehen...

(08.02.2013 16:29 )joerg030284 schrieb:  Irgendwie ist es doch immer wieder so, dass man mit bestimmten Fragen Grundsatzdiskussionen los bricht, eh man sich der eigentlichen Frage annimmt ;-)

Ich glaube nicht, daß es hier um eine Grundatzdiskussion geht!

(08.02.2013 16:35 )GerdW schrieb:  Tut mir leid, aber ich kann die Randbedingung "Programmiere bitte Hardware-Zugriffe, ohne die passenden Treiber/VIs zur Verfügung zu haben" nicht wirklich nachvollziehen...

Das kann ich so nur unterstreichen. Entweder hat man einen vollständigen Rechner zur Entwicklung oder man muß mit den negativen Randerscheinungen leben, die eine Entscheidung zu einem reduzierten Entwicklungssystem mit sich bringt.

Gerds Vorschläge in Ehren, aber mit den "Disable Strukturen" wirst Du auch nicht glücklich werden. Da kann ich ein Lied davon singen.

Grüße
Andreas

Hallo,

Zitat:mit den "Disable Strukturen" wirst Du auch nicht glücklich werden. Da kann ich ein Lied davon singen.

Mögliche Nachteile hatte ich ja bei allen erwähnten Alternativen genannt...

Das mit dem "Lied singen" kann ich nur bestätigen, auch für die ConditionalDisableStructure:
Letztens hatte ich mich maßlos geärgert, dass ich plötzlich keine Executables mehr erstellen konnte!
Grund war, dass ich ein (sub)VI umbenannt hatte, welches auch in einem VI enthalten ist, welches nur in der Executable aufgerufen wird und in der Entwicklungsumgebung durch eine CDS "maskiert" wurde. Beim Executable-Erstellen fiel dem Compiler dann auf, dass ein VI aufgrund eines fehlenden subVI nicht mehr ausführbar war.
Diesmal selber

Hallo Jörg, hallo Gerd, hallo Andreas,

könnte es möglicherweise ein Weg sein, in der Initphase der Appl. die relevanten VIs in den Speicher zu laden, zu prüfen, ob sie ausführbar sind und dann an der Stelle, an welcher der eigentliche Aufruf erfolgt, die VIs namentlich über VI-Referenz öffnen aufzurufen bzw. den Aufruf zu umgehen, wenn das entsprechende VI nicht im Speicher ist, weil es eben nicht ausführbar ist.
Dann müsste doch die Zeit zum Laden der VIs entfallen, da das ja in der Initphase geschah, und der Aufruf sollte ähnlich schnell gehen, wie bei statisch verlinkten VIs?


Gruß, Marko

Habe mir das auch mal durchgelesen. Das mit den unübersichtlich vielen Treibern wundert mich schon. Solange es sich um Hardware von NI handelt, hat man doch das Problem nicht: Es gibt genialerweise für die Hunderte von NI-Karten zur Messdatenerfassung und -ausgabe nur einen einzigen Treiber: NI-Max. Da der aber nicht als "Treiber" so benannt wird und dessen Installation sowieso quasi ein Bestandteil einer Labviev-Installation ist, kann ich mir nicht vorstellen, wie da irgendein Nichttechniker aus dem übergeordneten Management sein Veto dagegen einlegen könnte.

Die Hauptsache aber wurde überhaupt nicht diskutiert. Wenn die Treiber installiert wären, die zugehörige Hardware aber nicht, hätte man zwar keine broken arrays und könnte das Projekt erst mal starten. Die Fehlermeldung kommt aber dann umgehend, da es keine Daten Ein- und Ausgabe gibt. Es ist notwendig, die Hardware zu simulieren, d.h. Vis zur Datenein- und ausgabe müssen durch VIs eretzt werden, die die Ein- und ausgaben simulieren - wenn möglich einigermassen realistisch.

Ich selbst habe auch von Sachsen aus für das ferne Bayern Labview-Software für Messplätze entwickelt, die ich nicht hier hatte. Man muss da etwas Phantasie entfalten. Allerdings hatte ich nicht nur die Treiber installiert, sondern auch die Messkarten dabei. Die "Modellierung" der Messplätze war z.T. Software, aber auch Verdrahtung zwischen den Karten und zu Laborgeräten.