Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Tracking down invalid session handle error -1074130544 with 5620

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!

0 Kudos
Message 1 of 6
(7,897 Views)
Hello ness4,

I noticed in the code that you sent that the instrument handle is not passed out of the VI you are using. When there isn't an error condition, do you do anything to close the previous Scope session before attempting to open another scope session on your next run? If not, you should.

If this is not the case, or you are still getting the error after performing this fix, there is a method that may work to overcome this error. In an error case use two DAQmx Reset Device driver calls with the resource name of the Scope type cast as a string and used as the device in parameter of the DAQmx Reset Device VI.



Let me know if you are still having this issue after trying the first solution and whether or not the described workaround took care of getting your device working after this type of failure without a computer restart if the first solution didn't work or isn't applicable.
Message Edited by Dan_K on 03-30-2009 03:51 PM

Regards,
Dan King

0 Kudos
Message 2 of 6
(7,860 Views)

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.  😞

Message Edited by ness4 on 03-31-2009 11:37 AM
Message Edited by ness4 on 03-31-2009 11:38 AM
0 Kudos
Message 3 of 6
(7,836 Views)
Hello ness4,

For the first question, it would be best to close out your 5620 session separately from closing your MT session. The MT session, represented by the receiver info out wire, is separate from the 5620 session, even though it is based upon it.

For the second question, the behavior you are seeing with your 5620 is similar to another situation I have seen where a digitizer lost communication with it's host. There is a known bug in the driver that requires two DAQmx Reset Device calls to be made to reestablish communication in this situation. Now, given that this is only a similar situation, not the same one, this may or may not work, but it is worth a try.

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.

Let me know what happens.

Regards,
Dan King

0 Kudos
Message 4 of 6
(7,809 Views)

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!

0 Kudos
Message 5 of 6
(7,798 Views)
Hello ness4,

As a correction to my earlier post, the receiver info does contain the necessary scope handle and is closed with the ni5660 Close VI.

As for changing the VI to perform this type of operation, there may be a better way to perform the operation I described. Handle the error coming out of the ni5660 Initialize VI by externally calling the two DAQmx Reset Device VIs with the digitizer resource name wired into the device in input of each call. In fact the bug that required two of these reset calls has been fixed and downloading the newest version of NI-SCOPE should enable you to call DAQmx Reset Device once instead of twice during this error condition.

Regards,
Dan King

0 Kudos
Message 6 of 6
(7,774 Views)