LabVIEW
The program gets stuck while communicating via serial port
Hi,
It annoys me a lot recently.
I've writtten a code to aquire the data from an intrument by serial port.
It sometimes proceeds for a while and then gets stuck in such a way that user cannot terminate the program, even by the task manager.
(The only way is disconnecting the USB cable terminal(USB to Serial) from the USB port and connect it again.
The program will fail when running the program in the first time after reconnecting the USB, and works in the second time.)
I found the stuck point happened in the VISA Read, and I have no idea why VISA cannot get the data,
Then I modified the code by using the "Bytes at the Port". It seemed it works.
Could someone give some suggestions?
I do not know what point I missed and I still think it should be applicable by setting the "byte count" of the VISA Read.vi.
Assuming no data is coming from your instrument some reason, then the VISA Read will sit there until the timeout. By default, VISA has a 10 second timeout. You might concider lowering that. I highly recommend avoiding the Bytes At Port since it causes interesting race conditions with your instrument.
Hi crossrulz,
In fact, the time I waited is more than several minutes, it changed nothing at all.
I'm surprised that It can not be terminate by clicking the "Abort Execution" in LabVIEW and by task-kill in the task manager.
I have been taught not to use "Bytes at Port" in this forum, but I have no idea why there is a problem by implementing the terminator character and the byte count.
Although I can modify it in a way just putting a delay before the VISA Read.vi without "Bytes at Port". It seems it works too.
But why I should put a delay before the VISA Read? It shouldn't, right?
@William1225 wrote:
I have been taught not to use "Bytes at Port" in this forum, but I have no idea why there is a problem by implementing the terminator character and the byte count.
It is a race condition that I have ran into. Say you send a querry command to your instrument. That instrument takes time to get that command, process it, and then send the data back. So now let's say you use the Bytes At Port and you check for the number of bytes when the message is only half way sent. So since you are using the Bytes At Port to tell the VISA Read how many bytes to read, you will only get half of the message. Ok, so you throw in an arbitrary wait. The wait isn't long enough due to the instrument being slow to respond, so you still don't get all of the message. So you make the wait longer. Now you are just increasing the test time for no good reason.
@William1225 wrote:
Although I can modify it in a way just putting a delay before the VISA Read.vi without "Bytes at Port". It seems it works too.
But why I should put a delay before the VISA Read? It shouldn't, right?
The only time I have seen something like this is when I had a cheap serial interface (usually a USB-RS232 adapter).
