Test the MTDome on summit to understand the current software status and the running condition in the real-time target. Wouter and I will live on the summit's hotel at 1/30 night.

I would like to check the followings if possible:

1. The real-time application deployed in the target is in the debugging mode or not. The debugging mode will consume a significant resource (CPU + memory). In addition, some application may not be able to run without the debugging mode for the implementation of LabVIEW code (this is the tricky part in LabVIEW, some function is better not to be used for the real-time target).

2. When the system is running, is there any possible memory leakage? We could check this by just logging into the target from terminal. However, it will be easier to check by using the LabVIEW resource monitor with the debugging mode to see the memory usage in the real-time.

3. The frequency of telemetry. I noticed that the dome control system is using the scanning mode to get the data from instruments. I do not know EIE tried the benchmark of telemetry rate before or not. I thought it might be better to use the FPGA mode instead of scanning mode for the production. The scanning mode is used for the fast-development usually I believe. Of course, the use of FPGA mode will increase the code complexity as a trade-off.

4. I noticed that there are multiple timed loops in the application. I am wondering EIE tried to let the control system running for several days continuously or not without the rebooting or redeploying the project. Usually, if there is only two CPUs in the target, only use one timed loop is safest (number of CPUs minus one). This is because the settings of timed loop allow the hard real-time and it might get the dead lock in the application. If this happens, you will see the CPU usage >= 50%, and the NI OS kernel in target will kick out any connection such as TCP/IP and stop the response.