Visa read and write to text file freezes application

[Wolleee]

Hi all,

I ran this VI as a a portion of an exe overnight, but i can tell that after 2 hours the write to text portion stopped working, based on the latest update of the file.  Both files stopped working at roughly the same time, and when i debugged the code it looked as if this portion of the VI had frozen.  Upon trying to properly close the VI, it froze and i had to force quit the application.  The file sizes were around 130KB and 1.7MB.

Any suggestions?

[mikeporter]

What portion of which VI? What error did you get?

Your code is looking for and displaying error, right?

Mike...

[Wolleee]

Sorry, I attached it like 3 times and for whatever reason it wasnt working.  I hope this VI attaches.  But i actually dont get an error, the portion of the VI attached will stop working.  I also have some sort of issue with the USB devices, i think they may be powering down.

[mikeporter]

USB devices powering down after son period of time is a known problem with Windows. There is a setting in (I think) the device manager to change the setting. Try googling it.

Mike...

[johnsold]

I can see several possibilities for your freezes.

1. If the USB serial port emulation shuts down or stops responding (as you ask in another thread), nothing will get enqueued.  Then the Dequeue in the upper loop will wait forever. The default timeout on Dequeue is -1, which means never timing out.  The Abort execution button should get you out of waiting for timeout.

2. You wire error out terminals but do nothing with the wires. Wiring the error out (I think) disables automatic error handling for those VIs/functions. So you will never see any error which may have occurred. Wire error indicators or on of the error handler VIs.

3. NEVER use termination characters and Bytes at Port together. If your device sends a termination character, use that and simply wire a constant to the byte count input which is larger than the longest message you expect to receive. Remove Bytes at Port. VISA Read will wait for the termination character.

4. Get Queue Status can be removed since you do not use any of its outputs.

5. What happens if a file error occurs? The VI tries to continue writing to a file which may not exist or be open.  Robust error handling is a good idea for programs which run for long periods.

6. What happens if the USB communications fails? See 5.

Lynn

[Wolleee]

Lynn,

I will obviously have to do some error handling for a more robust system.  Do you have an example for 1 and 3.  There is not always data on the port, so i didnt want to read and timeout if there is nothing there.  Now do i need to let the read timeout and then simply handle the error? I was told to do this before but didnt have an example.

To better diagnose part of the issue, after i start the application, it will freeze, and i will try to abort it then i have to force quit it.  When i reopen it i can see all the ports as they should be but if i disconnect a usb device and plug it back in, it will not show up again if i refresh.  Now i assume the port didnt get closed correctly, but labview should have control of it still correct?

thanks for any help,

Matt

[johnsold]

Matt,

For 3 the changes are straightforward.  The case structure connected to the error wire will prevent writing an empty string if a VISA error occurs.  Timeout will generate an error.  The default timeout for VISA Serial Read is 10 seconds. That can be changed at VISA Configure Serial Port.  You could also send a status message to the other loop if it times out, just as you do when stopping.

For 1 using a dequeue timeout may be a possiblity. You then test the timed out? boolean output and respond accordingly. I am not sure what your system shoud do in the event of a timeout so I did not try to change anything. The timeout value may need be coordinated with the VISA Read timeout. Using the status message may be more flexible than having two indepedent timeouts.

Plugging and unplugging USB serial ports is often something not easily handled in the LV program because the OS is also involved.  Generally USB is a poor choice for programs which need to run for extended times.  Search for Jeff Bohrer's posts on USB power management issues. Do everything in those to try to minimize the problems. If possible physically block access to the USB connectors so users cannot disconnect the cables.

Lynn