Hello! I am reading from an Ocean Optics spectrometer using their OMNIdriver which is written in .net. When I call the read function it waits for the data to be ready before returning the results to labview. The spectrometer is triggered by a hardware signal coming from other istruments (200Hz square wave for the curious). My problem is if the read section of my VI is started without the hardware trigger present then the OMNIdriver read function (getSpectrum) waits forever and never returns a result for the while loop to continue. I cannot use a stop button to exit the loop since the loop is stuck waiting, and when I use the abort button under project to stop labview, it hangs up. All my other while loops stop, but this one never finishes. The only way for me to recover is to use task manager to kill labview and then restart it. Has anyone ran into something like this before?
One idea I had was a timeout function to abort the read if too much time happens. However I don't know how to do this with the .net call since my loop stops iterating while waiting for the .net portion to finish.
Windows 7 64 bit
Labview 2014 64 bit
Solved! Go to Solution.
It's a little complicated, but it seems to work.
Thank you for the suggestion! I will give that a try. I also realized I can check for the start signal befor I initiate a .net read, which might solve the issue as well.
Sorry for the late reply. It didn’t seem to fix my problem. I had to add a timeout to the asynchronous call and I got it to finish the VI successfully, however it then tries to reset the DotNetCall.vi and gets stuck there. I think what I need is a way to abort a .net call.
For now I’m the only one who uses this program and have a note to turn the trigger signal on before running. I would like to find a better solution if possible.
You could try to use the "setTimeout" Method
int setTimeout(int spectrometerIndex, int timeoutMilliseconds)
If you have a USB spectrometer
That worked! Thank you.
It's still interesting to think about how labview passes full control over to the .net call, and if it would be appropriate to have an abort .net call function. For me though this fixes my problem entirly 🙂