# This header is for providing additional information to hugo for the website generation it ignored by asciidoctor

title: "I/O Configuration for Different Platforms" url: doc/io_config/overview.html page_css_file: /4diac/css/4diac_doc.css layout: "doc-overview" type: "section" sidebar: - sb-doc ---

# I/O Configuration for Different Platforms

Using QX, IX and similar allows you to access the inputs and outputs of a supported hardware. Of course, in the case of a normal computer, this doesn’t apply since it doesn’t have I/O that you can control directly like you do on a PLC (normally boolean). Currently there are two I/O integration concepts, the parameter based and the IO_CONFIG based one.

## Parameter Based I/Os

The parameter based I/O support uses the PARAMS data input of the IX, QX, …​ function blocks. In order to access the I/O of a hardware, you need to set the PARAMS data input to a corresponding value to select which I/O to access. 4diac FORTE should be compiled with the corresponding module, that can be selected in CMake. You find here the values to be set to PARAMS for the following supported platforms:

1. Odroid

2. PiFace Digital 2

3. µMIC.200

4. Bosch Rexroth PLC (MLPI)

5. Lego Mindstorms EV3

6. SysFs (Raspberry Pi, Beagle Bone Black and Similar Boards) (older way to access GPIO pins)

## IO_CONFIG Based I/Os

The IO_CONFIG based I/O support uses an IEC 61499 Resource, that could be called IO_CONFIG_RES, but the naming is up to you. This IEC 61499 Resource contains a function block or a function block network that represents your hardware. If it is only one function block or a network of function blocks, depends on your hardware. Modular PLCs for example are represented as function block network, where one module represents the core module and the others the expansion modules. The function blocks for the supported hardware modules are within the io folder of the type library. Any I/O of a hardware module is represented by a function block input of type STRING or WSTRING. The STRING or WSTRING inputs are then set to the hierarchical name of an IX, QX, …​ function block instance you used within your application. Each hierarchy level is separated by a dot '.'. The hierarchy starts with the name of the IEC 61499 Application, followed by the dot, possible IEC 61499 sub-application names or composite function block names, also separated by dots and at last the instance name of the IX, QX, …​ function block. This concept of I/O support let your IEC 61499 Application be completely hardware independent. For the supported platforms have a look on the following chapters:

1. GPIOChip (Raspberry Pi, Beagle Bone Black and Similar Boards) (newer way to access GPIO pins)

2. PLC01A1

3. Revolution Pi

4. Wago PFC200

## Where to go from here?

You can see the supported protocols:

Supported Communication Protocols

You can see the examples:

4diac Examples

If you want to go back to the Where to Start page, we leave you here a fast access

Where to Start

Or Go to top