This problem may be hardware OR software related.
The program before you works fine, sometimes. Seemingly randomly, it doesn't use the sub-vi protocols. It says it does, but when probed further, it doesn't.
Example 1: the 'MOTO GO' sub-vi. It responds with "no error" even when the commands are not carried out by the motor. Opening the sub-vi and running the exact same commands results in the motor carrying the commands out, no problem. Placing the moto go code into the main program results in everything working; even though I did not change the commands to/from the moto go system. 'Moto go' fails about 50% of the time.
Example 2: GPIB Sam sub-vi. Sometimes it's output is the appropriate channel's value, other times it oscillates between 0V and 4V or 5V. This clearly is the GPIB communication protocol with the high band and low band. So why, 80% of the time do I get 0-5V, while the other times I get maximum 8nV (corresponding to the experiment). Again, I open the sub-vi and everything works as it should, while in the main program we have this massive failure rate.
A few other sub-vis do the same thing, fail inside the program, work fine outside. My thoughts are that there is some sort of GPIB command overload perhaps? Would it be better to only give 1 command over gpib at a time? Only 2 devices are being run by the gpib; a motor and a lock-in amplifier. Or, possibly, is there a hardware issue at play? Thoughts?
Revision C is the main code
Moto Go is a sub-vi with one time commands for the motor, called in the 1st part of the program
Sam scan .llb is a library with the modified lock-in-amplifier commands. It is used throughout the program. The main issues it has are with query subroutines, that's where it outputs the 0V to 5V we see.
