Ocean Optics USB4000 Spectrometer

[Greg-H]

Hi,

Thanks for posting this.  To make sure that your thread gets the maximum amount of exposure I would start a new one here:

http://forums.ni.com/t5/LabVIEW/bd-p/170

This will make sure that other people who have used the driver as well as the developers at NI see it.

Regards,

Greg H.

[OceanOptics.OliverL]

Dear all,

please allow me to briefly introduce myself. My name is Oliver Lischtschenko and I am Sales Engineer at Ocean Optics. I joined Ocean Optics in November 2011, having worked as a researcher prior to this. I am using Ocean spectrometers and am first hour OmniDriver veteran (since 2006). I have also worked with the NI drivers for our systems, so I am able to compare both.

First, there are indeed two ways to talk to our spectrometers (or rather the CCD chip inside) under LV.In the case of the NI interface, the very basic CCD line is read out. Thus, the chip does not know of the masked area. This is something that is done in the firmware and is automatically taken care of with the OmniDriver. Under the NI VIs it might work to reverse the array cut it back to 3648 elements and then reverse it again. The USB4000 has 3648 exposed pixels.

Is there a particular reason why the OmniDriver is not used? The OmniDriver .NET interface is rather quick, allows for error handling and is to my opinion rather intuitive. It also has the advantage of working with any spectrometer from us.

To show the basic concept, I attached a snippet of a very basic DAQ VI to illustrate that it is really quickly put together.

[James_G1]

What if I am not using windows?

[OceanOptics.OliverL]

You could also directly talk to the JVM. The .NET interface is just one option. I know from past experience that the JVM interface in LV also had some issues. Maybe someone from NI can comment on that. I only found a tech doc on this.

http://digital.ni.com/public.nsf/allkb/BEE812007BA2A9B486256BC80068A49A

That would allow you to talk to the OmniDriver directly via the Java functions. The java docs are installed together with the OmniDriver.

[maxwellb]

I think the reason OmniDriver is not being used is that, correct me if I am wrong, it costs money. I think if you look at the original purpose of this thread, it was to find a way to talk to the USB4000 without paying extra for software.

[Jason_P]

Maxwell - cost is part of it, but stability of the Omnidriver itself was a key issue in moving away from Omindriver for many of us.  The old LV wrappers did not report errors.  From the earlier post, it looks like the .net wrappers will report errors.  But even beyond this, I think the Java implementation itself has problems - and a wrapper won't fix that.

Here's a fun test - start continuously collecting spectra with Omnidriver in a LabVIEW application, then unplug your spectrometer in the middle of it.  In my case, every time I ran the test the entire application disappeared with no error or warning.  You could argue that this is an unfair test.  But on the other hand, I'm trying to ship equipment that has to meet very stringent reliability requirements.  Having even a potential for a silent crash if somebody bumps a cable is an unacceptable risk.  

I'm a big fan of Ocean Optics spectrometers, but I doubt I'll ever use Omnidriver again. The NI-VISA drivers are far more crash-resistant.  I'd like to see the community work with NI to extend the functionality and fix what bugs exist in the NI drivers rather than continue trying to wrap Omnidriver.

JasonP

[OceanOptics.OliverL]

That is a point, I am willing to argue about.

Actually, the crash resistance was the reason I moved away from the NI drivers as a scientist. They had the nasty habit of having to take the entire NI-VISA session with them.

By the way, that issue has been fixed with the OmniDriver .NET interface some time ago and the lastest release even improved it if unplugging happens during data transfer.

[Jason_P]

Hi Oliver,

If it has been fixed, that's great.  But when I found the problems originally, there was no fix.  Instead, I wrote my own set of LVOOP/NI-VISA drivers to handle the USB2000, USB4000, USB2000+, and USB2000+HR spectrometers (NI hadn't yet written their own drivers).  My drivers - which are similar to the NI drivers - have been used in commericial systems that have been in nearly continuous operation for 3-4 years without reported issues.  I can unplug the spectrometer, capture the error, and even automatically resume if the spectrometer is plugged back in.  I can even detect when the spectrometer appears to be responding but has frozen due to a firmware bug (saw that on the USB4000 several years back - OO fixed the firmware issue).  I can't speak to your particular experiences with NI-VISA, but I've never seen anything like what you describe.

I guess my point is that I got burned by Omnidriver pretty badly several years ago.  The NI drivers (or at least my version of them) have never failed me.  And if they ever did, I can easily get under the hood and fix it.  Why would we trade all that for an opaque .net interface?  Particularly one we have to pay for...

I understand Ocean Optics probably doesn't have the resources to focus on driver development for LabVIEW, and instead focuses on developing drivers for more mainstream languages.  That's just good business!  And for those companies using LabVIEW that don't have the internal resources to do any driver development, your packaged .net interface may be the best approach.  But it's good to have an alternative available, so I would still encourage the LabVIEW community to continue to maintain and extend the native drivers as an alternative for those who need either to reduce costs or have more control over their end product.

JasonP

[James_G1]

Jason is basically right.  Omnidriver is written in Java to be cross platform portable.  The .NET interface was put in place to allow easy interfacing from all other .NET aware languages.  There is still the classic C interface for those who can not use the .NET interface.  Many of these decision were to allow us to serve as many customers as possible with our current resources.  The previous LabVIEW drivers were less than great. (I do remember your issues Jason and being frustrated that we simply could not fix them at the time, we have since addressed many of those issues)

All that being said, when NI approached us in regards to making native drivers, we did in fact help them greatly and continue to do so as we can.

The .NET drivers in labview do work very well however there are negatives.  An application using them requires, in addition to the LabVIEW runtime and components, the Java runtime to be installed, and the .NET framework to be installed.  This also means I can not transport my applications easily to Linux, BSD, or other non-windows systems easily.

With the NI drivers comes the ability to manage my connections with MAX which is very useful, also making distributed applications is simpler with VISA drivers.  I also have to ability to drop in on low level communications with NI-SPY (I use this a lot for testing), and of course the ability to change things/debug all the way to the bottom level.

The disadvantage, and this is pretty huge, is that with the NI drivers you miss out on any added features and updates that we put into Omnidriver, and we are constantly improving and adding to Omnidriver.  There are already quite a few features that Omnidriver supports that are not in the NI drivers and I don't think any time soon they will be.

Also as a side note, I have noticed that somehow the Omnidriver applications I have written run noticeably faster than ones using the NI drivers.  I was surprised at this and tested several times and always got Omnidriver faster by about 30%.  For some, this may be a critical advantage.

James G

[Jason_P]

James - Good to hear from you again!  You make some very good points, both on the pros and cons side.  I hadn't noticed the speed issues, but I generally don't do acquisitions with integration times shorter than ~50ms.  But it wouldn't surprise me.  To get real speed out of LabVIEW you generally have to be VERY careful to avoid memory allocations and to stay off the UI thread.  And even then, you sometimes have issues.  I can't remember specifics, but some of the LabVIEW primitives are less efficient than you'd expect.

Some big issues that you touched on that I forgot to mention have to do with application distribution.  With any LabVIEW application, the installer tends to be a monster.  I've got one that is currently just over 1 GB in size.  I'm stripping out everything I can, so native drivers are very handy.  And MAX really is a nice tool for configuration...

One question though... you mention new features available in Omnidriver that aren't available in the NI drivers.  Can you give some examples?  

JasonP

PS - For anyone reading this thread: I hope I haven't come across as overly critical.  I've been very happily using Ocean Optics products since ~2004, and I've always received strong support from the OO team.  I just like to have choices and would hate to see the NI drivers go away.