Ocean Optics Spectrometers under LabView - Ocean Optics OmniDriver

[OceanOptics.OliverL]

Hi all,

I am trying to summarize most of the Tech Support questions in this thread that i have seen in the past months.

First things first:

The OmniDriver is made for coherent bit Versions of operating system, Labview and OmniDriver. This is regardless of the OS and valid for Windows and Linux OSes.Prior to getting LabView talk to any piece of external equipment, please ensure that you can talk to the equipment under the tools provided by the manufacturer. This is important not only for OceanOptics instruments, but in general. For OmniDriver, the verfication of the installation process can be verified by running the SpectrumTest32.exe or SpectrumTest64.exe (for Windows, please mind the OS bit version) from the OOI_HOME subfolder of the Omnidriver installation folder with a spectrometer connected. Please ensure here that the instrument is properly identified and no driver issues are occuring on OS level, prior to running the spectrum test calls. This should open up a window where a short program is executed that connects to the instrument and returns a table of data on your screen. If this is working then turn to LabView.

I have seen that many users use 32-bit versions of LabView on 64-bit operating systems. This creates issues with using native 64-bit architectures like OmniDriver 64-bit. The common error message here is a .NET error code 1074 in the .NET interface of the wrapper call under LabView. There are two options to solve this issue. The first would be to contact NI for a 64-bit version of you LabView suite which depending on the age of your license and license model may create costs or not give you a solution. If you really want to use a 32-bit version of LabView with the OmniDriver on a 64-bit platform you need to install the 32-bit version of the OmniDriver in a 32-bit simulated environment. Under Windows this is quite easy as you can select to run programs in compatibility mode of for instance WinXP SP3 32-bit. This correctly registers the 32-bit/64-bit interface layer of the operating system to not create buffer over-/underflow in the driver call.

The next thing is getting the .NET interface in LabView up and running. There was a change in the syntax of the .NET interface going from the .NET framework 3.5 (using .NET 2 syntax) to the .NET4 framework (using .NET4 syntax). This change rendered a lot of .NET functions unusable. . Depending on how current the .NET framework on you machine is this may cause an error in the .NET interface when trying to create .NET constructor nodes under LabView. On many LabView versions .NET2 syntax is initialized by default and thus the .NET interface in LabView and the .NET framework on your machine speak dialects that the other does not understand. The typical .NET error code for this is 1072.

The solution in forcing LabView to initialize a .NET4 syntax interface. This rather simple and needs a .exe.config file to be placed in the same folder as your LabView.exe and is explained in the knowledge base article (http://digital.ni.com/public.nsf/allkb/32B0BA28A72AA87D8625782600737DE9).

The .NET errors are all summarized in the table found under this link: http://zone.ni.com/reference/en-XX/help/371361J-01/lverror/misc_lv_error_codes/

Another common error is the .NET error code 1172 which is related to the location of your dll and the assembly trust concept. When using third party drivers, please ensure that you trust the driver. More on this can be found in the following knowledge base article on sine: http://digital.ni.com/public.nsf/allkb/B15CE9F2715434C386256D3500601878

[GregSands]

Firstly, thanks for summarizing the issues and solutions for using OmniDriver in LabVIEW.

I want to add a couple more observations from my recent use, which which I hope will be helpful to others using OmniDriver (also to document it in case I forget before I use it again!).

1.  It was straight-forward to get the .NET version working with LabVIEW 2012 32-bit on Windows 7 64-bit using the procedure outlined here.  I was using HighSpeedAcquisition (1 kHz) on a HR-2000+.  However the program would randomly crash (closing LabVIEW), so I reverted to using the (older) DLL wrapper routines, which did not crash at all.  Note that I was under a lot of time pressure to get things working, so did not have a chance to fully explore the issues.

2.  Using the DLL routines, I was attempting to acquire from the spectrometer while simultaneously controlling other DAQ hardware.  Even when I separated the spectrometer control into a separate program, my main control program would pause while the spectrometer acquisition occurred.  It took a few days to track down that the reason was that the DLL calls in these wrapper VIs have been set up to run in the UI thread, rather than in any thread.  When I changed those over (just on the handful of routines I used) and set my spectrometer controller to run in a separate thread, then everything worked very well.  So if there's no reason to restrict to the UI thread (and there doesn't seem to be) then changing this should help if you have a similar problem.

In the end, everything worked very well, but just with these hiccups along the way.

[BillyG]

I want to contribute an additional solution that solved my OmniDriver - LabVIEW compatibility problems. I use 64-bit Window 7 with 32-bit LabVIEW 2013. I installed the 32-bit OmniDriver v.2.20, as recommended by the OP, but my LabVIEW script could not see any spectrometers: Wrapper_OpenAllSpectrometers returned spectrometer count of zero.

The solution recommended by OceanOptics tech support is to navigate to the C:\Program Files (x86)\Ocean Optics\OmniDriver\OOI_HOME folder and look at the size of NatUSB.dll file relative to other NatUSB_*.dll files in the same folder. It should be of the same size as NatUSB_32_winusb.dll . If not, the driver is using a wrong version of NatISB.dll . Delete OOI_HOME/NatUSB.dll and copy OOI_HOME/NatUSB_32_winusb.dll -> OOI_HOME/NatUSB.dll . If you ever reinstall the driver, this will have to be repeated.

I was told that this should not be an issue with the current OmniDriver version (2.4) .

[lennyS]

Hi, All

Im a graduate student and i just inherited Labview VI to acquire data from an oceanoptics HR4000CG-UV-NIR spectrometer. When i run the vi i get a 3005 error at the IcoWrapper, vi potion below. This VI has no problem on an XP computer, but since im trying to upgrade to Win7 64bit i have to fix the issue and i would like to ask for help.

Labview version: 13.0 32bit

Win7 64bit

OmniDriver+Spam 32bit

Thank you for your time

LennyS

[OceanOptics.OliverL]

Hi Lenny,

no problem. This is a generic issue when trying to execute 32-bit software with hardware access on 64-bit OS Windows environments. The issue is a buffer underflow in the driver kernel as Windows expects a 64-bit answer. It does not realize that the driver will only answer in 32/bit accuracy. there are 2 options to work around this. The simplest one would be to uninstall OmniDriver and then reinstall it under the 32--bit compatibility mode, so that windows is told that this is 32-bit. This is quite easy to do. Please right click on the installer exe file and go to Properties. Then select the Connectivity tab and use the "WinXP SP3 compatibility" option which is by default 32-bit.

Then the Omnidriver package will install, you can verify the correct driver registration via the spectrumtest32.exe from the OOI_HOME subdirectory of the Omni+SPAM installation folder. Please run that test with a spectrometer connected to the PC. Please also mind, that the first time you connect the spectrometer Windows Update will look for the drivers. You can either wait a couple of minutes for WinUpdate to complete checking the database or cancel that part and tell Windows to look for the driver in the Omni+SPAM installation folder + subdirectories.

Please let me know if this solves your problem.

Best Regards, Oliver

[lennyS]

Hi Oliver,

Thank you for taking the time to reply to my post.

I managed to follow all your steps and got the spectrometer to work with spectrasuite and other software. After running my VI however, i got an "Error 91 occured at variant to data in spectrometer interface.vi". Is there a way to correct this error without rewriting the VI?

Again, Thank you for your time.

Lenny

[OceanOptics.OliverL]

Hi Lenny,

thanks for the post and i am glad that you got all things working. the variant to data call is a tricky thing. If possible try to work with fixed variable types. this usually prevents getting in trouble with the variant class.

I have done a quick search and there is quite a large number of fixes on the variant to data call also here on Sine. They seem to be linked to different variable types in the source and the sink of the call.

Best Regards, Oliver