Automating Manufacturing Processes with Linux

In a standard Linux system, if you wrote a function to poll the inputs of a data acquisition card at a set interval, your task would have less than favorable results. Such a system cannot guarantee the scheduling priority that it would receive. In the standard Linux operating system, as illustrated in Figure 2, all of the system processes are isolated from the hardware. This would not be so bad if our data polling was the only process the system performed. Our project, however, required user-space programs and a guarantee that the sensor inputs were polled every 1 millisecond. The hard real-time system would guarantee that sensor inputs would not be missed.

Figure 2. RTLinux System Flow

In the RTLinux operating system, also illustrated in Figure 2, the real-time task is isolated from the rest of the system processes and is implemented as a module. The module gains direct access to the hardware and the DAQ card drivers while receiving the priority that it needs over the rest of the system. The module is written to perform a specific task that produces reliable results and presents them to the user through the FIFO device files. The code for the module is kept simple, performing only tasks that must be held to hard real-time restraints. Connecting a handler function to one of the FIFO device files can control the module from the operator interface program. This structure, produced by RTLinux, ensures that the kernel cannot delay important module task with secondary priorities.

We needed to monitor only digital input status with hard real-time requirements, which made the real-time function fairly small. Polling the data inputs was made easy, because United Electronics Industries provided RTLinux drivers with their DAQ card. A DAQ card from ADLINK Technology, Inc., also was tested with drivers for the RTLinux platform, and it configured easily. Not many companies provided such a service. The Comedi Project, however, offers another option for open-source drivers, tools and libraries for data acquisition.

The real-time task was written in the form of a loadable module, which has to have at least two functions: init_module, called when the module is inserted into the kernel, and cleanup_module, which is called right before it was removed (Listing 1).

Once the base module structure was established, we needed to create a thread for our real-time task in the module. The thread was created inside of the init_module and was set up to run with established RTLinux priorities. Establishing the priority and rate of execution for the thread was an important step to creating our real-time task.

With a task running with predictable timing, real-time memory for data transfer was needed. The user-level task needed to access collected data and to control the real-time task. Real-time FIFOs are queues that can be read from and written to by Linux processes. The real-time FIFO devices are built during the RTLinux installation and created in the initialization of the real-time modules. Now a handler can be created and tied to one of the FIFO Devices. The handler can be set up to execute when 1 is written to the handler FIFO from the user interface program as controlling of the module is needed.

The module was created in order to be installed into the kernel as a real-time task. The tricky part of the real-time module was setting up the framework. Our real-time task code was straightforward, but lengthy. So, we've included only the real-time module skeleton (Listing 1). Notice the simplicity of the code that is implemented with real-time requirements.