The addition of event-generating code is a relatively simple process due to the creation of easily used
software modules written in Perl, C, and LabVIEW. The system also gives developers a mechanism to
keep themselves informed of specific incidents that might require their attention simply by adding the
MAILTO:
tag to any event. These facts, along with the obvious advantages of a uniform reporting
process, lead to rapid acceptance and inclusion of event generators by wind tunnel systems developers.
The ease with which developers, operators and clients can manually generate events to be included in the log encourages the timely reporting of any irregularities observed during testing. This is of great value in carrying out the task of finding and eliminating intermittent problems caused by inconsistencies in software, hardware or operating procedures.
Users require little or no training in order to utilize the system effectively due to the existence of an intuitive web interface. Events of interest are easily extracted from the large log files by specifying time, source, severity, and pattern matching constraints. The use of colour and icons in the output web page allows users to quickly locate specific information. Finding the rate of occurrence of a given type of event becomes trivial due to the counting mechanism built in to the viewer. The ability to easily download the results of a specific event search to the user�s computer greatly enhances the usefulness of the system for report generation.
Since multiple systems are sending asynchronously generated messages to a central location, a time stamp is added at the moment of reception, rather than relying on the accuracy of each local clock. Because of this, an extremely accurate and precise record of the sequence of events occurring during a wind tunnel test is easily compiled. Program interaction difficulties, timing problems, and inefficiencies in program design become apparent with little effort. Even as simple a thing as a permanent record of what has occurred can be of great value to users and developers alike.
Although somewhat atypical, the output page shown in Fig. 6 is an accurate
account of one hour of an
actual wind tunnel test and serves as a good example of the usefulness of the event logging system. From
16:01:05 to 16:01:26 the QNX system reported that the model was moved and data was taken twice. At
16:01:31 the operator pressed the
END RUN button and eight seconds later the UNIX system named
jabba noted that it received a request for end-of-run plotting. Approximately nine minutes later the
LabVIEW based motion control system, m2-aerotech, generated an error reporting that a limit switch had
been activated. (Since this was not preceded by a motion request, the axis move operation must have been
under manual control.) Between 16:32:49 and 16:53:19 a manual plot was produced, and a configuration
file, Run696.cfg, was modified twice. At 16:56:26 the LabVIEW system m2-wtdas-inf warned of a yaw
angle of 1599.88 degrees. As that system was under development, the event was indicative of a bug in the
YawPitchToAeroTek.vi subroutine. Testing resumed at 16:58:27 with a tare measurement and seven
seconds later, a motion request. The pitch-axis position exceeded a software limit at 16:58:45. Another
tare measurement was begun at 16:58:49 followed by a motion request seven seconds later. In total six
programs running on four computers generated events over the course of one hour.