**3.5 The block diagram: event structure/producer and consumer loops**

After initialization, the software goes in timeout mode and waits for user commands. The entire architecture of the software is therefore enclosed in a large event structure, shown in **Figure 9**, where every single button on screen is triggering a specific event. This choice of the basic architecture was perhaps not the wisest one, and it will be changed in the future (see the final section about future perspectives). In order to ensure that unjustified clicking on certain buttons by the user can harm the software execution, each event will disable all buttons which are not relevant during the performance of that event, and those buttons will be grayed, so that the user has an exact feeling of what can and cannot be done in that precise moment. The user can always stop the current task with a specific stop button, which drives

**Figure 9.** *The TeraVision block diagram.*

the already mentioned "smart-stop" VI instead of being directly linked to any loop, so to ensure that the system has returned to timeout mode correctly.

The TeraVision software has been written with particular effort on saving time during each measurement. If a simple time-scan on a short range and few points can take seconds or few minutes, a full resolution 2D scan of a real THYR measurement can take several hours. This time is really at the limit of long-term laser stability specifications. For this reason, every millisecond spared during the single point acquisition, or in between two subsequent scans, is important. Several actions have been taken in order to reduce the measurement time as much as possible, and we will list them in this section.

First, the time required for the actual measurement (devices movements and number of triggers for each point) is decoupled from all analysis and digital work (in particular data and parameters file writing, which is the most digital timeconsuming task). The way we chose for this, is to implement several Producer/ Consumer loops (an example is shown in **Figure 10**). The Producer/Consumer architecture is a classic case of multithreaded synchronization solution. It applies when two threads (producer and consumer) actually run together in parallel. The main role of the producer is to generate a certain amount of data to put into the buffers and then repeat the process with one or more nested for/while loops. It is crucial to implement "smart stops" in order to prevent crashes due to nested loops. At the same time, consumers are consuming the data in buffers for data analysis and saving. The key is to ensure that producers do not add data when the buffer is full, and consumers do not consume data when the buffer is empty. **Figure 10** shows as an example the Producer/Consumer architecture for the Acquisition task. Many users know that LabVIEW can be programmed by multithreading, but usual ways to implement multithreading are to use global and local variables, with the disadvantages of possible data loss, risk and competition. The loops are driven by queue controls in order to ensure a correct processing of data flow.

The data processing is, however, not the most time-expensive problem. The most time-consuming tasks are by far the physical movements of all devices. In order to minimize those movements, we implemented the following procedure.

**59**

ment begin.

**Figure 10.**

*Producer-consumer loop.*

*TeraVision: A LabVIEW Software for THz Hyper-Raman Spectroscopy*

The usual way to drive a step motor is to give it a target position, then read out the actually reached position and finally adjust it with a secondary movement command, with or without a third step due to so-called backlash correction. We chose to avoid all position corrections. For the measurement is not important that the target position is "really" that given in command, as long as the actual position reached after a single movement is read with sufficient precision and accuracy. Therefore, the system creates an array of positions, from the start/stop/step parameters, equally spaced, and gives them to the motor driver VI for each trigger of the acquisition loop. Instead of waiting that the device goes precisely on each position of the array, the software collects data on random positions acquired "closed to" the target positions. After one scan is completed, the software interpolates the signal values acquired on random positions on top of the original equally spaced array. In this way we realize two important things: first, the signal can be averaged easily with all previous scans as the x-axis values are identical, and second the FFT routine will work correctly, as it requires to run over equally spaced arrays only. For the same reason of minimizing the device movements, the software is also capable of performing the scans in "reverse" mode, i.e. it scans from start to stop and then from stop to start, in order to remove the dead time needed to send the motor back to the start position. Finally, the system can decide automatically how to start the first scan by reading the actual position and compare it with the position array so to choose which direction of motion will give the shortest time before the measure-

*DOI: http://dx.doi.org/10.5772/intechopen.96663*

*TeraVision: A LabVIEW Software for THz Hyper-Raman Spectroscopy DOI: http://dx.doi.org/10.5772/intechopen.96663*

**Figure 10.** *Producer-consumer loop.*

*LabVIEW - A Flexible Environment for Modeling and Daily Laboratory Use*

the already mentioned "smart-stop" VI instead of being directly linked to any loop,

The TeraVision software has been written with particular effort on saving time during each measurement. If a simple time-scan on a short range and few points can take seconds or few minutes, a full resolution 2D scan of a real THYR measurement can take several hours. This time is really at the limit of long-term laser stability specifications. For this reason, every millisecond spared during the single point acquisition, or in between two subsequent scans, is important. Several actions have been taken in order to reduce the measurement time as much as possible, and we

First, the time required for the actual measurement (devices movements and number of triggers for each point) is decoupled from all analysis and digital work (in particular data and parameters file writing, which is the most digital timeconsuming task). The way we chose for this, is to implement several Producer/ Consumer loops (an example is shown in **Figure 10**). The Producer/Consumer architecture is a classic case of multithreaded synchronization solution. It applies when two threads (producer and consumer) actually run together in parallel. The main role of the producer is to generate a certain amount of data to put into the buffers and then repeat the process with one or more nested for/while loops. It is crucial to implement "smart stops" in order to prevent crashes due to nested loops. At the same time, consumers are consuming the data in buffers for data analysis and saving. The key is to ensure that producers do not add data when the buffer is full, and consumers do not consume data when the buffer is empty. **Figure 10** shows as an example the Producer/Consumer architecture for the Acquisition task. Many users know that LabVIEW can be programmed by multithreading, but usual ways to implement multithreading are to use global and local variables, with the disadvantages of possible data loss, risk and competition. The loops are driven by queue controls in order to ensure a correct processing of

The data processing is, however, not the most time-expensive problem. The most time-consuming tasks are by far the physical movements of all devices. In order to minimize those movements, we implemented the following procedure.

so to ensure that the system has returned to timeout mode correctly.

will list them in this section.

**Figure 9.**

*The TeraVision block diagram.*

**58**

data flow.

The usual way to drive a step motor is to give it a target position, then read out the actually reached position and finally adjust it with a secondary movement command, with or without a third step due to so-called backlash correction. We chose to avoid all position corrections. For the measurement is not important that the target position is "really" that given in command, as long as the actual position reached after a single movement is read with sufficient precision and accuracy. Therefore, the system creates an array of positions, from the start/stop/step parameters, equally spaced, and gives them to the motor driver VI for each trigger of the acquisition loop. Instead of waiting that the device goes precisely on each position of the array, the software collects data on random positions acquired "closed to" the target positions. After one scan is completed, the software interpolates the signal values acquired on random positions on top of the original equally spaced array. In this way we realize two important things: first, the signal can be averaged easily with all previous scans as the x-axis values are identical, and second the FFT routine will work correctly, as it requires to run over equally spaced arrays only. For the same reason of minimizing the device movements, the software is also capable of performing the scans in "reverse" mode, i.e. it scans from start to stop and then from stop to start, in order to remove the dead time needed to send the motor back to the start position. Finally, the system can decide automatically how to start the first scan by reading the actual position and compare it with the position array so to choose which direction of motion will give the shortest time before the measurement begin.
