In this video, I show how to create a serial connection between a 45 years old computer and Business Central. The same principle can be used to communicate with weights and other machines with a serial interface. Check it out:
In this video, Erik demonstrates serial communication between Business Central (running in the cloud) and a physical serial device — in this case, an IMSAI 8080 computer from the 1970s running CP/M. Using his Cloud2Disk project, Erik shows how AL code in Business Central can open a COM port, send commands, and read responses from a device connected via a classic 9-pin serial cable. This walkthrough covers the architecture of the Cloud2Disk proxy, the AL code involved, and practical use cases like weight stations and industrial equipment.
The World of Serial Communication
Before USB (Universal Serial Bus) became ubiquitous, devices communicated over serial connections using cables like the 9-pin serial connector. While serial may seem like a relic, it’s still widely used today — from weight stations to industrial controllers and various embedded systems. Many pieces of equipment still only offer serial communication as their interface.
The challenge arises when you need to communicate with such a device from Business Central running in the cloud. You can’t exactly plug a serial cable into a cloud server. This is precisely the problem Erik’s Cloud2Disk project aims to solve.
Demo: Connecting to an IMSAI 8080 via Serial
To demonstrate, Erik connects his PC to an IMSAI 8080 — a computer from the late 1970s running CP/M 2.2 with 54K of RAM. The serial connection runs at 9600 baud (9,600 bits per second) with 8 data bits, 1 stop bit, no parity, and no handshaking. With the overhead of start and stop bits, this works out to roughly 960 characters per second.
Erik first demonstrates the connection using PuTTY on COM port 5, showing basic CP/M operations like directory listings and even launching WordStar 3.3 from a floppy disk. This confirms the serial link is working at the hardware level.
Cloud2Disk Architecture
The Cloud2Disk system consists of three components:
- Business Central — running in the cloud with the Cloud2Disk extension installed
- Local Access Module — a client application running on the local PC that has physical access to the serial port
- Azure Communication Proxy — a relay sitting in Azure that bridges the two
By definition, a cloud-hosted Business Central instance cannot directly connect to a program on your local machine. The proxy solves this: the local client establishes an outbound connection to the Azure proxy, creating a reverse open connection. Business Central also connects to the proxy. The proxy then relays communication between them. Both endpoints register within the same tenant, with security measures ensuring no cross-tenant communication.
Serial Communication from AL Code
Erik built a “Serial Communication Explorer” page in Business Central that mirrors the settings you’d find in PuTTY — COM port number, baud rate, data bits, stop bits, parity, and handshake settings.
Connecting to the COM Port
On page open, the extension registers as a Cloud2Disk client. When the user clicks Connect, the AL code calls into Cloud2Disk to open the COM port with the specified parameters:
// Opening the COM port through Cloud2Disk
CloudToDisk.OpenComPort(Port, Speed, DataBits, StopBits, Parity, Handshake, Timeout);
If the call succeeds, the connection is established. On the local machine, the Cloud2Disk client receives an “Open COM Port” task and opens the physical port. To disconnect:
// Closing the COM port
CloudToDisk.CloseComPort();
Writing and Reading Data
To send data to the serial device, you call the write method with the text to transmit. To read the response, you call the read method. Erik notes that because the IMSAI is relatively slow to respond, he adds a one-second delay before reading:
// Writing to the COM port
CloudToDisk.WriteComPort(TextToSend);
// Wait for the device to respond
Sleep(1000);
// Reading from the COM port
ResponseText := CloudToDisk.ReadComPort();
There are also stream-based versions of these operations for handling binary data or larger payloads.
Buffering Behavior
One important aspect of this architecture is buffering. Since the communication is relayed through a proxy, the local Cloud2Disk client continuously buffers incoming serial data as long as the COM port is open. When you call Read from AL, it returns whatever has been buffered up to that point.
Erik demonstrates this by resetting the IMSAI three times while the COM port remains connected. When he then reads from Business Central, he receives 585 bytes — the accumulated boot messages from all three resets. Unlike traditional serial programming where you’d separately check if data is available and then read it, Cloud2Disk combines both operations into a single read call. If there’s nothing buffered, the read simply returns empty.
Practical Use Cases
While connecting to a vintage IMSAI 8080 makes for a fun demo, the real-world applications are more practical:
- Weight stations — reading truck weights from a scale connected via serial
- Industrial controllers — sending commands and reading status from manufacturing equipment
- Measurement instruments — collecting data from lab or field devices
- Any scenario where you need to send a command and read a response from a serial device
Erik notes that this implementation is designed for command-and-response style communication. It won’t support complex file transfer protocols like Kermit, XMODEM, YMODEM, or ZMODEM — but those aren’t common use cases for Business Central integration. The sweet spot is simple, reliable serial communication: send a command, read the result.
Conclusion
Cloud2Disk’s serial communication capability elegantly bridges the gap between cloud-hosted Business Central and physical serial devices. By using an Azure-based communication proxy with a local client agent, AL developers can open COM ports, send data, and read responses from serial devices — all from standard AL code running in the cloud. The buffered read approach simplifies the programming model, and the architecture ensures secure, tenant-isolated communication. Whether you’re connecting to modern industrial equipment or a 40-year-old computer, the pattern is the same: open, write, read, close.
