Communication With the CNC Milling Machine Using Raspberry PI

The purpose of this project is to automate the communication process with the machine while ensuring remote access.

SWOT Analysis – Communication with the Laser Machine

Strengths

1. Standardization: Using an HID port helps avoid compatibility issues associated with traditional COM ports.
2. Reliability and Recognition: The Mach3 software is widely used in the industry for CNC machine control, ensuring an active community and technical support.
3. Automation and Precision: Automated communication reduces human intervention, limits production errors, and improves task repeatability.
4. Low Latency: The HID protocol allows rapid command transmission, essential for precise machine control.

Weaknesses

1. Limited Compatibility: Some CNC machines use HID ports that are not natively supported by software without specific plugins.
2. Dependency on Software and Drivers: Using Mach3 and proprietary drivers (e.g., BL-USBMach3-V22) limits flexibility and may be problematic if support ends or compatibility issues arise with newer versions.
3. Lack of Native Support on Other OS: The system is designed for Windows, making it difficult to use on Linux or macOS without specific adaptations.

Opportunities

1. Optimization of Operating Costs: Automating communication reduces human intervention time, minimizing errors and manual task management costs.
2. Transition to Industry 4.0: Improved communication opens the door to integration into a connected, intelligent environment where machine management is centralized and optimized.

Threats

1. Software and Driver Obsolescence: Dependence on proprietary software (e.g., Mach3) and specific drivers exposes the system to compatibility risks if hardware or OS evolves.
2. Windows Dependency: Use of Windows APIs (WriteFile, CreateFileA, etc.) prevents the system from being portable to other platforms (Linux, macOS).

Simple Communication with the CNC Machine

To analyze the scenarios, it's first necessary to establish normal communication to:

1. Verify that the physical connection is correctly established.
2. Identify the communication protocol used.
3. Ensure bidirectional communication between the software and the CNC machine works properly.

Results of Initial Communication

1. Physical Link Verification: The lsusb and ls /dev/tty* commands were executed, but the CNC machine did not appear.
2. Communication Test: A test was conducted, and the software successfully controlled the CNC machine’s movements along the X, Y, and Z axes, confirming communication.
3. Port Identification: Using the USBDeview tool, the port used was identified as a USB HID port.

Definition of an HID Port

An HID (Human Interface Device) port is a communication interface used to connect human peripherals like keyboards, mice, game controllers, and some industrial devices via USB. It allows the computer to detect and interact with these devices.

Advantages of the HID Port

In the case of the CNC milling machine, the HID port is used because:

1. Simplified USB Communication: The machine is automatically recognized without requiring complex configuration.
2. Low Latency: HID enables fast command transmission, which is useful for CNC control.
3. Standardization: Many industrial devices use HID to avoid compatibility issues with traditional serial (COM) ports.

An analysis of the software (Mach3) revealed the port type used for the machine connection. While exploring the configuration options, I observed that the software supports communication via a USB parallel port. Moreover, in Mach3, the "Serial Output" section allows configuring communication with an external device through a COM port.

This suggests that Mach3 does not natively support HID peripherals for machine communication. However, a specific plugin provided by the manufacturer enables this connection by ensuring the board is detected and allowing smooth communication via the HID protocol.

This plugin is the BL-MachUsb-V22.dll file. To verify this hypothesis, I used the tool "Ghidra" to analyze its operation. The results confirm this, particularly through the presence of a call importing hid.dll, indicating use of the HID protocol.

How is this link established?

To understand how this DLL enables communication, it is essential to analyze its functions.

The functions imported from hid.dll allow for device management, but communication between Mach3 and the machine relies on a function exported by the DLL. The software must be capable of calling this function to send and receive commands.

Function: SetCode()

Among the exported functions, SetCode appears responsible for sending commands. Its operation involves several steps:

1. Parameter Preparation:
2. Retrieves and prepares values to be sent to the device.
3. Handles registers and constructs a data buffer.
4. Device Access:
5. Establishes a connection with the HID device.
6. May use CreateFileA() to open a handle.
7. Command Construction:
8. A command code passed to SetCode().
9. Other necessary information for the device.
10. Command Transmission:
11. Uses WriteFile() to send the command.

This analysis confirms that SetCode() is used to transmit commands to the peripheral device. Therefore, the following steps must be taken:

1. Install BL-MachUsb-V22.dll on the Raspberry Pi.
2. Retrieve the address of the SetCode() function from the .dll file.
3. Send a command using SetCode().

Following research, a new approach allows Windows to run on a Raspberry Pi (Windows 11 on Raspi).

BVM (Botspot Virtual Machine) – Windows 11 ARM VM for Raspberry Pi

BVM is a powerful and user-friendly solution for running Windows 11 ARM on Linux ARM systems such as Raspberry Pi 4/5, using KVM (Kernel-based Virtual Machine) virtualization.

Main Features:

1. Seamless Network Connectivity: Integration with the Linux network allows immediate use of Ethernet and Wi-Fi.
2. Software Compatibility: Thanks to Microsoft’s Prism emulator, Windows x86/x64 applications can run.
3. Optimized Consumption: BVM (excluding Windows) consumes less than 1 GB of RAM and minimal CPU when idle.
4. USB Passthrough: Enables Windows to directly access USB peripherals.
5. File Access: Connect mode allows Windows to access Linux files as a network share.

BVM Architecture: A Hybrid Between Virtualization and Emulation

BVM is based on an intelligent combination of virtualization and emulation, suitable for ARM systems like Raspberry Pi 4/5. The goal is to run Windows 11 ARM as smoothly as possible while maintaining compatibility.

Why a Hybrid Approach?

Traditional solutions for running Windows on Raspberry Pi are usually limited by:

1. Pure Emulation (e.g., QEMU): Slow, as it must translate every x86 instruction to ARM.
2. Native Virtualization (e.g., KVM): Fast, but limited to ARM systems without native support for x86/x64 apps.

BVM overcomes these limitations by combining both:

1. Virtualization via KVM: Runs Windows 11 ARM with high performance by leveraging the Raspberry Pi’s hardware.
2. Emulation via Microsoft Prism: Allows launching x86/x64 Windows applications by translating their instructions in real time.

Why combine virtualization and emulation?

1. Performance Optimization:
2. Direct virtualization of Windows ARM avoids the overhead of full emulation and ensures smooth system execution.
3. Emulation is limited to x86/x64 apps, avoiding overall system slowdowns.
4. Maximum Software Compatibility:
5. BVM smartly leverages virtualization for speed and emulation for compatibility, providing a functional and efficient solution on Raspberry Pi.

BVM Installation

The BVM (Botspot's Virtual Machine) tool is available on GitHub and can be easily installed by following the instructions provided in the official repository:

🔗 BVM GitHub Repository

To install BVM, simply run the following command in your terminal:

This script will install BVM and its required dependencies on your system. Once installed, BVM provides an easy-to-use interface for managing and launching virtual machines, including Windows 11, on devices like the Raspberry Pi.

🛈 Note: Ensure you have virtualization support enabled and sufficient disk space available before proceeding with the installation.

It is important to highlight that the choice of this launch and display solution resulted from a series of experiments conducted on several display servers. The main challenge encountered was that the Windows system windows, intended to be displayed via the BVM interface, were not rendering as expected. This issue was linked to the fact that the environment used was a virtual machine, not a native system.

Automation of the Windows Launch Process

The Bash script automates the process of starting the VNC server, Websockify, and the Windows system via BVM, so that everything is launched automatically when the Raspberry Pi starts. A log file (start-vnc.log) is also generated to ensure complete traceability of the process.

1. VNC Server Check: The script checks if a VNC server instance is already running on display :2. If it is, it is gracefully stopped.
2. VNC Server Launch: A new VNC session is started on :2 with a custom resolution of 2000x800.
3. Display Configuration: The DISPLAY environment variable is set to :2.0 to ensure the following processes use the active VNC graphical interface.
4. Websockify Launch: Websockify is started in the background (-D), with the necessary parameters to connect the VNC server to web port 9090, allowing access via a browser using noVNC.
5. Execution of Windows via BVM:
6. The Windows virtual machine is first launched in silent mode (boot-nodisplay) to avoid blocking the interface.
7. It is then connected using ./bvm connect, which displays it in the active VNC session.

Despite configuring the .vnc/xstartup file, I encountered a gray screen issue when connecting via VNC. After several unsuccessful attempts and drawing from solutions found on various forums:

1. Raspberry Pi Forum
2. Ask Ubuntu
3. GitHub Discussions

I was finally able to identify a solution that works in my case, which is presented in the following section.

Remote Control of Windows via Web Browser

The configuration of the .vnc/xstartup file allows defining the graphical environment to launch when a VNC session starts.

1. xrdb "$HOME/.Xresources": Loads user-specific graphical preferences (like fonts or window colors).
2. xsetroot -solid grey: Sets a plain gray background to avoid a black or empty screen while the full desktop loads.
3. export XKL_XMODMAP_DISABLE=1: Ensures that the GNOME desktop environment starts correctly.
4. /etc/X11/Xsession: This is the main command that launches the system’s default graphical session.

Additionally, a configuration using raspi-config helps optimize remote graphical display using the X11 protocol, which is essential for integrating virtual applications and graphical display via interfaces like VNC.