Projektordner und -dateien¶

Alle zu einer Anwendung gehörenden Daten werden in einem Viper.NET Projektordner abgelegt. Dieser Ordner hat im Normalfall folgende Struktur:

Datei/Ordner	Beschreibung
Projekt.makproj	Die Projektdatei. Kann direkt gestartet werden.
Configuration	Ordner mit Konfigurationsdateien, die normalerweise nur bei der ersten Einrichtung des Projekt verändert werden.
Data	Standard-Datenordner für das Projekt. Der Ordnerpfad ist als paramsDirectory konfigurierbar
Plugins	Hier können projektspezifische Plugins abgelegt werden.
Doc (optional)	Projektspezifische Dokumentation.

Projekte werden so gestaltet, dass alle Dateipfade projektinterner Abhängigkeiten relativ auf die makproj-Projektdatei bezogen sind. Somit können Projektordner beliebig im Dateisystem abgelegt und verschoben werden.

Hinweis

Als Standard-Ort zu Ablage von Projektordnern wird der Pfad C:\Gefasoft empfohlen.

Neue Projekte werden von der Viper.NET Installation aus Projektvorlagen abgeleitet. Die Vorlagen zu den Standard-Dateien liegen im Unterordner ProjectTemplates der Viper.NET Installation. Zum Beispiel unter C:\Program Files\Gefasoft\GEFASOFT Viper.NET 6.4.3.0\ProjectTemplates\

Die Projektdatei „.makproj“¶

Allgemein¶

Eine Projektdatei mit Suffix .makproj ist der zentrale Einstiegspunkt für Viper.NET-Projekte. Alle projektbezogenen Dateien werden relativ dazu gesucht. Doppelklick einer Projekt-Datei im Windows-Explorer startet Viper.NET in derjenigen Version, die dem Projekt zugeordnet ist. Im Kontextmenü des Explorers werden vier Aktionen angeboten:

Start with „-repair“: Erzwingt eine Auto-Installation, welche die Abhängigkeiten der Viper.NET Version im System aktualisiert.
Start with „-simAll“: Startet das Projekt mit globaler Hardware-Simulation.
Start with „-repair -simAll“: Kombination der beiden obigen Aktionen.
Upgrade project version: Aktualisiert das Projekt auf eine neuere Version von Viper.NET.

Die .makproj-Projektdatei definiert im XML-Format grundlegende Einstellungen des Projektes. Zum Beispiel definiert sie Unterverzeichnisse und Pfade der weiteren Projektdateien.

<dataStore guid="81f2f63a-9ffa-4313-ae3f-39dc2a7e8a4a" name="GConfiguration" architecture="MSIL" Version="6.4.3.0">
<param name="applicationName" value="Vision_Gefasoft" />
<!-- ... Allgemeine Projekt-Parameter -->
<childStores>
  <!--
    Hier werden die globalen Parameter der aktiven Plugins jeweils in ihrem
    eigenen "Child-Store" gespeichert.
  -->
<childStores>
  <complex name="supportedLanguages">
  <ArrayOfString xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <string>en-US</string>
    <!-- ... Weitere unterstütze Sprachen -->
  </ArrayOfString>
</complex>
<complex name="environmentVariables">
  <ArrayOfEnvironmentVariableData xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <EnvironmentVariableData>
      <Name>GEFASOFT_REFERENCE_TOOLBLOCKS</Name>
      <Value>$paramsDirectory$\ReferenceToolblocks</Value>
    </EnvironmentVariableData>
    <!-- ... weitere Umgebungsvariablen -->
  </ArrayOfEnvironmentVariableData>
</complex>

Die Projektdatei enthält eine Reihe allgemeiner Parameter, die als Name-Wert-Paare im Format <param name="..." value="..." /> angegeben werden. Sie werden bei der Projekterstellung mit Standard- oder Benutzerwerten initialisiert. Die folgenden Parameter sind verfügbar:

applicationName: Frei wählbarer Projektname, der beim Anlegen des Projektes vergeben wird. Der Projektname wird in der Sidebar angezeigt.
autoCreateParamsFile: gibt an, ob die GlobalParams-Datei automatisch neu erzeugt werden soll, wenn sie nicht gefunden wird.
autoInstall: obsoleter Parameter, wird nicht mehr verwendet.
autoLogoutMinutes: Zeitdauer in Minuten, nach deren Ablauf eine automatische Abmeldung eines Benutzers erfolgt, wenn zuletzt innerhalb des Zeitraumes keine Benutzerinteraktion erfolgt ist.
autoLogoutSkipOnSuperDongle: True deaktiviert den automatischen Benutzer-Logout, falls ein Superdongle am System angeschlossen ist.
batOnAutoLogout: Pfad zu einem batch-Skriptes (relativ zur .makproj), welches bei jeder Benutzerabmeldung (manuell oder Auto-Logout) zusätzlich ausgeführt wird.
callConfigCheckerOnStartup: True aktiviert die Konfigurationsprüfung beim Programmstart.
defaultCommandLine: Befehlszeilenargumente für Viper.NET, die beim automatischen Starten verwendet werden, zum Beispiel beim Öffnen des Projektes per Doppelklick im Explorer.
gioPlcSecurityUserManagerXml: Pfad zur XML-Konfiguration des GInOut-PLC-Security-UserManagers (Zuordnung von Viper-Benutzern zu GInOut-Variablen), relativ zum paramsDirectory.
gioTypeDataManagersXml: Pfad zur Konfiguration der GioTypeDataManager-Instanzen (Multi-Instanz-Modus), relativ zum paramsDirectory.
gioTypeDataManagerXml: obsolet, wird nur noch für das Upgrade älterer Projekte ausgewertet. Stattdessen gioTypeDataManagersXml verwenden.
ioIni: Pfad zur Viper.xio, relativ zum Projektverzeichnis.
paramsDirectory: Verzeichnispfad für Parameter-Daten, relativ zum Projektverzeichnis. Standard ist der Unterordner Data
pluginsIgnoreUncriticalChanges: True unterdrückt den Plugin-Konfigurations-Dialog, falls erkannte Unterschiede zwischen installierten und konfigurierten Plugins nur unwesentlich sind. Als solches zählen als neu- oder deinstalliert erkannte Plugins, die in der Projektkonfiguration nicht aktiv sind.
projectNumber: Projektnummer zur Identifikation, die in der Sidebar angezeigt wird.
screenshotWidgetVisible: Steuert die Sichtbarkeit des Screenshot-Buttons in der Funktionsleiste. Damit kann Platz für andere Widgets freigegeben werden.
shellType: Kann genutzt werden, um eine alternative Shell-Oberfläche aus einem Plugin anstelle der Standard-Oberfläche zu verwenden. Gibt den Typ-Namen der Shell-Form an.

Bemerkung

In Projektdateien älterer Versionen (und teilweise noch in den Projektvorlagen) finden sich weitere Pfad-Parameter, die von Viper.NET nicht mehr ausgewertet werden. Die Pfade der zugehörigen Dateien sind fest vorgegeben und können nicht mehr über die Projektdatei geändert werden:

conStreamTelPoolFile → conStreamTelPool.xml im paramsDirectory (per Kommandozeilenargument -conStreamTelPoolFile überschreibbar)
extAppLayoutChildsConfig → Configuration\extAppLayoutChilds.xml
extAppTabsConfig → Configuration\extAppTabs.xml
log4net → Configuration\log4net.config (per Kommandozeilenargument -log4net überschreibbar)
parametersFile → globalParams.xml im paramsDirectory
persistentData → persistentData.xml im paramsDirectory
pluginConfig → Configuration\plugins.xml
saveVersionConfiguration → Configuration\saveVersion.xml
shellConfiguration → Configuration\shellConfiguration.config
stationConfiguration → Configuration\stations.xml
userAuthXml → Configuration\userAuth.xml
userTabsConfig → Configuration\userTabs.xml

Konfiguration¶

Die MAK-Projekteinstellungen für das aktuelle Projekt können in den globalen Einstellungen direkt in Viper angepasst werden.

In folgendem Fenster können alle wichtigen Parameter verändert werden:

Warnung

Manche Einstellungen werden erst nach einem Neustart der Anwendung aktiv!

Ordner „Configuration“¶

Das Unterverzeichnis Configuration eines Viper.NET Projektordners enthält Konfigurationsdaten, welche menschlich lesbar und editierbar sind. Die Einstellungen betreffen zumeist den grundlegenden Aufbau eines Projektes und werden daher in der Regel nur initial bei der Projekterstellung bearbeitet.

Bei der Erstellung eines neuen Projektes wird der Ordner mit Kopien eines Projekttemplates befüllt.

stations.xml¶

Stationen müssen initial in der stations.xml angelegt werden. Die Konfiguration unterscheidet sich je nach Stationstyp und ist deshalb bei deren Dokumentation beschrieben.

Bemerkung

Alternativ können Stationen im Stationseditor in der Benutzeroberfläche konfiguriert werden.

Zusätzlich können in der stations.xml noch folgende Elemente definiert werden:

LiveBitsToggler: Zyklischer Statuswechsel eines oder mehrerer Bits. Kann verwendet werden, um einer SPS zu signalisieren, dass Viper.NET aktiv ist und läuft.

<stationConfig>

  <liveBitsToggler cyleTimeMs="500">
    <bit id="1"/>
    <!-- <bit id="2"/> -->
  </liveBitsToggler>

  ...

Bemerkung

Der LiveBitsToggler wird insbesondere empfohlen, wenn E/A-Koppler wie Modbus-Koppler verwendet werden, die den Zustand von digitalen Ein- und Ausgängen puffern.

ResetBits: Ein oder mehrere Bits, mit denen die SPS einen Reset aller Stationen auslösen kann. Alternativ kann auch für jede Station ein Reset-Bit definiert werden.

<stationConfig resetBits="10,11,12">
  ...

Log-Konfiguration - log4net.config¶

Die Konfigurationsdatei des Logging-Systems definiert, welche Log-Inhalte in welche Dateien und Log-Displays geschrieben werden. Der Dateipfad ist fest als Configuration\log4net.config vorgegeben und kann per Kommandozeilenargument -log4net überschrieben werden.

Siehe auch

Logging

Troubleshooting logging

shellConfiguration.config¶

Die Shell-Konfigurationsdatei shellConfiguration.config legt die Darstellung der Hauptoberfläche fest. Der Dateipfad ist fest als Configuration\shellConfiguration.config vorgegeben.

In der Konfigurationsdatei können zum Beispiel die Darstellungsfarben und das Logo der Sidebar angepasst werden. Die Konfiguration erfolgt im XML-Format. Die Dateivorlage enthält erläuternde Kommentare zu den Konfigurationsoptionen.

userTabs.xml¶

Die Tab-Konfigurationsdatei userTabs.xml definiert zusammen mit der extAppTabs.xml die Anzeige der Tabs in der Sidebar eines Projektes. In der userTabs.xml werden dabei alle Tabs konfiguriert, die von Viper.NET oder dessen Plugins bereitgestellt werden. Die extAppTabs.xml definiert Tabs zur Einbindung externer Applikationen in die Projektoberfläche.

Die Datei beschreibt die angezeigten Tabs als Liste. Jeder Tab wird durch einen XML-Konten beschrieben. Zum Beispiel der Vision-Tab:

<tab name="#Vision" type="VisionTab">
  <param name="operation" value="MainForm.Tabs.Vision"/>
  <param name="sortId" value="0" />
</tab>

Der Name des Tab dient der Identifikation. Der type des Tab definiert die angezeigte Oberfläche beim Klicken des Tabs. Folgende Typen sind in Viper.NET standardmäßig verfügbar:

StationsIO: Stationsansicht mit Visualisierung der aktuellen Bit-Zustände
HardwareExplorer: zeigt den GInOut Hardware-Explorer
ControlLayoutExtApps: Bindet Oberflächen externer Programme als Tab in Viper.NET ein. Die Programme und das Oberflächen-Layout werden in extAppLayoutChilds.xml-Dateien konfiguriert.
GAppenderLog (oder der veraltete Alias Log): zeigt die Log-Ansicht
Alarms: zeigt die Alarm-Ansicht
WebBrowser: bindet einen Web-Browser als Tab ein

Diese Liste kann durch aktive Plugins erweitert werden. Zum Beispiel implementiert das Vision-Plugin zusätzliche Tabs.

Die Anzeige-Reihenfolge der Tabs in der Sidebar wird durch den param-Knoten mit name-Attribut "sortID" gesteuert: die Anordnung der Tabs von oben nach unten erfolgt nach dem value-Attribut der sortID in aufsteigender Sortierung

Die User-Tabs werden in der Konfiguration durch den param-Knoten mit name-Attribut "operation" mit Operationen aus der Benutzerverwaltung verknüpft: Die Berechtigung des angemeldeten Benutzer für die jeweilige Operation steuert, ob der Nutzer zum jeweiligen Tab wechseln kann.

Siehe auch:

Vision-Plugin Shell-Extensions

extAppTabs.xml¶

In der extAppTabs.xml werden Sidebar-Tabs definiert, mit denen externe Applikationen innerhalb des Projektes angezeigt werden. Beim Laden des Projektes werden die zugehörige externen Programme gestartet und deren Hauptfenster in die Viper.NET Oberfläche integriert. Der Pfad der Konfigurationsdatei ist fest als Configuration\extAppTabs.xml vorgegeben.

Die Projektvorlage enthält eine Vorlag mit auskommentiertem Beispiel-Template, welches den Windows-Editor als Tab einbindet. Kommentare in der Vorlage erläutern die Bedeutung der einzelnen Parameter.

Siehe auch:

userTabs.xml

userAuth.xml¶

Die userAuth.xml definiert im XML-Format die Grundlagen der Benuterverwaltung. Änderungen sollten nur über die Viper.NET GUI erfolgen.

plugins.xml¶

Die plugins.xml enthält die Plugin-Konfiguration eines Projektes. Alle installierten Plugins des Rechners werden mit ihrer jeweiligen Version erfasst, ebenso welche davon aktiv sind und in welcher Reihenfolge sie beim Starten des Projektes geladen werden.

Die Einstellungen sollten bevorzugt über die Viper.NET GUI angepasst werden, zum Beispiel im Info-Dialog.

Beim Laden eines Projektes wird die Viper.NET Installation auf Änderungen in der Plugin-Konfiguration geprüft. Werden solche erkannt, so wird der Benutzer zur Bestätigung oder Korrektur der Konfiguration aufgefordert.

In der Projektdatei kann dieses Prüfverhalten über den Parameter pluginsIgnoreUncriticalChanges angepasst werden.

Ordner „Data“¶

Der Ordner Data dient als Speicherort für Konfigurationsdaten, die in der Viper.NET Oberfläche erstellt oder angepasst werden. Manuelle Änderungen an den Daten sind in der Regel nicht nötig.

Bei der Erstellung eines neuen Projektes wird der Ordner mit Kopien eines Projkettemplates befüllt.

globalParams.xml¶

Die Datei globalParams.xml speichert globale Programmparameter. Zum Beispiel werden hier üblicherweise die Globalen Einstellungen gespeichert, sowohl von Viper.NET wie auch von allen Plugins. Enthaltene Parameter sollten im Normalfall nur über die Viper.NET GUI bearbeitet werden.

Die Datei liegt als globalParams.xml im paramsDirectory (Standard: Unterordner Data).

persistentData.xml¶

Die Datei persistentData.xml dient als zentralisierter Speicher für Viper.NET und seine Plugins, um Daten zum Applikationszustand über Programmstarts hinweg zu speichern. Hier wird zum Beispiel der zuletzt geladene Typ des Vision-Plugin hinterlegt, um ihn bei Applikationsstart neu zu laden. Die Datei sollte nicht manuell bearbeitet werden.

Ordner „Plugins“ (optional)¶

Der Unterordner Plugins eines Projektverzeichnisses ist der Standard-Ort zur Bereitstellung projektspezifischer Plugins. Viper.NET durchsucht den Ordner beim Projektstart nach Plugin-Dlls und fügt den Ordner als Assembly-Verzeichnis hinzu. Per Kommandozeilenparameter kann der Pfad überschrieben werden, so dass ein anderer Ordner als Projekt-Plugin-Verzeichnis genutzt wird.

Siehe auch:

Plugin Framework