Speicherverwaltung¶
Bildverarbeitungsanwendungen haben im Normalfall einen relativ hohen Bedarf an Arbeitsspeicher, je nach verwendeter Kameraanzahl, Bildgröße und Komplexität. Viper.NET enthält einige Mechanismen, um den Speicherverbrauch zu reduzieren oder einen effizienten Umgang mit Speicher zu ermöglichen.
Max. TgItems in Memory¶
In Viper.NET können theoretisch beliebig viele Bildquellen, Jobs und ToolGroup Items angelegt werden. Mit jedem Objekt steigt aber auch der Speicherbedarf der Applikation. Aus diesem Grund können länger nicht verwendete CogToolGroups, die die Basis der ToolGroup Items sind, automatisch entladen werden. In den Globalen Einstellungen wird festgelegt, wie viele ToolGroup Items maximal gleichzeitig im Speicher sein dürfen. Wenn ein derzeit nicht geladenes ToolGroup Item ausgeführt werden soll, wird zunächst die „älteste“ der im Speicher befindlichen ToolGropus entladen, die angeforderte ToolGroup geladen und anschließen ausgeführt.
Warnung
Das Laden/Entladen von ToolGroups kostet Zeit, die beim ersten Trigger mit eingerechnet werden muss.
Eine Alternative zu vielen parallel geladenen ToolGroup Items bietet die Typverwaltung. Wenn sich nur kleine Teile im BV-Ablauf unterscheiden, z.B. die Patterns eines CogPMAlignTool, kann auch das ToolBlockSelectorTool eine sinnvolle Alternative sein.
Doch wann macht welche Option Sinn? Diese Frage kann nicht pauschal beantwortet werden und hängt von der Charakteristik der Applikation ab:
Hohe Typvielfalt, Anlage wird „typrein“ betrieben -> Typverwaltung
Verschiedene Abläufe für denselben Typen, überschaubare Typvielfalt -> mehrere ToolGroup Items
Geringe Unterschiede zwischen Produktvarianten -> ToolBlockSelectorTool
Garbage Collection¶
Die .NET Laufzeitumgebung, auf der Viper.NET basiert, hat eine automatische Speicherverwaltung (Garbage Collection). Von Zeit zu Zeit muss der Speicher vom Garbage Collector untersucht und nicht mehr benötigter Speicher freigegeben werden. Im Normalfall wird die Garbage Collection automatisch vom System durchgeführt, wenn Speicher benötigt wird und die Gelegenheit „günstig“ scheint.
Je nach Größe der Anwendung hat dieser Vorgang negative Auswirkungen auf die Laufzeit der Bildverarbeitungsjobs. Deshalb kann in Viper.NET eine explizite Garbage Collection nach N Jobs ausgelöst werden. Die Konfiguration erfolgt in den Globalen Einstellungen.
Hinweis
Es wird empfohlen, N auf die Anzahl der konfigurierten Jobs zu setzen.
Speicherverbrauch anzeigen/loggen¶
Der aktuelle Speicherverbrauch kann zur Analyse in der Kopfzeile angezeigt und zyklisch in die Logdatei geschrieben werden. Beides wird in den Globalen Einstellungen aktiviert.