LabVIEW
polling find visa resource
In this case I would never try to guess what the user might do but simply respond to the error I will get.
like this:
I have an application (Call it contnuous measurement and logging.lvproj) reading from a USB pressure plate and showing a graph of the weight. Something like the attached but replace the random generator with a VISA read. ( its just a snippet from one of my vits in File>>New...Frameworks. It has no functions attached and the type defs are not included)
But assuming I did replace the random number function with a sub.vi that read data from a USB Device through a USB to serial adapter- it would run fine all day long.
unless Joe User stumbles by and pulls out the USB cable because he wants to hang himself with it in the men's room. (See you just can't predict what Joe User is going to do or what he is thinking! you can try to apply all the logic in the world but, then some crazy idea will just pop into his mind...)
In this case the VISA read is going to throw an error, stop the consumer loop destroy the queue and the next event (I usually code some fault feedback to the producer) stops the producer and reports the error on screen. This is all you can easilly do with your software. Notify a human that hardware is in an unexpected state and get to as fail-safe a condition as possible.
You can predict some actions and code for "Reasonable" ones but if you really do need to cover any possible user action........ Well---- don't walk by any USB cables OK?
@El_Tipo wrote:
Jeff,
Thanks again for your replay.
My objective is to make the sw as dynamic as possible taking into account (how clueless the users can be and even more the onces that have no idea what it takes to code sw)
I underestand and partially (almost completly) agree with you, because you have more experience than me (developing sw at least)
Now, when you wrote, "you can try to code around it"
how exactly would you do it, looking at what I already have done.
It boggles me that windows is seeing this disconnect/connect event perfectly, and LV is blind to it... why... just why..
again thanks for your feedback,
I think what Jeff is trying to stress is that "clueless people" shouldn't be anywhere near your setup! You wouldn't let a toddler operate your chainsaw (with the possible exception of being faced with the zombie apocalypse). You should only have people authorized to run the test near the tester. That being said, the best way to handle this situation is to put a sign on the tester saying "Test In Progress. Do Not Disturb."
@El_Tipo wrote:
Using the GetPortNames method seems to update the PortNames as I physically plug/unplug the cable.
Observation: the name that this methos spits out are in the COM1, COM4 format. It would be really helpfull (and after playing with the different properties/methods of the serial port class I have not been able to find) to get the "humman readable text that describes the given interface" (similar to the VISA instrument property "Intf Inst Name") because there is a particular text in this name that I know the interface belonging to my hw has.
On the scenario where the sw is started with the cable UNPLUG (using the .NET approach) there is no way of knowing which interface belongs to my hw because user easily can connect something else (that is also serial) but not my hw to the machine.
On the scenario where user unplugs the hw after the sw has been ran, Iam able to hold (among other parameters) the VISA port (which I get from the VISA get resource.vi and VISA instrument property "Inft Int Name" and "Intf Type"), on the hw driver FG, and in the polling state I then read this driver FG and compare that value to the array of PortNames from the .NET GetPortNames.
-> user connects the same hw (COM4 = COM4) literal match connection restablished
-> user connects another hw (with similar characteristic such as serial etc) before conecting expected hw (COM4 = COM4) literal match false possitive.
-> user connects expected hw (COM4 = COM4) literal match (ideal scenario)
If the .NET could give me just a little more info about the resource besides (COM4 for example) it would be ideal.
Maybe Iam overthinking this things, any opinion on this will be apreaciated.
regards,
I see. Probably the easiest thing to do is send an ID command to the port and if you get a timeout or an unexpected response, let the user know and then let them try again or abort the test setup.
