Upgrade auf die neueste LabVIEW-Version

Die Migration einer Anwendung auf die neueste Version von LabVIEW kann einfach und fehlerfrei verlaufen, wenn die richtigen Prozesse und Verfahrensweise befolgt werden. National Instruments ist bekannt, dass die Umstellung auf eine andere Version der Entwicklungsumgebung zusätzliche Zeit und die erneute Validierung einer Applikation erfordern kann. Dieser Artikel stellt die erforderlichen Schritte zur Aktualisierung vor, um die genannten Risiken und weitere Herausforderungen im Verlauf des Upgrades zu verringern.

Upgrade-Prozess

NI hat sich der langfristigen Kompatibilität und Kontinuität seiner Produkte verschrieben. LabVIEW wird inzwischen jährlich aktualisiert, um einen optimierten Übergang von einer Version zur nächsten zu gewährleisten. Das Ziel besteht nicht darin, dass alle LabVIEW-Anwender jedes Jahr ein Upgrade durchführen, stattdessen soll sich der Upgrade-Prozess so nahtlos und problemlos wie möglich gestalten, ganz gleichgültig, ob von der letzten Version, oder von einer viel älteren Version aktualisiert wird.

Viele Erweiterungsmodule und Toolkits, die National Instruments anbietet, basieren auf G. Mit jeder neuen LabVIEW-Version wurden auch die in G geschriebenen Module und Toolkits portiert. Dieses Dokument stellt den Prozess vor, der von NI intern genutzt wird. Alle erforderlichen Schritte zum erfolgreichen Upgrade einer LabVIEW-Anwendung werden leicht verständlich erläutert.

An LabVIEW-Upgrades sollte immer mit einem klar definierten Prozess herangegangen werden. Ein Leitfaden für die Durchführung von Upgrades vereinfacht den Prozess. Die folgende Abbildung stellt den Prozess, der in diesem Dokument erklärt wird, übersichtlich dar.

[+] Bild vergrößern

Dieser Prozess bietet eine systematische Methode zur Bewältigung des Upgrades.

Obwohl dieser Prozess bei NI über viele Jahre hinweg gut funktioniert hatte, gab es keine Garantie dafür, dass er auch auf gängige LabVIEW-Anwendungen anwendbar war. Dieser Prozess ist dabei auch durch das Feedback von Entwicklungsabteilungen großer internationaler Firmen weiterentwickelt und verfeinert worden. Das dabei gesammelte Feedback diente dazu, den Prozess feinabzustimmen.

Allgemeine Empfehlungen

Bevor die Details des von NI empfohlenen Upgrade-Prozesses dargestellt werden, sollen an dieser Stelle allgemeine Empfehlungen skizziert werden.

Wenn möglich, sollte eine Testmaschine genutzt werden, wenn LabVIEW-Code aktualisiert wird. So beeinträchtigen Probleme im aktualisierten Code nicht den Programmcode, der in einem Entwicklungs- oder Produktionssystem eingesetzt wird. In vielen Fällen sind die Kosten für eine Testmaschine nicht so hoch wie die Kosten, die eine mögliche Verzögerung der Inbetriebnahme nach einem Upgrade nach sich zieht. Um sicherzustellen, dass der Entwicklungscode nicht beeinträchtigt wird, sollte eine vollständig unabhängige Version oder Kopie des Programmcodes isoliert werden. Der Einsatz von Quellcodeverwaltung für den Überblick über die verschiedenen Dateiversionen kann diesen Prozess vereinfachen. Ein weiterer Vorteil eines systematischen Upgrades besteht darin, dass er die Dokumentation von Problemen während des Upgrades erleichtert. Die Dokumentation dieser Probleme gewinnt an Bedeutung, wenn das Upgrade später auch auf weiteren Rechnern durchgeführt werden soll.

Darüber hinaus ermöglichen Sicherheitskopien vor dem Upgrade, wenn nötig, eine einfache Wiederherstellung des ursprünglichen Codes. Es gibt auch Wiederherstellungswerkzeuge, mit denen Systeme in einen bestimmten Zustand zurückversetzt werden können.

• Werkzeuge für die Replizierung von Echtzeitsystemen
• Altiris Deployment Solution
• Norton Ghost
• Acronis True Image

Upgrade-Ressourcen

Für die Vorbereitung auf den Upgrade-Prozess kann es extrem hilfreich sein, im Voraus zu wissen, welche Änderungen an der LabVIEW-Umgebung vorgenommen wurden, auf die aktualisiert werden soll. Diese Informationen stehen in zahlreichen Ressourcen zur Verfügung, die entweder mit dem Produkt mitgeliefert werden oder auf der Website ni.com zu finden sind.

LabVIEW-Plattform-DVDs

Bevor man ein Upgrade in die Wege leitet, muss man unbedingt verstehen, welche Versionen von LabVIEW-Modulen, -Toolkits und NI-Treibern mit der neuesten LabVIEW-Version kompatibel sind. Die neuen LabVIEW-Plattform-DVDs vereinfachen diesen Prozess, denn mit ihnen lassen sich LabVIEW-Module, -Toolkits und Treiber in einem Schritt installieren. Jedes auf den DVDs enthaltene Produkt wurde für LabVIEW massenkompiliert und die Toolkits lassen sich installieren, ohne vorhergehende Installationen zu beeinflussen. Dadurch wird die Wartung mehrerer Versionen von LabVIEW auf demselben Computer vereinfacht. Es ist nicht mehr notwendig, Toolkit-Dateien ins neue LabVIEW-Verzeichnis zu kopieren, die Windows-Registry manuell zu editieren oder LabVIEW-Toolkit-Code einer Massenkompilierung zu unterziehen.

Informationen zu LabVIEW-Upgrades

Die LabVIEW Upgrade Notes sid eine bisher zu wenig genutzte Upgrade-Ressource. Diese mit jeder neuen LabVIEW-Version aktualisierten Upgrade-Hinweise sind im Lieferumfang jedes LabVIEW-Upgrades, auch im Rahmen des Standard Service Program (SSP), enthalten Die Upgrade-Hinweise enthalten einen Abschnitt mit dem Titel „Upgrade and Compatibility Information“, der Informationen über Veränderungen umfasst, die ein Upgrade mit sich bringt, etwa neue Funktionen, veraltete VIs und Verhaltensänderungen von LabVIEW. Die LabVIEW 8.6 Upgrade Notes erläutern etwa, dass es das VI Create Semaphore nicht mehr gibt und empfehlen stattdessen das neue VI Obtain Semaphore Reference. Außerdem gibt es eine Übersicht über die funktionellen Unterschiede der beiden VIs. Der Abschnitt „Upgrading From“ bietet darüber hinaus die notwendigen Informationen, wenn über mehrere Versionen von LabVIEW hinweg aktualisiert werden soll. 

Die LabVIEW Upgrade Notes stehen hier zur Verfügung.

Dabei sollte bedacht werden, dass Änderungen an den Lower-Level-VIs, die mit LabVIEW oder anderen NI-Produkten installiert werden, also VIs, die nicht in den LabVIEW-Paletten auftauchen und sich oft als llbs im Ordner vi.lib befinden, in den Upgrade Notes nicht dokumentiert werden. Diese Low-Level-VIs sind im Allgemeinen nur für die Verwendung seitens NI gedacht. Allerdings könnten einige davon auch in bestimmten Anwendung von Nutzen sein und dort eingesetzt werden. Da die Änderungen an diesen VIs nicht dokumentiert werden, wird empfohlen, den Gebrauch und Speicherort solcher VIs zu dokumentieren. So können sie im Falle eines Upgrades separat getestet werden, um zu gewährleisten, dass keine Änderungen die Anwendung negativ beeinflussen. Kommen keine Low-Level-VIs von NI zum Einsatz, sollte kein zusätzlicher Prüfaufwand anfallen.

Tests mit dem LabVIEW Upgrade Analyzer

Ein Service, den LabVIEW 8.6 bietet, ist der Upgrade Analyzer, der jetzt auf NI Labs (ni.com/labs) zur Verfügung steht. Diese Suite von Upgrade-Tests wurde konzipiert, um bestehenden Programmcode auf Schwierigkeiten beim Upgrade zu überprüfen. Obwohl nicht jeder bekannte Fehler über eine automatische Prüfung des Programmcodes aufgedeckt werden kann, überprüft diese Suite den Code auf bekannte Fehler und bietet zusätzliche Informationen und Workarounds. So sind diese Tests beispielsweise dafür konzipiert, Codeabschnitte oder bestimmte Konfigurationen von Code zu identifizieren, die bei der Migration zu einer Änderung im Verhalten führen könnten. Dies könnte auf eine veraltete Funktionalität oder Updates älterer VIs zurückzuführen sein. Sie werden keine Probleme feststellen, die ein Ergebnis der Einstellungen der Umgebung oder der Entwicklungsumgebung selbst sind. Wenn weitere Fehler gemeldet werden, aktualisiert NI die Test-Suite entsprechen.

Fehlerbehebungen in LabVIEW

Bei nahezu allen Softwareprodukten kommt es mit der Einführung neuer Versionen zu unerwartetem Verhalten, auch als „Bugs“ oder Fehler bekannt. LabVIEW ist dabei keine Ausnahme. National Instruments verfolgt einen Entwicklungsprozess, der die Auslieferung qualitativ hochwertiger Software zum Ziel hat. Der NI-Prozess ist als Qualitätsmanagementnorm ISO 9001 für Qualitätsstandards bei Software zertifiziert. Weiterhin wird die Existenz von Bugs dadurch gemildert, dass LabVIEW eine flexible Programmiersprache ist, so dass es für die meisten Bugs einfache Workarounds gibt. Dieses Problem wird durch die jährlichen Wartungsversionen, die meist sechs Monate nach einer neuen Version erscheinen, weiter entschärft.

Falls ein kritischer Fehler entdeckt wird, für den es keinen einfachen Workaround gibt, können NI-Ingenieure in Zusammenarbeit mit der Entwicklungsabteilung Service Patches entwickeln. In der LabVIEW-8.6-Readme-Datei stehen Informationen über behobene Fehler zur Verfügung. Veränderungen in LabVIEW in Folge einer Fehlerbehebung könnten unabsichtlich das Verhalten eines LabVIEW-Programms nach dem Upgrade verändern. Deshalb sollte man die Liste behobener Fehler überprüfen, um festzustellen, ob die eigene Anwendung betroffen ist. Jedoch kommt es in der Praxis nur selten vor, dass ein LabVIEW-Programm durch die Behebung eines Fehlers beeinträchtigt wird.

Vorbereitung der Umgebung

Nachdem man sich der Veränderungen bewusst ist, die den Programmcode einer Anwendung möglicherweise beeinflussen können, besteht der nächste Schritt in der Vorbereitung der Upgrade-Umgebung.

Quellcodeverwaltung

Die Verwendung von Quellcodeverwaltung für den Upgrade-Prozess kann äußerst nützlich sein. Man kann damit Dateien mehreren Entwicklern bereit stellen, Sicherheit und Qualität erhöhen und Änderungen an gemeinsamen Projekten zurückverfolgen. Besonders beim Upgrade großer Anwendungen spielt die Versionsverwaltung eine wichtige Rolle. Mit ihr lässt sich älterer Code wiederherstellen, falls es zu ernsthaften Beeinträchtigungen kommt. Die Quellcodeverwaltung wird für jede große Anwendungsentwicklung in LabVIEW empfohlen, doch besonders nützlich ist sie für Upgrades. Bei NI verwendet das LabVIEW-Entwicklerteam die Software Perforce für die Quellcodeverwaltung. Es gibt jedoch für diesen Zweck auch viele andere Softwareprodukte, die sich gut in LabVIEW integrieren lassen. 

Mehr über die Quellcodeverwaltung steht hier bereit: Quellcodeverwaltung in LabVIEW und Richtlinien für Entwicklergruppen bei anspruchsvoller Konfigurationsverwaltung

Testcomputer

Eine sorgfältige Vorbereitung der Upgrade-Umgebung kann den Upgrade-Prozess erheblich vereinfachen. Die Upgrade-Maschine sollte nicht mit der Entwicklungs- oder Produktionsumgebung in Verbindung stehen, ihre Konfiguration sollte jedoch einem geprüften Produktionssystem so ähnlich wie möglich sein. Die oberste Priorität besteht darin, sicherzustellen, dass ein Upgrade der Anwendung auf die neue Version das Verhalten der VIs nicht verändert. Änderungen in der Umgebung können zu Abweichungen beim Timing und der Ausführungsreihenfolge des Programms führen, was wiederum Probleme in dem Code verursachen könnte, der bereits vor dem Upgrade existierte. Dabei kann es schwierig werden, diese Abweichungen von Verhaltensänderungen in Folge des Upgrades der Anwendung zu unterscheiden. Die Upgrade-Umgebung erleichtert, wenn sie sorgfältig vorbereitet wurde, diese Schwierigkeiten, indem der aktualisierte Code isoliert wird. Sobald die Anwendung in der Testumgebung korrekt aktualisiert wurde, müssen für die Übertragung des Upgrades auf die Entwicklungs- und/oder Produktionsumgebung einfach nur die Änderungen an der Upgrade-Umgebung vervielfältigt werden.

Auch der unabhängige Test von Peripheriesoftware sollte bedacht werden. Viele Upgrade-Probleme können auf Treiber und andere Peripheriesoftware zurückgeführt werden, die sich beim Upgrade der LabVIEW-Umgebung ändern. Oft ist für ein Upgrade der LabVIEW-Umgebung ein gleichzeitiges Upgrade der Peripheriesoftware und der Treiber notwendig, damit die neue LabVIEW-Version unterstützt wird. Dabei kann es unter Umständen zu Problemen kommen, wenn es in der Peripheriesoftware Verhaltensänderungen gibt. Treten solche Probleme auf, kann oft nur schwer festgestellt werden, ob das Problem aufgrund von Änderungen in LabVIEW oder Änderungen in der Peripheriesoftware entstanden ist. Macht das LabVIEW-Upgrade auch eine Aktualisierung von Peripheriesoftware notwendig, wird empfohlen, auf die neueste verfügbare Version zu aktualisieren, welche die verwendete Hardware unterstützt. Darüber hinaus können vor dem Upgrade des LabVIEW-Entwicklungssystems verschiedene Maßnahmen ergriffen werden, um die erforderlichen Upgrades der Peripheriesoftware zu testen. Das ist nicht immer möglich. Wenn die Peripheriesoftware aber auf die Version aktualisiert werden kann, die in der neuen Version von LabVIEW auf dem System, das momentan mit der vorherigen LabVIEW-Version läuft, verwendet wird, dann kann die Peripheriesoftware auf dieses vorherige LabVIEW-System aktualisiert und können Tests durchgeführt werden, bevor das Upgrade auf LabVIEW vorgenommen wird. So sind beispielsweise die NI-DAQmx-Treiber, die mit den neuen Versionen von LabVIEW veröffentlicht werden, in der Regel mit den vorherigen LabVIEW-Versionen kompatibel. Bevor man also LabVIEW und die Treiber auf die aktuelle Version bringt, kann man zuerst nur die NI-DAQmx-Treiber auf dem System mit der LabVIEW-Vorgängerversion upgraden. Diese testet man dann, um eventuelle Upgrade-Probleme beim DAQmx-Treiber zu identifizieren. Anschließend wird LabVIEW mit den zuvor getesteten neuen DAQmx-Versionen auf die neueste Version aktualisiert.

Massenkompilierung

Nachdem das Upgrade-System sorgfältig vorbereitet ist, kann das eigentliche Upgrade vorgenommen werden. Die Durchführung eines Upgrades erfordert die Massenkompilierung der Anwendung auf die neueste Version. Zuvor sollte sie jedoch auch einmal in der bestehenden Version durchgeführt werden. Die Massenkompilierung kann man auf der LabVIEW-Menüleiste unter Werzkeuge > Erweitert > Massenkompilierung einleiten. Dabei besteht die Möglichkeit, VIs im Cache zu speichern, so dass sie nicht jedes Mal geladen werden müssen, wenn ein Top-Level-VI kompiliert wird. Damit kann die Dauer einer Massenkompilierung erheblich verkürzt werden. Abhängig vom verfügbaren Speicher der Maschine ändert sich die Anzahl der VIs, die sich im Speicher befinden sollten, aber eine Zahl zwischen 50 und 80 ist meist realistisch. Darüber hinaus ist es möglich, den Prozess in einem Log-File zu dokumentieren. Dies ist wichtig für den Upgrade-Prozess, da man so erfährt, bei welchen VIs Probleme aufgetreten sind. Nachdem der Code in der Ausgangs- und der Zielversion massenkompiliert ist, kann man die Logs überprüfen und nach folgender Warnung suchen:

“the VI expected to be at __ was loaded from __”

Diese Warnung informiert den Anwender über eine neue Verbindung in der Testumgebung. Die entsprechenden Verbindungen sollten korrigiert werden. Eine weitere Warnung ist folgende:

“Could not load __ because __ in memory”

Es handelt sich dabei um Fehler durch Querverbindungen, bei denen LabVIEW auf das falsche SubVI verlinkt, weil mindestens zwei VIs auf der Festplatte denselben Namen haben.

 Hier gibt es weitere Informationen über Probleme durch Querverbindungen.

Die meisten Eintragungen in der Log-Datei sind solche Warnungen vor falschen Pfaden. Sie werden immer in gewissem Umfang auftreten, außer wenn die Verzeichnisstruktur der Upgrade-Maschine identisch mit der der Entwicklungsmaschine ist. Nachdem die Warnungen über verschobene Dateien überarbeitet wurden, verschwinden sie nach einer zweiten Massenkompilierung und ausschließlich ernstere Probleme mit VIs bleiben übrig. Das liegt daran, dass die Verbindungen während der ersten Massenkompilierung aktualisiert wurden. Im Bericht zur Massenkompilierung sollte man nach folgendem String Ausschau halten, um fehlerhafte Objekte zu identifizieren, die in der Anwendung auftreten.

“Insane Object”

Der Log zeigt auch an, ob diese fehlerhaften Objekte von der Routine der Massenkompilierung repariert wurden. Auch diese Zeichen stellen fehlerhafte VIs dar.

“###”

Zwar kommt es nur sehr selten vor, aber es kann passieren, dass die Massenkompilierung abbricht, wenn sie mit instabilen VIs arbeitet. Bei der NI-internen frühen Entwicklungsphase einer neuen LabVIEW-Version passiert das recht häufig, wird aber während der Entwicklung behoben. Es ist sehr unwahrscheinlich, dass eine Massenkompilierung abstürzt, außer ein bestimmtes VI ist in schlechtem Zustand und bringt auch LabVIEW zum abstürzen, wenn es geladen und gespeichert wird. Wenn dies passiert, zeigt die Log-Datei an, welche Datei den Abbruch ausgelöst hat. Die entsprechenden Dateien müssen gefunden und geöffnet werden, um sicherzustellen, dass sie nicht beschädigt sind. Dann erfolgt eine neue Massenkompilierung. In seltenen Fällen könnte es notwendig sein, eine solche Datei aus dem Ordner zu entfernen, wenn die Massenkompilierung ein Verzeichnis aufgrund dessen nicht erfolgreich abschließen kann.

Reparatur fehlerhafter VIs

Nach erfolgreichem Abschluss der Massenkompilierung müssen nicht ausführbare VIs identifiziert werden. Enthält der aktualisierte Code solche fehlerhaften VIs, sollte man sich als Anwender nicht von ihrer großen Zahl einschüchtern lassen. Vielleicht sind tatsächlich nur ein paar wenige VIs nicht ausführbar, die aber in der Anwendung als SubVIs häufig zum Einsatz kommen. Mit dem Fenster, das die Fehlerliste enthält, können zunächst die fehlerhaften SubVIs lokalisiert und repariert werden. Behebt man diese Fehler in den SubVIs, verschwinden auch die Fehler, die sich von ihnen über die Aufrufkette verbreitet haben. Nicht ausführbare SubVIs können aus verschiedenen Gründen auftreten. Werden VIs verschoben oder fehlen sie auf der Upgrade-Maschine, zeigen die aufrufenden VIs einen unterbrochenen Ausführungspfeil. Das kann passieren, wenn nicht alles korrekt von der Produktionsmaschine kopiert wurde. Darüber hinaus führen periphere Treiber oder Software, die nicht auf der Upgrade-Maschine installiert ist, dazu, dass aufrufende VIs einen unterbrochenen Ausführungspfeil anzeigen. Ein weniger häufiger Grund ist, dass der aktualisierte Code eine Eigenschaft von LabVIEW enthält, die in der neuen Version nicht mehr unterstützt wird. Solche Probleme werden mittels Codemutationen und Kompatibilitäts-VIs automatisch behoben, sie können aber auch mittels des Upgrade Analyzer identifiziert werden.

Die Reparatur beschädigter VIs in einer Anwendung ist in der LabVIEW-Entwicklungsumgebung leicht möglich. Die einfachste Methode ist die Erstellung eines neuen VIs in der neuen Version und die Integration der Top-Level-VIs der ursprünglichen Anwendung in dieses VI. Dazu gehören Framework-VIs, VI-Bibliotheken und dynamische VIs. Die Top-Level-VIs werden nacheinander ins Diagramm integriert. Erscheint ein fehlerhaftes VI, lässt sich seine Grundursache mithilfe des unterbrochenen Ausführungspfeils und der Fehlerliste ermitteln. Dabei fängt man am besten von unten nach oben an, um Fehler, die durch die Aufrufkette verursacht werden, zu mindern. Kann die Ursache für ein beschädigtes VI nicht gefunden werden, lädt man es in die frühere Version, um sicherzugehen, dass der Fehler auf das Upgrade zurückzuführen ist und nicht bereits vorher bestand. Weitere Unterstützung bietet der technische Support von NI.

Probleme bei aktualisiertem Code

Aktualisierte Anwendungen können von zwei Arten von Fehlern betroffen sein, die nicht zu einem unterbrochenen Ausführungspfeil führen. Der erste ist ein Bug in der neuen LabVIEW-Version, der in der vorherigen Version nicht vorhanden war. Zwar kommt es selten vor, doch kann dieser Bug Verhalten oder Leistung der Anwendung in der neuen Version beeinträchtigen. Ein solcher Bug kann NI über den technischen Support mitgeteilt werden. NI-Anwendungsingenieure kümmern sich dann um einen Workaround. Die zweite Schwierigkeit, welche die Anwendung beeinflussen könnte, ist ein Problem mit der Migration an sich. Das heißt, dass NI veränderten Quellcode in LabVIEW integriert, der dann eine Anwendung beeinflusst. Enthält dieser mutierte Code einen Bug, betrifft das Problem auch den aktualisierten Programmcode der Anwendung.

Test

Das Testen, einer der wichtigsten Schritte bei einem Upgrade, wird oft vernachlässigt. Dabei bedeutet eine aktualisierte Version, die ablauffähig ist, nicht unbedingt, dass sie sich auch erwartungsgemäß verhält. Sorgfältiges Testen gewährleistet, dass das Upgrade erfolgreich war. Dabei ist es wichtig, einen Großteil des Tests auf dem Upgrade-System vorzunehmen, bevor die geänderte Anwendung ins Entwicklungssystem übernommen wird. Darüber hinaus sollte das Entwicklungssystem getestet werden, bevor wiederum diese Änderungen ins Produktionssystem implementiert werden. Die Synchronisation von Entwicklungs- und Produktionssystemen erleichtert und beschleunigt den Prozess der Implementierung von Änderungen am Produktionssystem.

Zusammenfassung

Jeder Upgrade-Fall ist einzigartig und setzt gewisse Entscheidungen seitens des Anwenders voraus. Diese betreffen kritische Komponenten einer Anwendung, Kompromisse, die man eventuell eingehen muss, und ein Verständnis dafür, welches Ziel der jeweilige Programmcode verfolgt. NI ist sich der Tatsache bewusst, dass jedes Upgrade eine Herausforderung darstellt und arbeitet ständig daran, den Prozess so einfach wie möglich und wichtige Informationen dazu leicht zugänglich zu machen. So haben SSP-Kunden beispielsweise Zugang zu Software- und Upgrade-Spezialisten, eine Gruppe von Ingenieuren im technischen Support, die speziell für LabVIEW-Upgrades geschult sind. Das Ziel besteht darin, den Upgrade-Prozess so nahtlos und problemlos wie möglich zu gestalten, gleichgültig ob Sie von der letzten Version oder von einer viel älteren Version aktualisieren. Mit der Veröffentlichung von LabVIEW 8.6 hat NI eine Reihe neuer Funktionen und Werkzeuge eingeführt, die Anwender beim Upgrade unterstützen.

Online-Schulungen: Beste Verfahrensweisen beim Upgrade

Online-Schulungen: Beste Verfahrensweisen beim Upgrade von LabVIEW-Anwendungen (SSP erforderlich)

Sehen Sie den Webcast "LabVIEW – Neue Funktionen der grafischen Entwicklungsumgebung"