Error when reopen USB connection without physical unplugging USB connection

[B.B.S]

Using Labview 8.5 to communicate with an USB device based on AT91SAM7S64 controller.
I has written a labview application that talks to several units and it works good as long as i dont close the USB connection
I wants the application to start talking to all USB devices that are already connected, at the moment i must reconnect all USB connection every time I start the Vi.
 
If a try to reopen a closed USB connection I got an timeout error when I read data from the device
to illustrate the problem I made a dummy test program. (Added as Attachment as jpg and vi)
 
Senario 1:
If i plug the USB connector into the computer and start the vi the first sequence works fine.
The second sequence fails.
 

Senario 2:
If i plug the USB connector into the computer and start the vi the first sequence works fine.
If i unplug and plug the USB connector between teh two sequences both works fine
 
Senario 3

If I remove the VISA close from the first sequence.
If i plug the USB connector into the computer and start the vi the first sequence works fine.
both sequences works fine without needing to unplug the USB connector.
 
Questions?
Does the VISA close command send a message to the USB device? can this be the reason for the need to replug the connection?
Does it exist a method to reopen a USB connection that has been closed?
 
All help is good help :-)

 


USB_error_example.jpg:
Loading Image...


USB_error_Example.vi:
http://forums.ni.com/attachments/ni/170/347395/2/USB_error_Example.vi

[James McN]

Hi B.B.S,
Firstly thanks for a very well written question!
I am just having a look at your problem and trying to find out exactly what the VISA close is doing that might explain this behaviour.
In the mean time with regards to general architecture I wondered whether you could avoid the problem by only closing the connections at the end of the running of the program, do you need to close and then re-open the session in the program?  or could you just use a shift register and state machine architecture to re-use the current session.
In the mean time I will try and find out why you should need to do this anyway.
Regards,

[James McN]

Hi B.B.S,
I have been trying to recreate your problem with some success.  What seems to be happening is by closing the connection VISA is telling Windows to close the connection to the USB device, akin to using safely remove device for a USB drive.  So when the second scan is done for USB devices as far as Windows is concerned the device is no longer plugged in.
The best solution is to keep the session open, it should be possible to architect the program in such a way that you can keep the session open for the duration of the program.  Generally I would say a good place to start would be to look at a state machine architecture (you can find this as one of the templates in LabVIEW) and you can use a shift register on the while loop to pass the session ID to the next state.  This is how the examples have been produced that you can find in the LabVIEW example finder at hardware input and output>>VISA>> USB RAW- xxxxxxx.vi
Hope this helps.
 

[B.B.S]

My current solution holds all connections open until i quit the application.
A shift register contains the name on all earlier opened connections and uses them if they exists.
There will be a limited connections that is not in use but thats ok.
 
But it seems correct to close them when i quit the application.
When I start the application again i get the same trouble.
The testsystem this labview application should be used inn will use between 7 and 15 USB units.
they
 
 

[B.B.S]

Not sure why the posting suddenly was sent... :-)
to summary.  it should be operated by a lot of people that will probably start and stop the application. they will change the 15 units three times per day.
I must have 100% control over the USB connections.
And i am not quite there yet .-(
Thanks for the support so far.
BR Bjarne

[James McN]

Hi Again,
I have tried to recreate the issue when using multiple runs of the same program but this time I have been unable to.  Mine does manage to find the device again.
I have had a word with a few people and they have proposed a solution that would involve writing the references to the registry or a configuration file.  They suggest:
First Run: The program will look to the registery/file to try and find the references.  It wont find any so it will open the VISA references and write them to the registry. This should not close the references at the end of execution.
Run n : The program will look to the registry/file and find the references and use these for VISA operations.
First Run after Reboot: The program will look to the registry/file and find the references but will find that they are invalid so it will open new references and write these to registry for subsequent runs.
Functions for writing to the registry are under connectivity>>windows registry access VIs and have all the usual LabVIEW help files associated with them.
I hope this helps! let me know how it goes.
 Message Edited by James McN on 08-07-2008 02:10 PM

[B.B.S]

Hi
 
I have now implemented a workaround for the problem.
 
A shiftregister contains all open sessions.
Everytime the application checks for new USB connections in the applications (FIND VISA) it closes all sessions that is not in use (VISA Close) and removes it from the shiftregister.
When the application closes the sihiftregister with the open sessions are stored in a textfile.
The textfile are read at application startup and putted into the shiftregister.
 
Seems to work :smileytongue:
 

This workaround is done in the microsoft Windows Spirit "Eat memory and keep it for later"  :smileymad:
 
Thanks for the help James
 
BR Bjarne