The original control software for our Rigaku Geigerflex XRD machine is DOS-based, with a rather non-intuitive text-based user interface. To be able to run this software on a modern computer requires installing DOS and the control program on a virtual machine (we used VirtualBOX). To get the data files out of the virtual machine environment a shared folder is used that holds the files and allows access from both DOS and the Windows 7 host system. All of this is very inconvenient for the user and I started a project to write a new control software for the Rigaku based on National Instruments LabVIEW.
I began a similar project about 3 years ago, but the resulting program had a poor user interface and internal design, and the communication with the instrument was buggy at best. The program was never used in a production environment. Instead, we relied on the original DOS program.
For the newly developed LabVIEW program I chose the an event-driven state machine design. This separates user events from the program logic and creates a clean, easy to understand block diagram. it also allows to expand the program’s capabilities in a straightforward way.
For communication with the instrument I relied on the protocol described in more detail here.
The GUI layout is very simplistic, with the data display in the center and various control/indicator clusters arranged around it. The functionality of these cluster groups is based on the original DOS software to allow similar workflow.
As an additional feature, I added the capability to directly read the goniometer angles by pressing the corresponding button. The communication protocol had such a command available, but the original program used this function only implicitly with other commands.
The main problem I faced with the old LabVIEW version of the program was the lack of detecting the end of a transmission with reliability. The RS232 port has data control signals, but either they weren’t used with this instrument or my lack of understanding RS232 was too significant, either way the old program hung up periodically while reading from RS232.
For the new version I went a different route. When data was expected from the instrument, the program goes into a while loop, reading single bytes of data, until [CR] (carriage return) and Null Byte  was received. Although not very elegant, this code works quite well and no more hang-ups of the program ocurred.
The program has two parallel while loops. The main loop, containing the UI event structure and the state machine, and the emergency stop loop, which monitors the STOP button and sends a stop command to the machine when activated.