The story of Honeywell's proprietary C-Bus communication driver began in the last millennium. For the needs of a specific project of our OEM partner, it was necessary to communicate the PLC series EXCEL manufactured by Honeywell. These devices are used in the heating industry, in the automation of exchanger stations, OST (heat take-off stations) and et cetera.
Do you need to establish communication with Honeywell devices using C-Bus?
History
The C-Bus protocol uses the RS-485 bus, supports multiple masters and uses a token-passing mechanism. For these reasons, it requires relatively precise timing, which could not be achieved on standard computers used as application and communication servers around the year 2000 - with the Windows NT and Windows 2000 operating systems. So how did colleagues win over real-time?
They used the KMFB02 communication card from Incos - it was a standard ISA slot card, equipped with an RS-485 interface, an Intel 8051 processor and its own memory. Old-timers know that this widespread and popular microcontroller, developed in 1980, has been popular for decades in the form of many clones and modifications. By the way, we also had the 8051 emulator at home - my father used it for two decades to develop software for MT series industrial terminals manufactured by SAE Elektronik.
The KMFB02 communication card contained firmware for receiving and sending C-Bus messages and correct timing. Receiving and sending messages were handled by using an interrupt for receiving and sending characters via the serial port (the UART circuit of the processor had a buffer for receiving and sending one character). Accurate timing was achieved by using the processor's internal timer. The firmware was developed in Ipesoft in the Modula-2 language and, in addition to the Modula-2 syntax, also contained assembler instructions for the 8051 processor.
The D2000 KOM accessed the card as a special file that was handled by the communication driver for Windows NT/2000. The driver ensured the copying of data to the memory of the ISA card and the operation of control commands:
· serial port speed setting (4600, 9200 or 19200 baud)
· setting of a unique address of ISA card on the C-Bus (1-30)
Veterans of those times divulged that the implementation of the driver for C-Bus took several weeks of hard work (I myself did not work in Ipesoft at that time). The problem included an analysis of a proprietary protocol, tuning of communication time parameters, implementation of firmware for the KMFB02 card and drivers for Windows NT/2000.
Present
Within a specific project, we needed to communicate with equipment from the LION System series (specifically PLC CLLIONLC01 manufactured by Honeywell). But how to do it - today, after 20 years?
We no longer have the ISA card KMFB02 in stock - and even if we did, we do not have a computer with an ISA slot in which we would install it. Moreover, the customer's redundant application servers are virtualized.
The first option is a bit retro - the use of a small communication computer KPX02, which is also built using the 8051 processor. It was "only" necessary to port the communication driver from the ISA card environment to a separate machine and replace communication with the D2000 KOM process, which was performed via direct memory access, by communication via serial port. The KPX02 has one RS-485 port, which was connected to the C-Bus and two other RS-232 ports, one of which was used for communication with the D2000 KOM process. I intentionally wrote "only", because just installing the Multi-Micro MODULA-2 compiler (the installer was designed for Windows 3.x) into a 64-bit Windows 10 environment and running the development environment (16-bit DOS application) under DOSBox was an adventure in itself. In any case, even such a difficult challenge was handled by our experts. This method of communication can now be activated by setting the LineMode protocol parameter to KPX02.
In parallel, we tried another way. What way? Well - compared to the year 2000, computers have become a bit faster. The D2000 supports the NPE X-500 industrial computer, which is based on the Raspberry Compute Module. (Note: the name has no connection with the language of Modula-2 J).
So - could today's 1.2 GHz processor in conjunction with Linux and Ada language handle real-time pitfalls to master real-time communication and 9600 baud token exchange?
After a few days, we know the answer. The D2000 KOM process on the NPE X-500 industrial computer can stably communicate with the CLLIONLC01 PLC device via the built-in RS-485 bus using C-Bus protocol. Those several days were taken by rewriting the original driver from the Modula2 language to the Ada language and implementing an auxiliary communication task with a higher priority, which serves the RS-485 bus.
How's the NPE X-500 processor? Consider it yourself:
The D2000 Kom process uses about 15% of the power of one core for C-Bus communication. If complete debug statements are activated, the load will increase up to 19.9%. This corresponds to the rule they taught us at FEI STU (Faculty of Electrotechnics and Informatics of Slovak Technical University, Bratislava) in the last millennium - the industrial server should normally use about 20% of the CPU power, the rest is a reserve for dealing with peaks and crises. In our case, the real reserve is even 4 times higher, as the NPE X-500 processor is quad-core.
This method of communication is configured with the LineMode protocol parameter set to the value Direct.
Conclusion
Compared to pure informatics, industrial automation differs also by specific time parameters. The devices (and protocols) that are 20 or more years old are still in production. Sometimes it is necessary to communicate with such devices. Sometimes it is necessary to dust off the 20-year-old implementation of the protocol. And possibly modify it to take advantage of technologies existing today. The good news for our customers and OEM partners is - we have people in Ipesoft who can do this. And we have the technology that helps them do that.
