03-27-2009 07:23 PM
Hello,
I am trying to track down an invalid session handle error that we receive once in a while. I have created a program that is based off the ni5660 Getting Started vi and we run this ni5660 vi repeatedly (every 1 -3 hours) using many different configurations of input parameters. A single run can call the ni5660 vi hundreds of times with varying parameter values. The system runs for days (literally) and then once in while I get the error message that I've attached. So I traced through the error message's list of vis (ni5660SA -> ni5660 Initialize -> ni5660 Sub 562x Read) and have a couple questions.
1. On the very right hand side of the 2nd attachment there is an error condition where I see an NI-Scope Close vi and an ni Tuner close vi. However, in the 3rd attachment, when no error occurs, we do not see either of these VIs. Why would we call these two sub vis only when there is an error? Why not call them after each run whether or not an error occurs?
2. Has anyone else seen anything like this? My program literally runs through these VIs for days and then all of a sudden we'll get that error and many times we find that the 5620 digitizer is locked up and the only way to get it responsive is to reboot the machine. Shutting down and reopening LabView is not enough.
Thank you in advance for any thoughts or solutions you might have!
03-30-2009 03:50 PM - edited 03-30-2009 03:51 PM
Regards,
Dan King
03-31-2009 11:36 AM - edited 03-31-2009 11:38 AM
Hello Dan_K!
Thank you so much for trying to help me out! I really appreciate it!
1. You are correct about the instrument handle. This confused me for a while too because the vi that I attached is actually the block diagram for the ni5660 Initialize.vi that comes with the NI API. I could see that a session was opened and that an instrument handle was created within the ni5660 Initialize.vi but the handle is not passed out of the vi and the session doesn't get closed until I call the ni5660 Close.vi later down the line. I can only assume that the instrument handle is part of the "receiver info out" that is passed out of the ni5660 Initialize.vi. Does this sound reasonable to you?
2. Could you tell me why I need to use 2 DAQmx Reset Device.vis? I do not question the validity of your solution, I just wonder why I need two.
3. Would you suggest that I put the reset vis in the error box before I call niScope Close.vi (see below)?
Thanks again. My vis are up and running in the lab and have been for days now. I'm waiting for the error to be generated again so please don't think I'm not responding to you if you don't hear from me soon. I just have to wait until the error pops up again so I can make a few changes, then run the vis for several more days/weeks until it crashes again. 😞
04-02-2009 06:43 AM
Regards,
Dan King
04-02-2009 11:14 AM
Hi Dan_K
Again, thank you for your help! In the last part of your previous post you mentioned the following:
For the last part of your question, when the error you have described occurs, there is no point in closing out the session at that point, it is already gone. Instead of closing the session you would want to perform the two DAQmx Reset Device VI calls and then once again try to open a 5620 session.
I just want to make sure that I was clear in stating that the vi I attached earlier is actually the block diagram of the ni5660 Initialize.vi that is part of NI's API. I am a little worried that if I put two reset device calls in the Error case (and therefore remove the 2 closing calls) I will have modified NI's code which may cause troubles in the future if the API is changed. Do you think I may be shooting myself in the foot?
And one last question for today ... is there a place where I can find other known bugs that may be in the drivers?
Thanks again and have a great day!
04-03-2009 04:01 PM
Regards,
Dan King