Configuring CODESYS on an Apple Silicon MacBook Guide

CODESYS or InoproShop will not install cleanly, or the application starts but cannot connect to a PLC, when an M4 Pro MacBook hosts Windows 11 through VMware Fusion. Treat application execution, device-driver compatibility, network access, and vendor support as four separate commissioning gates. A successful launch proves only the first gate.

Host and guest architecture boundary

An M4 Pro is an Apple Silicon system. VMware Fusion on that host runs Windows 11 for ARM; it does not present the guest as a native x64 Windows computer. Windows can translate many x86 and x64 user-mode applications, but translation does not make an incompatible kernel driver usable. The term kernel driver here means the Windows component that directly controls hardware such as a USB programming adapter.

This distinction explains the common partial-success symptom: an engineering IDE may open while its cable, license service, discovery component, or communications driver fails. Do not classify the platform as compatible merely because the installer finishes.

Layer	Required result	Failure implication
Application	IDE installs and opens without recurring errors	User-mode translation or prerequisite problem
Driver	Windows loads the required device driver	Driver architecture or signing problem
Transport	Guest reaches the PLC through USB or Ethernet	Pass-through, addressing, firewall, or routing problem
Vendor support	Host, guest, and software combination is supported	Troubleshooting may stop at the platform boundary

Check 1: Open Windows system information and read the guest system type. Expect an ARM-based Windows 11 installation. Record that result before evaluating any automation package.

Supported engineering-tool selection

Start with the exact software required by the installed controls. In this case, the plant primarily uses Inovance products and the named engineering package is InoproShop. CODESYS, OpenPLC, and InoproShop are not interchangeable merely because they all relate to PLC programming. A PLC project depends on the target runtime, device descriptions, compiler, communications stack, libraries, and download protocol expected by that controller.

OpenPLC is useful only when the selected controller supports its runtime and the work scope permits a different toolchain. It is not a generic route for opening, maintaining, or downloading an existing InoproShop project. Likewise, getting CODESYS to launch in the virtual machine does not demonstrate that InoproShop, its device catalog, or its communications components will work.

1. Identify the controller family installed on the machine.
2. Identify the engineering package and project-file format used for that controller.
3. Read the package documentation for supported Windows editions and processor architectures.
4. List every required auxiliary component: USB driver, Ethernet discovery service, license manager, device package, and firmware utility.
5. Confirm support for the complete combination, not only the main executable.

Check 2: Compare the installed guest architecture with the engineering package and each required driver. Expect every component to list a compatible Windows architecture. An unlisted ARM environment remains a commissioning risk even if installation succeeds.

Windows virtual-machine preparation

Build the Windows 11 virtual machine as a controlled engineering environment. Apply Windows updates, restart, and confirm that VMware integration components are operating before installing PLC software. Display scaling problems may improve after a restart, but a corrected display says nothing about driver or communications compatibility.

Create a clean restore point or virtual-machine snapshot before adding engineering packages and drivers. This provides a repeatable baseline if an installer changes network filters, services, or device associations. Keep one change per test cycle so a failed connection can be traced to a specific component.

Do not make production work dependent on Box64, Wine layers, or nested translation workarounds. Such a stack adds another executable-translation boundary while leaving Windows kernel-driver requirements unresolved. It also creates a configuration that the automation supplier may not diagnose.

1. Update Windows 11 and restart the guest.
2. Confirm normal display, keyboard, storage, and network operation.
3. Capture the clean baseline.
4. Install only the required engineering package and documented prerequisites.
5. Restart and inspect Windows Device Manager and service status before connecting plant hardware.

Check 3: Launch the IDE twice, including once after a full guest restart. Expect the same startup result, no missing-component message, and no disabled communications module.

Programming-interface connection

Select Ethernet when the controller and engineering package support it because Ethernet avoids a vendor-specific USB programming driver in many installations. The guest still needs a usable virtual network adapter, a valid address on the PLC subnet, and an allowed path through the Windows firewall. Discovery broadcasts may behave differently through network address translation, so direct addressing can work even when automatic discovery does not.

For a USB adapter, attach the device to the Windows guest rather than the macOS host. USB pass-through exposes the hardware to Windows; it does not translate its driver. Device Manager must show the adapter without a warning symbol, and the engineering application must expose the corresponding interface.

Symptom	Diagnostic check	Decision
USB device appears in macOS only	Review VMware USB attachment	Connect the device to the guest
USB device appears with a warning	Read Device Manager status	Obtain a compatible driver or change platform
PLC answers by address but is not discovered	Compare direct connection with discovery	Inspect VM network mode and firewall handling
No network response	Check guest address, subnet, route, and physical link	Correct the first failed layer

Check 4: For USB, expect Device Manager to show the adapter without an error. For Ethernet, expect the guest to reach the controller address through the intended interface before opening an online session.

Controlled first online connection

A personal computer should not be connected to employer-controlled production equipment without plant authorization. The issue is both operational and administrative: the plant controls endpoint security, software licensing, project backups, network access, and change records. A company-provided business-class Windows PC also preserves a supportable boundary between personal and professional systems.

Perform the first test on an authorized controller or isolated commissioning setup. Begin with a read-only identification action if the tool provides one. Confirm controller identity and project context before any download, firmware operation, mode change, or online edit.

1. Obtain authorization for the laptop, interface, and network segment.
2. Back up the existing project through the plant-approved method.
3. Connect to the intended controller without initiating a transfer.
4. Read the controller identity and compare it with the project configuration.
5. Use the engineering tool’s compare function, if present, before selecting upload or download.
6. Stop when identity, project, or communications results differ from the expected machine record.

Check 5: Expect the engineering tool to identify the intended controller and show a stable online connection without changing controller mode or application state.

End-to-end platform verification

Prove the entire workflow before accepting the Mac-based virtual machine for internship work. The test must cover restart recovery and the actual communications path, not only an offline editor session.

1. Guest check: Restart the Mac and Windows guest. Expect Windows 11 to boot normally and retain the configured virtual hardware.
2. Application check: Open InoproShop or the required package. Expect the project and required device definitions to load without missing components.
3. Driver check: Reconnect the programming interface. Expect Windows to recognize it without a Device Manager warning.
4. Transport check: Select the intended USB or Ethernet interface. Expect repeatable access to the authorized controller.
5. Online check: Connect and read controller identity. Expect an exact match with the machine and project records.
6. Recovery check: Close the IDE, disconnect, restart the guest, and repeat the connection. Expect the same interface assignment and online result.

If any check fails because an ARM-compatible component is unavailable or the supplier excludes the virtualized platform, move the work to a company-provided x64 Windows PC. Application translation is not a corrective action for an incompatible driver.

Frequently asked questions