The Implementation for Motors and Camera

The motors and camera are standalone devices and they have own properties, fulfil own functions independently without any reliance from other hardware components. There-fore, the motor and camera were implemented with the concept of OOP. Both devices have standard functioning LabVIEW drivers provided by manufacturers. The drivers are very modular and compatible with LabVIEW 2014 as well. By using VISA, the connection between devices and PC can be easily established.

In the project, there are three linear motors and one rotational motor controlled by the computer via VISA. By iterating the VISA address array, each motor can be easily pointed.

Due to this property, we abstract all four motors into a common, generic class named Motor which provides the movements along with different directions.

Motor functions are used at the alignment and imaging phases. For the sample align-ment, all the motors need to be appropriately used to align and move the sample per-fectly. However, during the data acquisition phase, only the rotation motor is working and in order to avoid additional movement because of the acceleration and deceleration, the rotation motor finishes each angular rotation every one second. For alignment, the rota-tion motor calculates the destinarota-tion and moves in a default speed which is 1500 steps per second. However, in the data acquisition process, the motor moves in a different way.

For all modes, each rotational movement takes always one second regardless of data acquisition angle because the speed changes linearly depending on the rotational angle.

In case of the rotation speed is too fast to damage the sample, the maximal speed is 500 steps per second and it is not changeable for users. This could guarantee that during the rotation, the computer does not need to do polling to check if the motor has stopped which saves much CPU power.

In order to integrate the motor into the system and achieve the functions, the public VIs of Motor Class need to be reused to build a related task inside a state machine. The combination of OOP and state machine make sure that the specific method of each object is detached with the workflow design. Even if you redesign the workflow shown in figure 3.3, the motor methods are not affected at all. As figure 3.14 displays, there is a data queue created for the motor to receive messages from other parts of the system. Inside the state machine, there are cases which can perform the motor functionalities such as rotational, up-down movements. Additionally, the motors are not data generators, hence, there is no need to have a producer-consumer pattern.

For the camera, all the methods it has needs to be defined in the Camera class first. Then those VIs are integrated and implemented in a state machine according to the workflow

Figure 3.14. The motor handler receives the task from its own queue and dequeue functions to get the message and data. Then according to the message information, it executes the task in its state machine by calling motor functions.

of a camera. When the camera is working, it captures frames every per second and these images need to be either saved or represented to the user, thus, a producer-consumer architecture has to be chosen (figure 3.15).

Figure 3.15. The producer-consumer loop is applied for the camera. The camera ac-quires high-resolution image which are around 8 MB each. Because the displaying and saving images take a few seconds, the camera data must be processed asynchronously in the consumer loop in order to reduce the data acquisition time.

In the producer loop, the camera methods are called to complete certain duties. In order to properly use the camera without damaging itself, the camera has to follow a fixed sequence of the workflow. It begins with checking if the camera is on and connected to the PC. Then, it has to be configured with correct parameters and proper capturing mode.

The camera driver for capturing images provides two different modes: sequence mode and snap mode. Sequence mode means the camera is able to take at least 3 frames per second and snap denotes it take one frame every second. In the sample alignment phase, in order to visualize the real-time position of the sample inside the chamber, the

sequence mode is configured for the camera. However, in OPT or OPT/EIT mode, the camera is set with snap mode to avoid duplicate images. After it, the camera starts to prepare itself for imaging. When the camera is ready, it waits for the frames and takes it. Before the camera quits, it has to stop the capture and unprepare itself. Importantly, if the camera is going to be configured again, it has to exit the capture mode, unprepared and reset its configuration data, otherwise, the camera will throw an error and LabVIEW software crashes.

Consider that each image is about 8 MB and LabVIEW is based on data flow principle, if the data gets larger, the time costs for data transmission gets longer and the queue memory space is not enough either. Therefore, instead of pass the image itself, the reference of the image in the memory is transferred by using data value reference. In the consumer loop, it dereferences the reference and finds the image. Compared to the size of an image, the size of reference is only 16 bytes, hence, the data transmitting rate is dramatically improved and very less memory in RAM is consumed to store the images temporarily.