9 Real-Time Issues
Newcomers to DAQ are very seldom aware of real-time issues until they build a system that doesn’t work because of these issues. Luckily, the issues are rather easy to explain and understand, as will be done in this chapter. We will discuss real-time issues in operating systems, then we will discuss hardware and software techniques to handle these issues.
There are many definitions for the term real-time, so I will define it for this chapter: a real-time system is one in which certain tasks can be guaranteed be complete within a specified time span. This is sometimes called deterministic.
9.1 TIMING IN OPERATING SYSTEMS
All major operating systems are not real-time. Windows is very non-realtime. In simple terms, this means that any task you perform could take an arbitrary amount of time. For example, there is no guarantee that any Microsoft Word document can be opened in less than five seconds. In fact, there’s technically no guarantee that your tasks will ever finish, as your entire system (particularly with Windows) could crash or hang at any time! Why are operating systems not real-time? There’s a good reason. They must be flexible enough to accommodate any number of programs, as processor speed, memory, and overall computer power increase every year. Unlimited flexibility and real-time ability are opposing forces in operating system design, so very few operating systems are real-time.
The computer’s processor (there may be more than one, but we’ll use the singular term in this chapter) must switch between tasks, as it usually has several tasks virtually occurring at once. Disk activities typically take a higher priority than any other activities, so if you write a large file to a floppy disk (or read such a file from it), everything else that is processor-dependent will come to a halt. This includes DAQ, and that is exactly why we have DMA and FIFO, as discussed in Chapter 2: DMA and FIFO are not processor dependent. They allow a smooth, continuous stream of data points into or out of the computer, even when the processor is totally ignoring all DAQ hardware and software. You can get a good idea of what kind of delays to expect from your operating system by building the VI shown in Figure 9-1.
That’s a String Indicator on the front panel with the scrollbar shown. The block diagram measures the time between consecutive iterations of the White Loop, and stores the maximum delay in a shift register. Every time a delay comes along that is longer than the previous maximum, the length of that delay is reported on the front panel, along with the time the delay occurred. The 5.00 second delay shown in the figure was intentionally caused by starting Windows’ ScanDisk, a disk-scanning utility.
Suppose you are designing a control system for a fighter plane’s wing movement during flight. First of all, you would not be using LabVIEW for this, but let’s just pretend that you are. Suppose the inputs to your control algorithm come from the pilot’s manual input and from the plane’s instrumentation. Suppose the algorithm’s output controls the wing’s position. Let’s also suppose that if the wing’s position is not adjusted four times per second, your fighter plane will crash. Unfortunately, your plane is going to crash unless you have LabVIEW RT (to be discussed soon), because no amount of DMA or FIFO can help in this situation! Unlike data streaming into a computer, control loops involving feedback are less immune to a processor’s absence, because control loops require actual processor interaction in order for the loop to operate properly. What is a control loop? It involves input and output, where the output must respond to the input within a certain time. Since a processor is required for such a response, a real-time operating system may be required, as is described in the next section. In general, if your control loop cannot withstand a processor delay of more than about 10 seconds, it will not be reliable. If this seems insanely long (it is), read the next paragraph.
My experience shows me there are two common situations in which lengthy operating system delays might occur: disk access and network access. Once, white running ScanDisk (a system tool that scans all disk drives for surface errors and various file I/O errors), I noticed a 14-second delay! This is a record for me, though, and I admit I was intentionally trying to see how big a delay I could create. Depending on what software and/or hardware drivers you have on your computer, you will see maximum delays that vary widely. If you have a delay-sensitive DAQ application, beware of disk and network activities. If you must read or write to disk, flush often (see Chapter 6, Section 6.4.3), as this will minimize your maximum disk-related delay.
Figure 9-1
Observing your operating system’s delays.
9.2 HARDWARE TECHNIQUES FOR REAL-TIME DAQ
Remember that DMA is not processor-dependent, so if your DAQ involves DMA, it will be unaffected during the processor’s vacation. DMA and FIFO are fully described in Chapter 2, but to reiterate the key points, they can keep DAQ data streaming into or out of your computer when the computer’s processor is ignoring DAQ. They do not provide truly real-time capability, however, as they can only handle processor absences of a finite length of time—all they really do is keep data streaming constantly in one direction or the other.
Probably the most reliable way to perform real-time DAQ using LabVIEW is with LabVIEW RT, where RT stands for real-time, as you might have guessed. NI has special DAQ devices (RT Series DAQ boards) that are required with LabVIEW RT. Currently, these devices are DAQ boards that live inside the computer and have their own processors; they are, effectively, embedded controllers. LabVIEW RT compiles real-time code specifically for these DAQ boards’ processors, so that deterministic real-time performance is achieved; you can even warm boot your main computer, and LabVIEW RT will theoretically run unaffected.
9.3 SOFTWARE TECHNIQUES FOR REAL-TIME DAQ
There is no such thing as true real-time performance using software timing alone in any non-real-time operating system (such as Windows or any other major operating system). However, there are a number of software techniques that greatly reduce the delay time encountered in real-time operating systems.
The best way to reduce the timing of your DAQ functions, other than NI’s RT products, would be to write a device driver. A device driver can provide timing with much smaller delays, but it is still not truly real-time. Currently, the easiest way to develop a device driver for Windows is by using utilities from BlueWater Systems, www.bluewatersystems.com. These utilities exist for all of the popular versions of Windows. If you have months of time to kill, you could try writing a device driver for Windows without such utilities. No matter how you choose to write a device driver, its linkage to LabVIEW will be difficult at best. But remember, device drivers are not truly real-time, as they cannot guarantee a maximum delay in your program, but they can greatly minimize this maximum delay.
A completely different approach would be to use a real-time operating system. As of this book’s writing, LabVIEW does not run under any such operating system, other than LabVIEW RT, which requires special hardware.
If you’re good with microcontrollers, they can easily be programmed for real-time control. You could pass the data to LabVIEW via RS-232, but you need to be good with microcontrollers to even think about this.
DOS is very close to a real-time operating system, in my opinion. LabVIEW doesn’t run under DOS, and NI doesn’t support any DOS issues, but some of their older hardware and non-LabVIEW software products work very well under DOS. LabWindows for DOS, the predecessor of today’s LabWindows/CVI product, is a wonderful, albeit simple, C-based development environment—if you want to use it, it helps if you know the C programming language. NI does not advertise LabWindows for DOS, it does not run on computers with more than 32 Mbytes RAM, and it is increasingly unsupported. With the need for real-time systems, it is beyond me why DOS seems to be disappearing to such an extent.