Skip to main content

Inputs & Outputs

Inputs and outputs are the interface between the PLC program and the outside world. Inputs are used to read data from sensors or other devices, while outputs are used to control actuators or other devices. In logiccloud, inputs and outputs are defined directly in the code using a specific syntax, depending on the intended usage and behavior.

There are several aspects of the I/O configuration that can be defined in the code:

  • Direction: IN, OUT, or IN_OUT to specify whether the variable is an input, output, or both.
  • HMI Visibility: HMI or NO_HMI (default) to indicate whether the variable should be visible in the HMI.
  • Internal: INTERNAL to indicate that the variable is for internal use only and should not be used in connectors. Typically, such variables are used for HMI-only values.
  • Reset policy (only for outputs):
    • NO_RESET to specify that the variable should not be reset during a program reset.
    • RESET_DEFAULT (default) to specify that the variable should be reset to its default value during a program reset.
    • RESET_TO <constant value> to specify that the variable should be reset to a specific constant value during a program reset.

The syntax for defining inputs and outputs in the code follows the patterns shown in the examples below:

VAR_INPUT 
varA, varB: INT { IN }; // Input variables with default reset policy and no HMI visibility
varC: BOOL { IN HMI }; // Input variable visible in HMI
varD: REAL { IN INTERNAL }; // Internal input variable
END_VAR

VAR_OUTPUT
varE: INT { OUT RESET_DEFAULT }; // Output variable with default reset policy
varF: BOOL { OUT HMI NO_RESET }; // Output variable visible in HMI and not reset on program reset
varG: REAL { OUT RESET_TO 3.14 }; // Output variable reset to 3.14 on program reset
END_VAR

VAR
varH: INT { IN_OUT }; // Input/Output variable with default reset policy and no HMI visibility
varI: BOOL { IN_OUT HMI }; // Input/Output variable visible in HMI
varJ: REAL { IN_OUT INTERNAL }; // Internal Input/Output variable
END_VAR

In these examples, various input and output variables are defined with different configurations for direction, HMI visibility, and reset policies. This allows for flexible and precise control over how the PLC program interacts with external devices and systems.

tip

Note: The syntax for defining inputs and outputs must be followed precisely to ensure correct behavior in the logiccloud environment:

{ DIRECTION [HMI|NO_HMI] [INTERNAL] [RESET_POLICY] }

The order of the attributes within the curly braces matters and should be as shown above. The DIRECTION attribute must always come first, followed by optional attributes in the specified order.

I/O Variable names

The names of the generated access variables will be the same as the variable names defined in the code. For example, if you define an input variable named sensorValue, the corresponding access variable will also be named sensorValue. This naming convention helps maintain consistency and makes it easier to identify and use the variables in the HMI or other external systems.

Variables defined as IN_OUT will have two access variables generated: one for input and one for output. The naming convention for these variables will be as follows:

  • For the input part: <variable_name>_INPUT
  • For the output part: <variable_name>_OUTPUT

Nested I/O Definitions

In addition to defining inputs and outputs at the top level of a POU, logiccloud also supports nested I/O definitions within function blocks. This allows for more organized and modular code, especially when dealing with complex data types. For example:

FUNCTION_BLOCK FB_MyFunctionBlock
VAR_INPUT
inputVar: INT { IN };
END_VAR
VAR_OUTPUT
outputVar: BOOL { OUT };
END_VAR
VAR
ioVar: STRING { IN_OUT HMI };
END_VAR
END_FUNCTION_BLOCK

PROGRAM MyProgram
VAR
fbInstance1: FB_MyFunctionBlock;
fbInstance2: FB_MyFunctionBlock;
END_VAR
END_PROGRAM

In this example, the function block FB_MyFunctionBlock has its own input, output, and internal I/O variable. When instances of this function block are created in the program MyProgram, each instance will have its own set of I/O variables as defined within the function block. This encapsulation helps in managing complexity and enhances code readability.

When using nested I/O definitions, the generated access variable names will include the instance name to ensure uniqueness. In the above example the following access variables will be created:

  • fbInstance1_inputVar
  • fbInstance1_outputVar
  • fbInstance1_ioVar_INPUT
  • fbInstance1_ioVar_OUTPUT
  • fbInstance2_inputVar
  • fbInstance2_outputVar
  • fbInstance2_ioVar_INPUT
  • fbInstance2_ioVar_OUTPUT

This naming convention ensures that each instance's I/O variables can be easily identified and accessed without conflicts.

I/O Variable List

The variable list is updated as soon as the project is saved. If the code contains errors, the variable list will not be updated until the errors are resolved and the project is successfully saved. This ensures that the variable list accurately reflects the current state of the code and prevents inconsistencies that could arise from unresolved errors.

If there are access variables defined with earlier versions of logiccloud, they will be preserved in the variable list even if they are not defined in the current code. This allows for backward compatibility and ensures that existing configurations remain intact. The legacy access variables are highlited in the list.

If a variable is defined in the code and matches an existing legacy access variable, the existing access variable will be updated to reflect the new definition from the code. This ensures that any changes made in the code are accurately represented in the access variable list, maintaining consistency between the code and the access variables used in the HMI or other external systems.

io-variable-list.png

The legacy access variables are highlighted in yellow in the list above. To remove all legacy access variables that are no longer defined in the code, you can use the "Remove Legacy Access Variables" button (highlighted in the screenshot). This will clean up the variable list and ensure that it only contains access variables that are currently defined in the code.