LinkManager:
Until now we did not find a way to run LinkManager on an arm based system. This seems to be a known Issue and there are some post in the internet when searching for Secomea and arm64. Although there is a LinkManager Mobile with very basic functionality that would run on MacOs https://kb.secomea.com/docs/linkmanager-mobile-1, we are currently using a Windows x86 VM in the cloud to connect to our physical machine to have the full functionality. Any one found a better solution?
Question to AI: ”Which is the best way to run B&R link manager on MacBook?”
Answer:
Running B&R LinkManager (Secomea) on a MacBook depends primarily on your processor (Intel vs. Apple Silicon M-series), as the software is natively designed for Windows.
1. For Apple Silicon Macs (M1, M2, M3, M4)
The full LinkManager client does not currently run natively on ARM-based macOS or within standard ARM Windows virtual machines due to driver incompatibilities.
LinkManager Mobile: This is the most compatible native option for Mac. It provides basic web-based functionality that allows you to access web services or VNC on the remote PLC directly through a browser without installing drivers.
Cloud-Based Windows x86 VM: Some users connect to a physical machine or a full x86 Windows VM hosted in the cloud to gain full LinkManager functionality while working on a Mac.
Virtualization Limitations: While Parallels Desktop can run Windows 11 on Apple Silicon, users often report that the specific virtual network drivers required by LinkManager fail to initialize on the ARM architecture.
2. For Intel-Based Macs
If you have an older Intel Mac, you have more robust options:
Virtual Machines: Use Parallels Desktop or VMware Fusion to run a standard Windows 10/11 environment. This allows you to install the LinkManager Windows client directly.
Boot Camp: For the most stable connection, use the Apple Boot Camp Assistant to boot natively into Windows. This bypasses virtualization layers that can sometimes interfere with industrial VPN drivers.
3. Alternative: Browser-Based Diagnostics
B&R System Diagnostics Manager (SDM): If you only need to check hardware status or runtime settings, you can access the System Diagnostics Manager using any standard web browser on macOS, provided you have a TCP/IP connection to the PLC.
Regarding the debugger, second question to AI:
How can we use the Automation Studio debugger on MacBook?
Answer:
Running B&R LinkManager (Secomea) on a MacBook depends primarily on your processor (Intel vs. Apple Silicon M-series), as the software is natively designed for Windows.
1. For Apple Silicon Macs (M1, M2, M3, M4)
The full LinkManager client does not currently run natively on ARM-based macOS or within standard ARM Windows virtual machines due to driver incompatibilities.
LinkManager Mobile: This is the most compatible native option for Mac. It provides basic web-based functionality that allows you to access web services or VNC on the remote PLC directly through a browser without installing drivers.
Cloud-Based Windows x86 VM: Some users connect to a physical machine or a full x86 Windows VM hosted in the cloud to gain full LinkManager functionality while working on a Mac.
Virtualization Limitations: While Parallels Desktop can run Windows 11 on Apple Silicon, users often report that the specific virtual network drivers required by LinkManager fail to initialize on the ARM architecture.
2. For Intel-Based Macs
If you have an older Intel Mac, you have more robust options:
Virtual Machines: Use Parallels Desktop or VMware Fusion to run a standard Windows 10/11 environment. This allows you to install the LinkManager Windows client directly.
Boot Camp: For the most stable connection, use the Apple Boot Camp Assistant to boot natively into Windows. This bypasses virtualization layers that can sometimes interfere with industrial VPN drivers.
3. Alternative: Browser-Based Diagnostics
B&R System Diagnostics Manager (SDM): If you only need to check hardware status or runtime settings, you can access the System Diagnostics Manager using any standard web browser on macOS, provided you have a TCP/IP connection to the PLC.
so just for curiosity, Have you tried to debug your code with AS code?
Ciao
Valerio
Hi @Jonas_Keller ,
I’m waiting an answer from them, in the mean time regarding the second point AS Code and Mac I see we have an update at this post:
So for I see it’s possible to run AS Code and Mac
I hope that post helps your case
Ciao
Valerio
With AS Code I still have the same connection issues even when I follow the steps from the other post. But I don’t use AS Code that often so it is not a blocker.
Regarding the debugger in AS we are in contact with the local B&R support. So maybe we will find there a solution. I will update the post when I have new findings.
Just wanted to confirm this issue is still present in AS 6.7 (tested with AR000 version 6.7.8, Build 1, ArSim/simulation target).
Symptom on my side: gdb reports
(gdb) target remote 127.0.0.1:2323
127.0.0.1:2323: Connection timed out
I dug a bit further and found the likely root cause:
AR000.exe in the generated Temp\Simulation\... output folder is a 32-bit (x86) process.
The gdbserver.exe shipped alongside it in that same folder is a 64-bit (x64) binary.
Manually attaching gdbserver to the running AR000 process (gdbserver.exe --attach 127.0.0.1:2323 <AR000 PID>) fails immediately with:
Attach to process failed (error 87): Falscher Parameter
Exiting
Had an AI assistant help dig into it — looks like an architecture mismatch: AR000.exe runs as 32-bit, but the gdbserver.exe shipped alongside it in this AS/AR version is 64-bit, so it can never attach (Windows rejects cross-bitness attach outright). That would also explain gdbserver “crashing immediately” in your case. Couldn’t find a 32-bit gdbserver anywhere in the AS6 install to swap in either.
Looks like a packaging bug on B&R’s side rather than something fixable from our end.
Would be great if someone from B&R could confirm/fix ?
I got immediately feedback from B&R Switzerland on this. Unfortunately it’s not good news:
This exact topic was already raised before (CASE-65600, “Debugger not running - MAC / Parallels”), which went through several rounds via 2nd level support / PM and was ultimately closed. Virtual machines are officially not supported by B&R.
Product Management’s feedback on this was essentially: there isn’t “the VM” as a single thing — Mac Parallels, VirtualBox, VMware, Docker, etc. are all different solutions, and B&R doesn’t see itself in a position to test and support every possible virtual environment on the market. While it’s known that running AS in a VM is generally possible, it is simply not part of their test scope.
However, I don’t think this is actually a VM problem. I believe it’s specifically a Windows-on-ARM issue.
Has anyone tried this on native Windows ARM64 hardware (not in a VM) ?
