Application Area: Field Testing Challenge: Develop a fully functional automatic detection system for short-wave irregularities on the rail top surface using LabVIEW, filling a gap in this technological field in China. Application Solution: Develop a fully functional and advanced detection system using NI's multi-function data acquisition card and the LabVIEW platform. Products Used: LabVIEW; Introduction to data acquisition cards such as PCI-6035E, 6711E, and PCI-MIO-16E-4 Short-wave irregularities on the rail top surface are one of the main causes of noise generation and changes in the interaction force between train wheels and rails. With the continuous development of railway transportation towards high speed and heavy load, the degree of short-wave irregularities on the rail top surface is becoming increasingly serious. This not only exacerbates damage to track structural components and exceeds geometric limits, but also affects the service life of rails and even endangers traffic safety. Currently, the existing methods for detecting short-wave irregularities on the rail top surface in China are only static point-by-point manual measurements, which are time-consuming, labor-intensive, and inefficient. The development and research of a new rail top surface short-wave irregularity detection system can provide a scientific basis for the formulation of rail grinding plans, thereby guiding the grinding of rails to extend their service life, improve passenger comfort, and ensure train safety. Its economic and social benefits are considerable. This article introduces the development of a rail top surface short-wave irregularity detection system (hereinafter referred to as the "detection system") based on LabVIEW and discusses some issues encountered during the development process. Functions and Features of the Detection System The detection system consists of two parts: an online detection subsystem and a post-event playback subsystem. The front panels of the two subsystems developed using LabVIEW are shown in Figure 1 and Figure 2, respectively. [align=center] Figure 1 Front panel of the online detection subsystem Figure 2 Front panel of the post-event playback subsystem[/align] The online detection subsystem triggers sampling through external pulses and simultaneously measures the time interval of the external pulses, calculating the corresponding train speed from the time interval. While continuously acquiring data, the system also performs necessary analysis and processing on the acquired data, stores it in a specific format, and dynamically displays the waveforms of the original data and processing results. The processed data and the signal driving the paper feeder are transmitted to the paper feeder via the output card, allowing most of the required test results to be obtained on-site. The post-test playback subsystem indexes and retrieves the original data files obtained from on-site testing, achieving processing functions similar to the online testing subsystem, and replaying information from the online testing process. Furthermore, this subsystem can evaluate the test results and display and print them in report form, greatly facilitating the understanding of the specific unevenness of the rail surface on each section by testing personnel. The most significant advanced technical feature of this system is its integration; data acquisition, analysis, processing, storage, display, output, and plotting are all completed within a single system, overcoming the weaknesses of older testing systems such as asynchronous data acquisition and analysis, and essentially achieving real-time online testing. Developing this system using NI's LabVIEW not only allows for easy implementation of complex data processing functions but also enables a visually appealing, user-friendly, and personalized user interface. Its modular design greatly facilitates program modification and maintenance. Implementation of the Detection System As a graphical programming language, NI's LabVIEW comes with a rich VI library, which is very easy to use. Furthermore, its abundant application example subroutines and comprehensive online help functions greatly facilitate programmers. 1. Coordination Between Multiple Tasks The challenge in designing this detection system lies in the fact that, since it is installed on a train, the online detection subsystem must maintain stable operation for extended periods while the train is in motion. Simultaneously, it must process, display, and drive the paper feeder to complete the drawing process while continuously acquiring data. To ensure no data loss during the entire online detection process, close coordination between data acquisition, processing, display, and output is crucial. If the processing or output modules consume too much time, the acquired data may not be read in an orderly and complete manner, leading to buffer overflow and loss of useful data. Based on these considerations, we fully utilize LabVIEW's multi-tasking mechanism in the program design, treating data acquisition, processing, and output as independent subtasks. We call the event (occurrence) function and wait on occurrence function in the function library to achieve reasonable coordination between multiple tasks. The flowchart of the main program of the online detection subsystem of our developed detection system is shown in Figure 3. [align=center] Figure 3 Flowchart of the main program of the online detection subsystem[/align] 2. Data transmission method and buffer Generally speaking, the data transmission methods used by the acquisition function unit include: timing, polling mode, interrupt mode, and direct memory access (DMA mode). The first three methods consume a lot of CPU time, and the transmission speed is not as fast as DMA. Since the data volume acquired by this detection system is large and the duration is long, it may take several or even more than ten hours, and the entire detection system consumes a lot of CPU resources, so we use DMA mode to transmit data in the program design. General data acquisition cards support this data transmission method, but different data acquisition cards support different numbers of DMA channels, some may only have one DMA channel. This system uses DMA for both data acquisition and measurement time intervals, so at least two DMA channels must be available. In order to ensure data processing while continuously acquiring data for a long time, and to leave a certain buffer time for data processing, a circular buffer must be opened to store the acquired data. This ensures timely data processing while data is being collected. When the buffer is full, it starts storing new data from the beginning, requiring a sufficiently fast data reading speed to avoid data loss. If the buffer hasn't reached the required reading amount, the program waits for it to arrive before reading. 3. Program Optimization To reduce system resource consumption and improve execution speed, we used sub-VIs as much as possible in the program design, fully utilizing LabVIEW's modular system building capabilities to achieve modular program design. LabVIEW provides rich data structures, including arrays, strings, clusters, and more complex data structures composed of them. However, considering algorithm execution efficiency and flowchart visualization, we minimized the use of complex data structures in the program design. Conclusion and Experience Currently, the development of the rail top surface short-wave irregularity detection system we undertook is basically complete, and multiple verification tests have been conducted on-site. We believe that with further improvements, this rail top surface short-wave irregularity detection system developed using LabVIEW will fill a gap in domestic automatic short-wave irregularity detection systems. While LabVIEW is relatively easy to learn initially, various programming problems still arise in practical applications. As a graphical, rapid programming language, many programmers have yet to fully utilize LabVIEW's numerous advantages. Based on the author's personal experience, LabVIEW provides a wealth of example subroutines, many of which can be directly used or slightly modified for use in their own programs. For example, many DAQ applications can be found in these example programs. Therefore, it is recommended to study LabVIEW's built-in example subroutines, as this will be of great help to programmers. LabVIEW's multitasking parallel operation mechanism is not found in traditional languages. This advantage should be fully utilized to conveniently and flexibly implement multitasking scheduling and quickly and efficiently construct relatively complex multitasking detection systems. LabVIEW's multitasking mechanism is cooperative rather than preemptive, and the system does not support interrupts, therefore it cannot achieve strict task timing, which limits its real-time performance. It is only suitable for situations where real-time requirements are not very high. If high real-time performance is required, other development systems that meet these requirements should be chosen, such as the real-time LabVIEW system (LabVIEW RT series). However, real-time performance is a relative concept. For situations where real-time requirements are not very high, the LabVIEW development platform can adequately meet the requirements through reasonable task scheduling, making it unnecessary to choose a more expensive real-time development system. From a program development perspective, if LabVIEW is chosen as the software development platform, it is recommended to use NI boards, as this simplifies and facilitates program design, thereby shortening the program development cycle.