Can LogicLab Control I2C on a Standard Raspberry Pi?

LogicLab on a standard Raspberry Pi has a runtime boundary, not an I2C wiring problem. The Raspberry-specific runtime supplied by Axel supports the standard IEC operators but does not support the Elsist application libraries. The Elsist runtime exposes functions such as SysI2CWrRd, but it accepts only Raspberry modules assembled with the Elsist hardware interface used by the SlimLine Raspberry PI IEC61131-3 CPU.

Start with the target/runtime handshake. Changing I2C settings, GPIO assignments, or application logic cannot correct that identity check.

What fails first in the control signal chain?

The intended chain is sensor or converter, I2C electrical bus, Raspberry bus driver, LogicLab runtime, IEC application, and final output. Each layer must expose an interface to the next one. A valid voltage transition on SDA and SCL proves only the electrical and Linux-driver portions; it does not prove that the selected LogicLab runtime exports an IEC-callable I2C function.

Read the chain from the controller outward. First verify that the IDE remains connected and recognizes the runtime. Then verify that the runtime contains the library object used by the project. Only after both checks pass should bus traffic, device addressing, and application data be diagnosed. Tuning or rewriting IEC logic does not fix a missing runtime plug-in.

Which runtime is installed?

Separate the two runtime families before selecting a device in the IDE:

• The LogicLab runtime supplied by Axel is the path for a commercial Raspberry Pi. It can be installed on Raspberry models that Axel lists as supported, but it does not provide the Elsist-developed libraries.
• The Elsist distribution contains its application functions and function blocks, including objects implemented as C++ LogicLab plug-ins and others written in Structured Text. It is supported only when the Raspberry module includes the Elsist interface for the company’s expansion I/O modules.

That interface is assembled into the SlimLine Raspberry PI IEC61131-3 CPU and is not sold as a stand-alone part. Installing the Elsist software onto standard Raspbian does not turn a commercial board into that CPU. The runtime can begin an Ethernet session and still reject the board when its hardware check runs.

The Mdp154 script was described as installing the LogicLab components on a standard Raspbian distribution. Treat script completion as an installation check, not as proof that the installed runtime supports stock Raspberry hardware. The later hardware restriction decides whether the Elsist runtime can stay connected.

Why does SysI2CWrRd fail after import?

SysI2CWrRd is not a self-contained IEC source routine that can be copied between unrelated targets. Its declaration depends on the corresponding library implementation and runtime plug-in. Exporting the function from an Elsist project and importing it into the Axel Raspberry environment transfers the project-level object, but not the compiled C++ implementation or its runtime integration.

A compile error at that point indicates an unresolved target dependency, incompatible object, or missing library component. Inspect the first compiler diagnostic and identify whether it names the function, its types, or a missing library. Reimporting the same object will not supply the absent runtime service.

The Elsist IDE work covered more than 200 functions and function blocks. Neither a trial nor a purchased license changes target compatibility: licensing authorizes a compatible component after the runtime and hardware checks have passed.

What does the documented I2C mapping require?

On the compatible Elsist platform, SysI2CWrRd accesses the software I2C controller identified as i2c-dev4. The controller is configured in /boot/config.txt on GPIO2 for SDA and GPIO3 for SCL:

# ------------------------------------------------------------------------------
# I2C SLIMLINE BUS CONFIG
# ------------------------------------------------------------------------------
# Software I2C (i2c-dev4) set to max speed (180 Khz).
dtoverlay=i2c-gpio,bus=4,i2c_gpio_sda=2,i2c_gpio_scl=3,i2c_gpio_delay_us=1

The overlay specifies bus 4, a stated maximum speed of 180 kHz, and a delay setting of 1 microsecond. These values describe the supplied configuration; they do not prove that a connected peripheral accepts that bus rate. Read the peripheral datasheet before changing the overlay, then verify SDA and SCL electrically and confirm that the addressed device responds.

A successful bus transaction requires the correct device address, electrical pull-ups, a common reference, and a peripheral compatible with the configured signaling. Those checks come after runtime compatibility. If SysI2CWrRd does not compile, no pin measurement can repair the missing software layer.

Can the project use Raspberry GPIO directly?

The described LogicLab implementation did not expose direct Raspberry GPIO management. Selecting SlimlinexUnified in LogicLab 3.1.0 therefore did not create GPIO handling, and choosing that target solely to obtain a project device produces the wrong architecture.

The I2C overlay’s use of GPIO2 and GPIO3 is not general-purpose IEC GPIO access. Those pins are assigned to the software I2C bus and are operated by its driver. An application needing extra digital or analog I/O must use interfaces actually exposed by its selected runtime and supported hardware; no IEC variable mapping for native GPIO is specified here.

Which branch resolves a standard Raspberry installation?

Make the platform decision before buying licenses or building the application:

1. Identify the physical controller. If it is a commercial Raspberry Pi without the Elsist interface, select the Axel runtime and a device definition supported by that package. Do not select SlimlinexUnified to bypass target detection.
2. Identify the required IEC functions. If the project requires SysI2CWrRd or other Elsist application-library objects, move the application to the assembled SlimLine Raspberry platform. Copying the objects into the Axel runtime does not provide their plug-ins.
3. Separate GPIO from I2C. If direct native GPIO is mandatory, verify that the chosen runtime explicitly exposes it before committing to that architecture. The documented Elsist configuration provides I2C through bus 4 but no direct LogicLab GPIO management.
4. Check model support at the correct source. For a Raspberry Pi 4 using the Axel runtime, consult Axel’s supported-model information. Replacing it with a Raspberry Pi 3 does not address an Elsist-runtime hardware-interface check.

How do you verify the resolving branch?

1. Start a project with the device definition belonging to the installed runtime.
2. Connect over Ethernet and keep the session open beyond the previous 10–15-second failure window. Any incompatible-hardware message still points to a target/runtime/hardware mismatch.
3. Compile an empty project containing only standard IEC logic. This isolates target communication from library dependencies.
4. Add the required library object and compile again. On the Elsist branch, confirm that SysI2CWrRd resolves without a missing-object or incompatible-target diagnostic.
5. On the compatible I2C branch, inspect /boot/config.txt and match bus 4, GPIO2, GPIO3, 180 kHz, and i2c_gpio_delay_us=1 to the documented configuration.
6. Measure SDA and SCL while issuing one controlled read/write transaction. Confirm clock activity, the requested device response, and valid returned data before connecting application decisions or final outputs.
7. Run the project through the required operating period. A 30-minute stop in demo mode is a licensing boundary; an immediate compile failure or 10–15-second disconnect is not.

FAQ