VISA Close issues

[elset191]

If my program runs for any significant amount of time, say 1000 VISA Read cycles, then when I stop the program I can highlight execution and see that the program is getting stuck in VISA Close.  I have no idea what's causing this, and in the process of trying to figure it out I learned about NI I/O Trace.

I've got a few screenshots I'll attach.  The one called Lock.jpg has two NI I/O Trace sessions that caused the computer to lock up, and OK is two sessions that exited properly. 

The only thing I see is that in the cases where VISA Close stops everything NI I/O Trace has a blank spot in the Status column. 

I'm not including the actual .nitrace files because there's four of them.  I can if anyone thinks it'll be helpful.  I can attach code as well but I'm reluctant to because it's something I inherited and I'm embarassed to post it.  Also, it won't be too useful without the hardware.  Just trust me when I say I'm getting stuck in the VISA Close in this VI

[elset191]

Here's a picture of my debugging.  As I'm writing this both my Trace and Close.vi are still running and going nowhere fast.

I'm not certain, but I think in the past I've had it where VISA Close has the green arrow on top of it.  But based on the IO Trace, it has in fact been called.  Just not returned as near as I can tell.

[johnsold]

Tim,

Have you verified that the VISA Resource is valid where it enters the Close?   Perhaps valid is not the best word. Verify that it is unchanged from some earlier point in the program when things were still working correctly.

Lynn

[elset191]

Not specifically, but I know that when I start and stop in relatively short order everything closes down correctly.  I'm running a test now where I probe the VISA Resource after the VISA Open and before the VISA Close.  Assuming those two probes are the same, can I assume the answer to your question is yes?  Is there something more specific I should be checking?

Edit: Testing complete.  VI froze.  here's the two probes I put after VISA Open and before Close.

Not quite sure yet if that means its unchanged or not, though.  I figure I can't get more sure than the Session IDs matching.  (I don't remember where I got that VISA probe from, but I'm assuming it's doing things right.)

Perhaps somewhat relevant:

Does anyone have any idea how the physicaly wiring of my instrument could affect the VISA VIs, if at all?  I ask because when I was developing this code at my desk I didn't have any issues with the Close locking up.  I never ran it for these extended durations either, so I don't know if it's possible it could be related at all or not. 

[johnsold]

It was just a guess on my part. I agree that the Session IDs seem to be rather definitive.  The reason I asked is that I have sometimes seen a strange error, not necessarily in VISA, when the real problem was just upstream.  What about checking the error of the VISA Unlock?

Lynn

[elset191]

---

@johnsold wrote:

It was just a guess on my part. I agree that the Session IDs seem to be rather definitive.  The reason I asked is that I have sometimes seen a strange error, not necessarily in VISA, when the real problem was just upstream.  What about checking the error of the VISA Unlock?

Lynn

---

The VISA Unlock does in fact return an error (NI I/O Trace shows this too) because I have removed the Lock call during configuration a while ago in an effort to fix this freezing issue. 

However, I still see the same behavior when disabling the VISA Unlock, so I'm pretty sure that's not the issue.

[JÞB]

Tim, a few ideas come to mind.  Maybe no help but could a handshake setting be getting lost?  is that the right VISA class in the object or could it gotten twisted with a wrong class?  I'll assume that if this is a VCP via USB the windows hub power options were set.  Could this be a Keithley instrument with that odd serial adaptor?  What is the device?

[elset191]

---

@JÞB wrote:

Tim, a few ideas come to mind.  Maybe no help but could a handshake setting be getting lost?  is that the right VISA class in the object or could it gotten twisted with a wrong class?  I'll assume that if this is a VCP via USB the windows hub power options were set.  Could this be a Keithley instrument with that odd serial adaptor?  What is the device?

---

I'm not aware of any handshaking other than I send a command and it sends a response.  There's some RTS assertion and unassertion, but I don't know specifically what's happening.  As I said, the driver is inherited and a huge mess.  I don't know what a VCP is, but I've not done anything special and had it working in the past.  It's a Rosemount 3051S pressure transducer using a Hart to USB modem.

After much headache I've gotten this Hart driver working in a way I'm satisfied with, and it doesn't seem to have the same issues as the crappy one I've been trying to deal with.  Stay tuned.  Even if it does work, I'd still like to know wtf is going on originally, just as a matter of curiosity.

[JÞB]

well it does look like a Virtual COM Port (VCP) 

That is not the nicest looking driver I've seen but, I've seen worse.  Do a double check of the USB Hub power options.

[WANJA]

Hi Tim,

I am running into the same problem regarding the Visa Close freezing. This original posts did not conclude a solution in the end. Have you ever found out any possible solution for this issue?

Thanks,

Wan