VISA serial write hangs

[Kevin J]

Hello all,

After leaving my program running over the weekend, I came back to see that it was hung up in the VISA Serial Write block.  Trying to stop the VI did absolutely nothing, so I ended up just closing it.  However, after I did that, a little dialog box popped up saying "Resetting <program name.vi>".  After about 10 minutes of it seemingly doing nothing, I finally just killed the process.  I started up LabView again, and after about 20 minutes, the same thing happened.

Ive seen other people describe similar, but almost all of those seem to be because of problems with other drivers for a USB to serial converter or something like that.  I am just using a regular built-in serial port so I dont have any of those.

I am running LabView 8.6.1 with NI-VISA 4.4 on Fedora 10, except with the stock 2.6.23 Fedora 8 kernel (due to an unrelated issue).  Does anyone have any ideas on what could be causing this or how to gather more detailed data on what is going wrong?

Thanks

[muks]

Can it be a cable issue? Suddenly the device gets lost will cause labVIEW to hang

[j.masse]

Kevin - I too am having issues related to mysterious hanging of comports. When it hangs, please check a couple things for me.

Is the CPU at 100% utilization?

Is this an executable that is hanging or are you running the development suite?

Also, try bringing up NISPY and see if the comport is active or not.

This is my NI Dicussion link http://forums.ni.com/ni/board/message?board.id=140&message.id=37722&jump=true and I have been experiencing this issue for a very long time but only when I build the application not during development.

[Kevin J]

Muks, I dont see how a cable issue could cause this to happen.  There is no handshaking going on, it should be able to write to the serial port regardless if there is a cable or device connected.  But I havent touched the cable at all recently anyways.

j.masse, the CPU isnt maxed out.  Its at the same 5-8% level that its at while the program is running correctly.  I am running the development suite, I dont have the stand alone application builder.  Ive never used NISpy before, but it seemed simple enough to stop Labview, start a capture in NISpy, and then start Labview back up.  So that should be running now and we will see what happens when it decides to hang again.

[muks]

---

when it decides to hang again.

---

The in consistency prompted me to ask abt the cable. Hmmm.....

[Kevin J]

So it hung a little while ago, and after letting it sit there for about an hour I stopped the capture.  Attached is the last 100 events that NISpy recorded.  The last event (copied below) is a VISA Write of a newline (0x0A) to the serial port.  There is a start time listed but no ending time or return value.

891125.  VISA Write ("ASRL1::INSTR", ".")
Process ID: 0x00007823         Thread ID: 0x072BCB90
Start Time: 12:19:58.209

Anyone know why or how this could be happening?

[Dennis_Knutson]

I see a lot of instances where you are apparently calling the VISA Configure Serial Port. Normally, you would only do this once. Is there a reason that you are doing this?

[Kevin J]

Dennis, mostly because I dont want to pass a configured serial port object all over the place throughout my program.  I have one subVI which takes in a string and writes it to the serial port and ensures that it gets the correct response back, and thats the only place that the serial port is written to or read from.  When that subVI exits, the serial port is closed and so the next time it is called it has to reconfigure it.  I have lots of places throughout the program which calls that subVI though and it would be a hassle to have to connect every single one of those up with a serial port object.  It would be nice if I could configure it once globally and then just use that every time I need to but I dont know how to do that.

[Dennis_Knutson]

It would be nice to see your code but if you are passing a VISA Resource (i.e. Comx) in, you just have to do the read and write in the subVI. Don't close the com port more than once either. Even if you aren't passing the resource and have the com port hard coded in the subVI, you would do the same thing - just don't close it. The only reason you would need to close the port is if you need another program such as Hyperterminal to access the serial port.

[Kevin J]

Hmmm.  Ok.  I had figured when the subVI exited that the serial port would be closed since it was no longer being used but I guess it doesnt do that.  I changed it up a little bit to not close the serial port at the end of the program and it also takes a Resource name in (though in every place it is called a constant is hooked up to it).  Now the only VISA calls being made are reads, writes, flushing the buffers, and a get attribute (for number of bytes at port).

I have attached the code that reads and writes to the port.  It is rather complicated because you are supposed to send 1 character, make sure that you recieve that character back, and then send the next one.  Also, there could be an unknown number of characters sent back after the last one you send, so I had to handle that as well.

Do you think the constant calls to configuring the serial port could have caused it to hang every once in a while?  Its back up and running again so I guess Ill see if it hangs in a little while.