Q1: windows installer may fail to setup environment variables. A1: Reinstall the packages again usually solve the problem. The environment variables is defined to help compiler to find the DLL, header files. The vate itself did not depends environment variables. If you don't rely on environment variables to setup your development environment, you can ignore this issue completely. Q2: vate_ext_return() and vate_tp_return() can't return string with space such as "HELLO WORLD". The vate_get_result() will get wrong number of arguments error. A2: This is consider as a features. The vate is for IC testing, so normally, only number will be return back to caller. However, this limitation will be removed in the future, but it's marked as a low priority task. Q3: Durning "loop" command, another "start" from other client will break "loop" ! I heart that the "loop" command is just a list of "start" commands, why it will be break by other "start" command ? Is this a bug ? A3: No, this is not a bug. It's a feature. Yes, "loop" command is just a list of "start" commands. But it will not break by just another "start" command. The reason "loop" stop is because there is another "asynchronous" start command comes from other client. The TP FSM make sure there are one and only one TP command will be executed at one time. When TP FSM testing DUT, another "start" command will got BUSY and FAIL. And if this command is one of the loop list member, the "loop" will break. This limitation is easy to fix by just ask "start" to wait until another "start" finish. But it's a low priority task, IMHO. Check the GUI, when "loop" command start, "init" and "start" will be disabled ... so far I think AP policy should be used to fix the issue, instead of change hehavior to let "start" wait. Q4: When vate GUI exit, it will cause segementation fault !! A4: The vate GUI is not officially release yet. This is a known bug of GUI, and we are working on that. This bug only happen at Exit ... the reason seg. fault happen is because we did not waiting for some threads to exit before main thread exit. This bug did not affect any normal usage of vate GUI, as far as we know, ... so you can safely ignore this issue. It will be fixed soon.