I seem to have fixed my problem of randomly occuring errors in my filterwheel control. But I don't know why this should actually work.

[Carsten_Schmidt]

Hi there,

I am using a thorlabs fw102B filterwheel. It's connected via USB (simulating COM port, that's what it says in MAX). The second device is a camera, also connected via USB. The application is running 24/7, at least that's what it's supposed to do. LabView version is 8.6.

The LabView code I wrote for this, was never really finished, meaning I totally ignored error handling in the first program version.  That never bothered me, because the program ran for weeks and months without any problem. Whenever I had to reboot my system it was not LabViews fault, but I was changing something else.

Recently I was running into problems with the filterwheel (after a system reboot). However, I don't understand the error in the first place: The filterwheel is supposed to change position every 15 minutes, in between the camera is taking exposures, then the data is written to an ASCII-file (only ~156 kB). At first the error occured just once: the filterwheel was set to the wrong position for about 15 minutes, which might happen, as it is not really could in counting. A few days later it was in that wrong positon for one hour, so it didn't respond to the "move" order four times in a row. Finally I didn't move at all anymore. The error message I was getting is "0xFFFFFFF unkown status code". In my opinion the communcation to the filterwheel got lost somehow. I don't know a better explantion. 

But why should it recover after some time?

The problem usually occured at night, when nobody is there to watch.

I investigated the behaviour in a second setup (see attachment). There is only the filterwheel connected. Through randomly unplugging the USB or power cable I was able to reproduce 'session handle is not valid', 'unkown status code' and 'session handle lost'. The program enters the 'true case', the session is to be closed and resetted, then it shall be reinitialized. This actually works as soon as the cables are reconnected. But why?

The close.vi still returns 'session handle is not valid', The reset.vi returns the same, but initialize.vi returns 'No Error' and the system works again.

What am I not getting here?

I read some threads here and somebody mentioned for another instrument/problem to use the 'reset' command twice. So I tried 'close-initialize', 'reset-reset-initialize', 'reset-initialize' but only 'close-reset-initialize' works (not surprising). Yet I still get the same errors (probe 1 and 2). Am I introducing more bugs without knowing than I fixed?

I AM CONFUSED.

Carsten

[UM]

Hello Carsten,

Unfortunately the “thorlabs fw102B” Instrument Driver is not listed in the NI Instrument Driver Network (http://www.ni.com/devzone/idnet/).
So I’m not able to have a closer lock on the source code. I guess, the “thorlabs fw102B” uses the VISA API under the hood.

The error “ -1074130544” occurs, when a session handle is not valid.

I checked out your screenshot, and I noticed, that you didn’t follow the paradigm of the dataflow.
Please try the following:
Always wire the reference from your VISA Session to the next VI.
Thus, you should wire the reference in your application in the following order:
“FW102x Initialize.vi” -> “FW102x Get Position.vi” -> “FW102x Close.vi”.
I hope this helps.

Ulrich

AE-NICER

[UM]

Hello Carsten,

Unfortunately the “thorlabs fw102B” Instrument Driver is not listed in the NI Instrument Driver Network (http://www.ni.com/devzone/idnet/).
So I’m not able to have a closer lock on the source code. I guess, the “thorlabs fw102B” uses the VISA API under the hood. The error “ -1074130544” occurs, when a session handle is not valid. I checked out your screenshot, and I noticed, that you didn’t follow the paradigm of the dataflow.
Please try the following:
Always wire the reference from your VISA Session to the next VI.
Thus, you should wire the reference in your application in the following order:
“FW102x Initialize.vi” -> “FW102x Get Position.vi” -> “FW102x Close.vi”.
I hope this helps.

Ulrich
AE NICER

[Carsten_Schmidt]

Hello Ulrich,

thank you for your answer. Concerning the dataflow I agree and it is what I usually do. Actually I follow the dataflow paradigm whenever there is no problem (the 'false case' in the screenshot):

“FW102x Initialize.vi” -> “FW102x Get Position.vi” -> “FW102x Set Position.vi”.

Whenever there is a mistake, this just doesn't work with these drivers. The sequence

“FW102x Initialize.vi” -> “FW102x Get Position.vi”  -> ///error/// -> “FW102x Close.vi”, “FW102x Reset.vi”  ;; “FW102x Initialize.vi”

will give me errors for “FW102x Close.vi”, “FW102x Reset.vi”  and “FW102x Initialize.vi” reporting "session handle not valid". However, if I "bypass" the instrument handles directly from the first "Initialize" to "Close" and "Reset", they will report the same error, but the second "Initialize" will work again. I can even merge the first two frames and execute "Close" and "Reset" at the same time to do so. But whenever I try something else, e.g. do the 'correct' wiring, I am unable to close, reset or reinitialize. I have to restart LabView completely, to make the vi work again. So I guess the session is still hanging around somewhere in memory, but I can't access it anymore.

Surprisingly, wherever I put Probes on the data handle wires they show the correct "ASRL5::INSTR" (with or without correct wiring). But only the "Bypass" wire makes the vi work. Since you couldn't find the drivers in the driver network, I guess they might just run into problems, if an error occurs.

But thanks for your comment anyway. The problem is fixed for the moment. It's just that I prefer to actually know what I am doing here instead of producing some code I'd rather not show anyone.

Carsten

[RipRock99]

Hi,

I was wondering if you might post your working FW102B solution.  We have 10 FW102B attached to our system, which also runs 24/7.  For us, for reasons unkonwon, random individual FW102 units will become unresponsive over time. We were reduced to rebooting windows to get them back, though rebotting LV may have worked; I will note that the dummy light on our USB hub would go dark/indicate a disconnect. It sounds like your error handling may have addressed this issue.

Thanks,

S-

[Carsten_Schmidt]

The screenshot of the solution is in the first posting. (without the Relais switch, which comes before Reinitialization)

The basic idea is to close the connection in case of an error and physically switch the filterwheel off for a few seconds then reestablish the communication. I happened to have a NI-DAQ module with a Relaiscard, so I could handle this within LabView itself. I'll for the complete code, but I am kind of busy right now. I am on a measurement campaign and I'm still fixing my LabView code 😉

C