Project folders and files¶

All data belonging to an application are stored in a Viper.NET project folder. This folder normally has the following structure:

File/Folder	Description
Project.makproj	The project file. Can be started directly.
Configuration	Folder with configuration files that are normally only changed during the first setup of the project.
Data	Default data folder for the project. The folder path is configurable as paramsDirectory
Plugins	Project-specific plug-ins can be stored here.
Doc (optional)	Project-specific documentation.

Projects are designed so that all file paths of project-internal dependencies are relative to the makproj project file. Thus, project folders can be stored and moved arbitrarily in the file system.

Hint

The recommended default location for project folders is C:\Gefasoft.

New projects are derived by the Viper.NET installation from ProjectTemplates. The templates to the standard files are located in the ProjectTemplates subfolder of the Viper.NET installation. For example under C:\Program Files\Gefasoft\GEFASOFT Viper.NET 6.4.3.0\ProjectTemplates\

The project file “.makproj”¶

General¶

A project file with suffix .makproj is the central entry point for Viper.NET projects. All project-related files are searched relative to it. Double-clicking a project file in Windows Explorer starts Viper.NET in the version assigned to the project. In the context menu of Explorer, four actions are offered:

Start with “-repair”: Forces a autoinstall which updates the dependencies of the Viper.NET version in the system.
Start with “-simAll”: Starts the project with global hardware simulation.
Start with “-repair -simAll”: Combination of the two actions above.
Upgrade project version: Upgrades the project to a newer version of Viper.NET.

The .makproj project file defines basic settings of the project in XML format. For example, it defines subdirectories and paths of the other project files.

<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>

The project file contains a set of common parameters that are specified as name-value pairs in the format <param name="..." value="..." />. They are initialized with default or user values during project creation. The following parameters are available:

applicationName: Freely selectable project name, assigned when creating the project. The project name is displayed in the sidebar.
autoCreateParamsFile: specifies whether the GlobalParams file should be automatically recreated if it is not found.
autoInstall: obsolete parameter, no longer used.
autoLogoutMinutes: Time in minutes after which a user is automatically logged out if there was no user interaction within the time period.
autoLogoutSkipOnSuperDongle: True disables automatic user logout if a superdongle is attached to the system.
batOnAutoLogout: Path to a batch script (relative to the .makproj) that is additionally executed on every user logout (manual or auto-logout).
callConfigCheckerOnStartup: True enables configuration checking at program startup.
defaultCommandLine: command-line arguments for Viper.NET to use when starting automatically, for example when opening the project by double-clicking in Explorer.
gioPlcSecurityUserManagerXml: Path to the XML configuration of the GInOut PLC Security UserManager (assignment of Viper users to GInOut variables), relative to the paramsDirectory.
gioTypeDataManagersXml: Path to the configuration of the GioTypeDataManager instances (multi-instance mode), relative to the paramsDirectory.
gioTypeDataManagerXml: obsolete, only evaluated for upgrading older projects. Use gioTypeDataManagersXml instead.
ioIni: Path to Viper.xio, relative to the project directory.
paramsDirectory: Directory path for parameter data, relative to the project directory. Default is the subfolder Data
pluginsIgnoreUncriticalChanges: True suppresses the plugin configuration dialog if detected differences between installed and configured plugins are insignificant. This includes plugins that are detected as newly installed or uninstalled but are not active in the project configuration.
projectNumber: Project number for identification, displayed in the sidebar.
screenshotWidgetVisible: Controls the visibility of the screenshot button in the function-panel. This can be used to free up space for other widgets.
shellType: Can be used to use an alternate shell interface from a plugin instead of the default interface. Specifies the type name of the shell form.

Note

In project files of older versions (and partly still in the project templates), further path parameters can be found that are no longer evaluated by Viper.NET. The paths of the associated files are fixed and can no longer be changed via the project file:

conStreamTelPoolFile → conStreamTelPool.xml in the paramsDirectory (can be overridden via the command-line argument -conStreamTelPoolFile)
extAppLayoutChildsConfig → Configuration\extAppLayoutChilds.xml
extAppTabsConfig → Configuration\extAppTabs.xml
log4net → Configuration\log4net.config (can be overridden via the command-line argument -log4net)
parametersFile → globalParams.xml in the paramsDirectory
persistentData → persistentData.xml in the 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

Configuration¶

The MAK project settings for the current project can be adjusted in the global settings directly in Viper.

All important parameters can be changed in the following window:

Warning

Some settings only become active after restarting the application!

Configuration folder¶

The subdirectory Configuration of a Viper.NET project folder contains configuration data that is human readable and editable. The settings mostly concern the basic structure of a project and are therefore usually only edited initially during project creation.

When a new project is created, the folder is populated with copies of a project-templates.

stations.xml¶

Stations must initially be created in stations.xml. The configuration differs depending on the station type and is therefore described in their documentation.

Note

Alternatively, stations can be configured in the Station editor in the user interface.

Additionally the following elements can be defined in the stations.xml:

LiveBitsToggler: Cyclic state change of one or more bits. Can be used to signal to a PLC that Viper.NET is active and running.

<stationConfig>

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

  ...

Note

The LiveBitsToggler is especially recommended when using I/O couplers such as Modbus-coupler that buffer the state of digital inputs and outputs.

ResetBits: One or more bits that the PLC can use to trigger a reset of all stations. Alternatively, a reset bit can be defined for each station.

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

Log configuration - log4net.config¶

The configuration file of the logging system defines which log contents are written to which files and log displays. The file path is fixed as Configuration\log4net.config and can be overridden via the command-line argument -log4net.

shellConfiguration.config¶

The shell configuration file shellConfiguration.config specifies the appearance of the main interface. The file path is fixed as Configuration\shellConfiguration.config.

In the configuration file, for example, the display colors and the logo of the sidebar can be customized. The configuration is done in XML format. The file template contains explanatory comments about the configuration options.

userTabs.xml¶

The tab configuration file userTabs.xml together with the extAppTabs.xml defines the display of tabs in the sidebar of a project. In the userTabs.xml all tabs are configured, which are provided by Viper.NET or its plugins. The extAppTabs.xml defines tabs for the integration of external applications into the project interface.

The file describes the displayed tabs as a list. Each tab is described by an XML account. For example, the vision tab:

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

The name of the tab is used for identification. The type of the tab defines the interface displayed when the tab is clicked. The following types are available by default in Viper.NET:

StationsIO: station-view with visualization of the current bit-states
HardwareExplorer: displays the GInOut Hardware-Explorer
ControlLayoutExtApps: Integrates interfaces of external programs as tabs in Viper.NET. The programs and the interface layout are configured in extAppLayoutChilds.xml files.
GAppenderLog (or the deprecated alias Log): displays the log view
Alarms: displays the alarm view
WebBrowser: embeds a web browser as a tab

This list can be extended by active plugins. For example, the Vision plugin implements additional tabs.

The display order of the tabs in the sidebar is controlled by the param node with name attribute "sortID": the tabs are arranged from top to bottom according to the value attribute of the sortID in ascending sort order

The user tabs are linked in the configuration by the param node with name attribute "operation" to operations from the user-management: The permission of the logged-in user for the respective operation controls whether the user can switch to the respective tab.

extAppTabs.xml¶

In the extAppTabs.xml, sidebar tabs are defined with which external applications are displayed within the project. When the project is loaded, the associated external programs are started and their main windows are integrated into the Viper.NET interface. The path of the configuration file is fixed as Configuration\extAppTabs.xml.

The project template contains a template with commented out example template which embeds the Windows editor as a tab. Comments in the template explain the meaning of the individual parameters.

userAuth.xml¶

The userAuth.xml defines in XML format the basics of user-management. Changes should only be made via the Viper.NET GUI.

plugins.xml¶

The plugins.xml contains the plugin configuration of a project. All installed plugins of the computer are recorded with their respective version, as well as which of them are active and in which order they are loaded when starting the project.

The settings should preferably be adjusted via the Viper.NET GUI, for example in the info-dialog.

When loading a project, the Viper.NET installation is checked for changes in the plugin configuration. If such are detected, the user will be prompted to confirm or correct the configuration.

In the project file, this check behavior can be adjusted via the pluginsIgnoreUncriticalChanges parameter.

Data folder¶

The Data folder serves as a storage location for configuration data created or customized in the Viper.NET interface. Manual changes to the data are usually not necessary.

When a new project is created, the folder is populated with copies of a projkettemplates.

globalParams.xml¶

The globalParams.xml file stores global program parameters. For example, the global-settings are usually stored here, both by Viper.NET and by all plugins. Included parameters should normally only be edited via the Viper.NET GUI.

The file is located as globalParams.xml in the paramsDirectory (default: subfolder Data).

persistentData.xml¶

The persistentData.xml file serves as a centralized repository for Viper.NET and its plugins to store application state data across application launches. For example, the last loaded type of vision-plugin is stored here to be reloaded at application startup. The file should not be edited manually.

Plugins” folder (optional)¶

The Plugins subfolder of a project directory is the default location for deploying project-specific plugins. Viper.NET scans the folder for plugin dlls at project start and adds the folder as assembly directory. Via command-line parameter the path can be overridden to use a different folder as project plugin directory.