Hardware accesses with GInOut

The GInOut module simplifies and standardizes digital communication with external plant controllers. Thanks to its own driver layer, data access from the application point of view always remains the same, regardless of whether communication takes place with a Beckhoff PLC, SIMATIC S7 or simulated hardware via the main memory. This greatly simplifies the simulation of remote stations or porting of an application to other plant controllers.

Configuration

GInOut is parameterized via an XML file (.xio). With the tool GInOutHwExplorer the configuration can also be created outside of Viper.NET and tested at the same time. In Viper.NET the Hw Explorer is included in a sidebar tab.

Some functions are only possible by directly editing the XML file (e.g. removing objects) or are more comfortable (Copy&Paste).

Note

Before making changes in the XML file, Viper.NET should be closed, because the file may be saved on exit.

Hardware and Datablocks

The hardware forms the basis in GInOut. Each hardware has different properties, connection parameters and communication protocols (see also Supported hardware). Any number of hardware objects can be created, i.e. Viper.NET can also be connected to several independent controllers at the same time.

Each hardware has at least one DataBlock (physical data), which enables access to a data area in the hardware. The parameters of a DataBlock depend on the hardware. When accessing TwinCat ADS, for example, a DataBlock corresponds to a TwinCat ADS variable, whereas when connecting Profibus-Hardware the available DataBlocks are fixed by the hardware.

Polling and performance

The data is actively polled from the remote station with almost every available hardware. When using multiple hardware connections, polling runs sequentially hardware by hardware. Comparatively slow remote stations, such as a Simatic S7 via the S7ISOTCP, slow down a poll cycle and GInOut becomes sluggish overall.

To avoid this, you can set for each hardware whether the data should be polled in a separate thread.

  • Advantages of global polling: - With several fast responding remote stations, the CPU is unloaded

  • Advantages of own polling: - Slow hardware does not slow down the whole system

Which setting is correct depends on the specific use case, but as a rule of thumb: Always configure slow hardware with its own poll thread.

Usual cycle times:

Hardware

Cycle time

Beckhoff

? ms

S7ISOTCP

3-70 ms

MemoryMappedFile

0 ms

Data, Bits and Bytes

Hardware and DataBlocks are not visible to the application. Instead, the underlying hardware is accessed via logical data areas or individual configured bits.

A data area is created by offset and length within a DataBlock, i.e. a DataBlock can be divided into several data areas or completely covered by one data area.

Since the data areas are hardware-independent, the configuration is always the same here. The entire further GInOut configuration, but also accesses from Viper.NET, are always related to the data areas.

The digital inputs and outputs (bits) are defined in the data areas.

../../_images/bit-add.gif

Bits are used, for example, for digital station handshake, but can also be included in visualizations.

See also

Variable lists and variables

The byte data provided by or to controllers must be interpreted or prepared on the application side depending on the agreed interface. For example, a serial number can be a 4-byte integer or a 10-digit ASCII text.

Variables provide the ability to provide interpreted data to the application. In each variable must be specified:

  • Data area

  • Byte offset in the data area

  • Length

  • A converter responsible for converting the data to a specific target type.

Variables are always grouped in variable lists.

See also

Python scripts

In GInOut können Python-Skripte angelegt und automatisch ausgeführt werden, wenn sich der Zustand eines zugeordneten Bits oder einer Variablen ändert.

Scripts are usually used for simulations, but can also trigger more complex processes in automated systems.

Viper.NET uses the free .NET Python implementation IronPython.

See also

Axes, cylinders and signal lights

On the basis of the previous basic objects, GInOut contains additional, prefabricated objects that can be used in more complex scanning or placement processes.

Axes

The GInOut axis is an interface to a PLC linear or rotary axis. A new axis is created in the hardware explorer popup menu ‘Add… -> Axis’. This is addressed via the Gefasoft standard handshake for axes. The data exchange takes place via GInOut variables.

See also

Cylinders (Valves)

The GInOut cylinder can control a monostable or bistable cylinder with two end positions via a digital interface. A new cylinder is created in the Hardware Explorer popup menu ‘Add… -> Valve’.

Signal Lights (Signal Lights)

The signal traffic light is a series of output bits via which signals are controlled. A new signal light is created in the Hardware Explorer popup menu ‘Add… -> Signallights’. Each output signal can be set to permanently on, permanently off, or to flashing.

See also

Vacuum cups (Suction Tools)

A vacuum cup can be used in scripts or plugins for Pick&Place applications.

See also