polling find visa resource

[El_Tipo]

Hello all,

I have a VI that searches the VISA resources (VISA Find Resources.vi) on the loca machine and spits out the COM port which the hardware is using.

I have found that if I enclose this VI inside a loop and unplog the serial cable that connects the hardware to the local machine, that the (VISA Find Resources.vi) does not update the resources.

example: say COM1 and COM2 are found (under device manager) once the cable that connects hw and pc is plugged, and that COM2 is the one that will be used to communicate to hw.

I see a change on device manager if I unplog the cable but not on the output of this (VISA find resources.vi)

Now if I take the vi out of a loop and manually run it (once or continuosly) using both the straight arrow and the two arrows (that signal continuos run) the vi updates equally as the Device manager.

I really need for it to do the same if I ever poll it (like iam intending for) because I want my sw to react to a disconnect event.

reading previous posts I checked the option of closing visa resources automatically under tools>>opetions>>enviroment.

any help in this matter will be greatly appreaciated.

regards,

[JÞB]

First what version of LabVIEW and what VISA version are installed?  I ask because you are describing the exact way legacy versions were intended to operate.

Next I assume since Windows is watching these COM resources pop in and out that they are USB-SER converters.  What make and model?

Then we can determine how you can get there from here.

[El_Tipo]

thanks for your prompt replay.

LV 2013

NI VISA 5.4

The HW is a medical device controller. The cable is USB female on one side (the one connected to the PC) and a mini usb (similar to the one on an android phone.

[El_Tipo]

I just opened MAX and this is what it shows under the devices.

the cable is unpluged (before opening MAX).

[El_Tipo]

After opening a service request and talking to one of the NI guys I was adviced to use the (VISA Write.vi) with *IDN?\n and get the disconect/connect event from there, but no luck.

I tried:

 My setup:

state machine ini state: ini hw FG driver (which inside has a vi that uses the (VISA FInd Resources.vi) to get the port

state machine open comm port, set up the visa comm on the hw driver FG and update a 2nd FG that holds the connection state.

then on my idle/timeout state (regardless if I successfully cought the port on my hw driver init state) I poll the same driver (which in its datatype has the COM port of interest (in the read state) and feed that to the VISA write.vi.

so in the case where i statrt te sw with the cable on (showing on the device manager), I get the port#, update the driver FG, update the connection FG, poll the VISA write.vi and its output is no error as expected.

Now as soon as i disconnect (Device manager updates the device by taking it out.) I see the error out of the VISA write as expected (resources are not on the machine or something like that) and hense I update my connection FG with the new connection state. (I probe the COM wire at this point and I see the parameters such as ID COM # etc which were the initially good COM port parameters. Now I connect the cable and I see the change on the device manager, but the VISA write.vi is blind to this.

I hope I have been clear explaining the sequence.

regards,

[JÞB]

Alright, so that is the problem!  USERS! changing physical connections during test.  DO NOT DO THAT!

This will cause an error to your program - your program should shut down.   A PROCESS was VIOLATED.  Specifically your company's policy to "Do Not Disturb, - test in progress"  NONE of your data is evidentiary!  It may be of engineering evaluation use but is of no value to justifying paying money to your company for delivery of product or service.  A process was violated.  That process was attemping to either turn raw materials into marketable product, prove the process did so without failure or establish some other scientifically useful evidence on which to base a conclusion.

You can try to code around that but, generally acceptable good practices ( and any of those certs) depend on proper controls and training. 

Now, I am more than willing to deliver what the client wants but, if they want a program that anticipates users that cannot follow a test procedure???.......  Those companies usually cannot afford my services  but, they won't be around long anyway so... no burned bridges

[El_Tipo]

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,

[srikrishnaNF]

Hi El_Tipo,

 The scenario which you explain that "FindResources.vi is unable to find the resources (i.e. com port which hardware is using) when the port is disconnected and connected to another port during the run-time even though the device manager is updating" is very surprising.

  I am just suggesting you to use the System.Io.Ports .net class and you can try creating a vi which works similarly with FindResources.vi .I am just attached a picture which will act as a start..

Regards,

SrikrishnaNF

[El_Tipo]

SrikrishnaNF,

First off thanks for the replay.

First thing in the tomorow morning I will take a look at that and build a little function to test it.

Will give an update then.

Regards,

[El_Tipo]

I have been browsing the .NET constructor and I have net been able to find the System.IO.Port

would it be normal if I happen to not have this on my machine?

If you could just send me the constructor that you posted on the picture it self and see if it is broken on my end or something it would be great.

Here are some pictures.

regards,