Buffer Overflow demonstration demo script.
Important - Test and calibrate VI before demo. The sample rate and samples per read should be set so that the samples in the buffer stays low normally, and increases steadily when moving a window about the screen. If you plan to show the solution you will also need to calibrate the solution VI and adjust the period of the consumer loop.
Open the Buffer Overflow VI.
Show and explain the block diagram of the VI.
This VI acquires Data continuously at a high rate. It also performs analysis on the data as it is acquired and displays the results. In this case, the analysis and display are fairly processor intensive, as they involves applying complex algorithms (FFTs) multiple times and graphing data multiple times per second.
Run the VI. Point out the buffer size.
Initially, the VI is reading samples from the buffer as fast as they are being generated, keeping the buffer size low.
Open a Windows Explorer window.
Grab the title bar of the window, and move the window around the screen, keeping the buffer size indicator visible. Explain the change in the buffer size.
With another process (the display updates for windows explorer) monopolizing the processor, the loop in the VI runs less frequently, and the samples in the on-board buffer accumulate while waiting to be read.
Continue to move the window until the VI throws a buffer overflow error. Explain the error.
The buffer between the DAQ board and the application has a fixed size. Each time a sample is read by the application, it is removed from the buffer, but if the application doesn't read samples quickly enough, the buffer fills up, and eventually must discard data that has not been read. This generates an error.
Discuss methods to reduce the problem.
Although you cannot completely solve the problem, there are a couple of ways in which you can increase the VI's tolerance to a period in which the processor is monopolized by other tasks. In order to make the most of the time in which the VI has the processor, you must decrease the execution time of your acquisition loop as much as possible. One way to do this would be to move the acquisition and display after the acquisition is complete. This works for short term acquisitions; however, if you want a continuously updating display or if the data is being acquired for too long to easily store it in memory then you must perform the analysis as acquisition occurs (as is the case with the course project).
In order to perform the analysis continuously and still offer some level of tolerance for busy-processor situations, you can use a producer/consumer design pattern to put the analysis in a separate, lower priority loop (you can manage loop priority most effectively by using timed loops, but you can get a similar effect by introducing a wait). When you do this, the queue becomes an additional buffer for your program, thereby increasing your tolerance to busy-processor situations.
Optional: Show a producer consumer solution
Before showing this VI, you'll need to calibrate it for your instructor computer so that when moving the windows explorer window, the DAQ buffer does not overflow, but the queue size increases steadily. Finding the right values can take some time so be sure to prepare early if you plan to show this portion of the demo. Once you calibrate the sample rate and samples per read in the DAQ assistant, you'll also need to set the wait time of the consumer loop. The wait time should be something close to the result of this equation: wait time(ms) = 900/(sample rate/samples per read)
Open the Buffer Overflow Solution VI.
Open and explain the block diagram.
The VI has the same data acquisition and analysis settings as the original VI, but the analysis has been moved to a consumer loop. The consumer loop has a wait, which effectively causes it to be a lower priority for the processor than the producer loop. Therefore, when the processor is busy, the producer loop will run more often than the consumer loop. The wait has been set to a value slightly lower than the ideal frequency of the producer loop, so that during periods when the processor is not heavily used, the consumer loop can empty the queue and catch up to the producer loop.
Run the VI.
Move the Windows Explorer window around. If the VI has been calibrated correctly, the size of the DAQ buffer should increase some, but should stabilize before reaching an error and the size of the queue should increase steadily.
Stop moving the window. The size of the queue should slowly decrease now that the processor is idle.