BFFF000E

[MartaS00]

I am using LabView to automate a measuring process using Thorlabs DC2200, connected to my computer via USB cable. I have encountered the error BFFF000E (TLDC2200 Self-Test.vi<ERR>Driver Status: (Hex 0xBFFF000E) VI_ERROR_INV_OBJECT: The given session or object reference is invalid.) - the weirdest thing is, that it appeared without me changing anything, then disappeared again after an hour (I was testing in on the same setup and code) and now it appeared again. It seems that it affects mainly the diode, as some code seems to be working and connects to the DC2200 with no problem. As my main work is with automating the pulses the diode gives out, this is a major problem for me. I have searched forums with this problem and tried their solutions, but they didn't work for me unfortunately.

Restarting my computer or the measuring device, or even disconnecting and reconnecting the diode didn't work either.

Please help.

[Jay14159265]

Hmmm that sounds like a flakey USB connection ( or driver ). When the error occurs can you confirm the the device is connected? 

[MartaS00]

Thank you so much for an answer. Unfortunately this is not the case, as I have checked both NI Max and NI Visa and both of them show the USB as connected.

The error occurs when you forget to choose (in the code) the input device and leave it blank, but then it doesn't go away even after stopping the code, choosing the correct device and then restarting.

This made me think that maybe closing and reopening the vi could be the solution, but that was not the case. I even restarted LabView, all NI programs, the computer and the measuring device - none of that worked.

[petrz]

I didn't worked with this Thorlabs device, but I worked with PM100 and some servo drivers and from my experience the Throlabs firmware and drivers has some bugs. It is quite sensitive to not closing communication session properly. Check if you are closing session every time even when there is an error. In some Thorlabs drivers, when error is on input of the close session the VI it will not run (code runs error case and skips the closing).
I remember that in some cases, when the PM100 was not responding I used the original measuring SW just to connect and disconnect and than it magically started communicating.

Check also if you are using the latest firmware version. Changing the USB cable could also help.

[rolfk]

Thorlabs hardware definitely can be problematic (as many other physical experiment setup devices hardware). It is often clear that the physical part of those devices is excellent, but the electronics/software part is a lot less than perfect. It seems almost like they let their physicist and scientific engineers design the hardware and software. in some ways overengineered, often using older development systems and only testing the software until it works, not until it works even when you do not follow the standard operation procedure.

[MartaS00]

Thank you very much for your answer.

Did you implement any solution in your code to fix this issue? I am simply developing the tools for a team of scientists, none of whom are computer engineers, so I would love to solve this in a way that would cause them to troubleshoot this by themselves as little as possible.

Also how would you go about "properly" closing the communication when the error appears?

[petrz]

I didn't resolved the problem entirely. I make sure the session is closed when application stop by stop button and also by closing the window. My code for opening closing sessions:

(Note that the error in of the close session is not connected. When Connect = False there is no action - just close sessions)

This code is called in event structure on the press button event. In case of error I just show the error dialog and leave to user to decide what to do (usually they will press the disconnect button and try connect again). If you running from LV environment avoid stopping it by abort button.

Then I added instruction what to do when it quit working :D, it's also app for lab so no big deal when there are some troubles. In my case it was: Stop the application, disconnect, turn the device OFF and ON, connect, check if (until) the power meter works with the Thorlabs Optical Power Monitor, close Thorlabs run again.

Check your firmware version, according to changelog they made some serious fixes on that. https://www.thorlabs.com/software_pages/ViewSoftwarePage.cfm?Code=DC2200

[rolfk · Accepted solution]

I'm sorry, I haven't used your specific device. I did have experiences with other Thorlabs hardware which was selected for their excellent mechanical and optical specifications. And been ripping my hairs out when trying to get it to work from within LabVIEW without pointing my right index finger at my nose, touching my right heel with the left hand and then pushing the start button somehow. The software can be very tricky to get running and especially to get running reliably again after having done one or more runs.

One thing: Never ever abort your LabVIEW program with the abort button!! That is almost certain to mess things up to the point that you have to restart the whole computer.

Your program must have a very well defined sequence working with Thorlabs hardware of almost any kind: Initialize, Configure, Prepare, Start, Acquire/Measure, Stop, Clear and Dispose and then your LabVIEW program should cleanly stop itself too. If you start to abort this sequence halfway, skip certain steps for some reason (for instance programming errors) or otherwise don't strictly adhere to it, you have a pretty good chance to get the driver into a mess. Nothing you can do about that than to follow that sequence strictly. You can't change the driver.

I usually created an independent task/daemon (a LabVIEW subVI that consists of a loop with a state machine that handles the entire communication with the devices and ensures the proper sequence no matter what). Then used queues to fire events to it and query results from it. If you are into advanced programming and use the Actor Framework or a similar message based framework, then make the Thorlabs device an independent actor. Test this very well and then again to work on its own in the right way. Then integrate it into your application. And hide the toolbar and don't ever let your users see (and press) the abort button!!