Components > Control, logic & time > Script IDE (LUA / Python)

Introduction

This component is used to implement custom workflows and user-specific logic within EisBaer. The number of inputs and outputs can be freely defined and processed by the script.

The supported scripting languages are LUA and Python.

Use of scripting languages

LUA is particularly suitable for time-critical, event-driven or cyclic control logic within EisBaer.
Python is particularly suitable for more complex calculations, structured data processing and users with existing Python experience.

The choice of scripting language has no impact on the available inputs and outputs.

Developer notice

This component is intended exclusively for users with solid knowledge of LUA or Python.
No free support is provided for custom-written scripts.
Incorrect or inefficient scripts may lead to malfunctions or system instability.

Accessing arrays

Arrays in EisBaer are defined in the Channel Editor using the setting “Number of elements (array)”.
These EisBaer arrays are always zero-based and are available to the script regardless of the scripting language used.

Example – channel configuration

INPUTS:
Input[0] … Input[7]

OUTPUTS:
Output[0] … Output[3]

Python Interpreter – Installation and initialization

To use Python, a separate Python installation is required.

EisBaer 3 requires Python 32-bit.
EisBaer 4 requires Python 64-bit.

Both versions can be installed in parallel, but must be located in separate directories.

Path configuration:
Base Path: Root directory of the Python installation
Home Dir: Lib\site-packages
DLL Path: Root directory of the Python installation (pythonXY.dll)

Important note regarding initialization:
The first start of the simulation from the Script Editor may take approximately 30–45 seconds.
During this time, the simulation mode must not be enabled or disabled.
It is recommended to connect the diagnostic output to a log window to monitor when initialization has completed.

Important for Python:

The Python setup must be installed as a 32bit version (EisBaer3) or 64bit version (EisBaer4) in order to use .

Select "Install Now"

At the end of the installation, you will be asked whether the character limit should be deactivated (Disable path lenght limit). This must be deactivated.

After installation, "Auto Search" must be executed in the Script Interpreter component in the Language Interpreter parameter. This sets all the necessary path settings.

Data points of the component

Component name	Type	Type Function
Diagnosis [Text]	Output	Attention: Diagnostic or debug outputs are only intended for use in the event of an error. Please only use them after consulting the support team! If used, they can significantly impair the performance of the service.
Dynamic	Folder	The edited inputs and outputs are provided as data points in this folder.
Extended diagnostics	Input	The output of the diagnostics can be extended here with an On value.
Driver On/Off	Bidirectional	Switch LUA on or off.
Processing delay [ms]	Bidirectional	Execution of the script can be delayed at runtime.
End script	Output	An ON edge is output when the script has been processed.
Script error	Output	An ON signal is output if the script contains errors, otherwise an OFF signal is output.
Script running	Output	An ON signal is output if the script is being executed, otherwise an OFF.
Script processing time [ms]	Output	Outputs the script processing time in milliseconds.
Update script code	Input	The script code from the higher-level LUA is updated with any signal.
Script code Output	Output	The script code entered can be transferred to another LUA.
Script code input	Input	The script code of a higher-level LUA can be received.
Cyclical trigger interval [s]	Bidirectional	The cyclical execution of the script can be set at runtime.

Properties of the component

Name	Standard	Function
Language interpreter	Lua	Option for switching between LUA and Python as the script language. To use Python, this must also be installed as a 32bit version (EisBaer3) or 64bit version (EisBaer4). At the end of the installation, you will be asked whether the character limiting should be deactivated. This should be deactivated.
Predefined modules	...Custom	Only for LUA! If available, ready-made scripts can be loaded here. To do this, the complete data set (script (.lua), channel list (.luaChannels), encryption file (.luaPasswd) if required and possibly icon (.png)) must be stored in the directory C:\Program Files (x86)\Alexander Maier GmbH\EisBaer SCADA 3.0\Devices. The file name must be the same for all parts.
Channels	0	The inputs and outputs can be created in the channel editor. The number of data points per channel can also be set here. If a number is entered, the data points are part of an array and are addressed via the channel name. The channel name can only consist of letters [a-z][A-Z], numbers [0-9] and the underscore character [_]. Other characters are not allowed. Umlauts such as "ä" are converted to "ae".
Script file		Only for LUA! Enter the storage path if a script file is to be executed. If nothing is entered, the code from the LUA itself is used.
LUA Code	230 bytes	Opens the Code Editor. see also Extensions
Code editor - font size	10	Adjustment of the font size within the Code Editor.
Codeeditor - Font colour		Adjustment of the font colour within the Code Editor.
Codeeditor - Background		Adjustment of the background colour within the Code Editor.
Password		Here you can protect the access to the code editor with a password.
Trigger		Here you can set when the code should be executed. Inputs (selected) --> Trigger on change at the selected input. Cyclic (interval) --> Code is automatically executed after the set time. Inputs and cyclic --> Code is triggered both when there is a change at the marked input and after time has elapsed.
Cyclic trigger interval [s]		Time setting for the cyclic execution of the code. Only has an effect if cyclical was also selected under "Trigger".
Processing delay [ms]	0	The script call is delayed by the specified time after a trigger input is changed.
Delay Trigger During Execution		If enabled, triggers are delayed during script execution and the script is triggered once after completion. This avoids multiple execution of the script if multiple trigger inputs are triggered at the same time.
Execute script at start		If this option is set, the script is executed immediately at system start.
Read out network values on startup		Read out and accept network values at start. This can be used to trigger the interpreter itself. Default values can only be accepted if there is no network at the data point.
UTF8 Encoding		Set to process strings in UTF8 format.
Driver On/Off		Switch interpreter on or off.

Notes on using trigger settings

The trigger options available in the component properties define when and how often a script is executed. The following notes complement the reference tables and explain the interaction between the options as well as typical usage scenarios.

Event-driven execution

This mode is suitable for logic that must react immediately to changes of input values.

Note:
If multiple inputs change at nearly the same time, it is recommended to configure a short processing delay to ensure that all values are stable before the script is executed.

Cyclic execution

Cyclic execution is suitable for logic that must be checked or recalculated regularly, even if no input values have changed.

Note:
The cycle interval should always be chosen so that the script execution time is significantly shorter than the configured interval.

Combination of event-driven and cyclic execution

This mode is useful when immediate reaction to events is required, while a periodic recalculation or supervision is also necessary.

Note:
This configuration should be used deliberately, as it increases the number of script executions.

Avoiding multiple script executions

If multiple trigger inputs are used or values change rapidly, it is recommended to buffer triggers while the script is running and execute the script once again after completion. This improves system stability and avoids unnecessary repeated calculations.

Execution on system start

Executing the script at system start is recommended for initialization tasks, setting start values, or calculations that are required immediately after startup.

Best practice (summary)

- Pure reaction to changes → event-driven
- Regular checks → cyclic
- Combination of both → combined
- Many trigger sources → enable processing delay and trigger buffering