Alicat Error 1073807339 VISA Read

[HuntrTrakr]

Hi guys!

I have an issue which somebody out there might have a solution to. In my setup, I am using an Alicat Mass Flow Controller and LabVIEW to communicate/control the MFC. As I am somewhat new to LabVIEW, the "Alicat Simplified Driver Example_Setpoint.vi" has been our test bench for troubleshooting. Everything has been working great until my boss and I were bug testing. We momentary unplugged the USB - 8 Pin DIN cable from the Alicat device to simulate a loss of communication between the devices. What happened next was the dreaded "Error 1073807339"!

I have isolated the problem to the VISA Read function within the "Read Mesurements.vi". This .vi is located within the while loop of the block diagram. My understanding of the problem is that LabVIEW is trying to communicate with a device at the current VISA path, but no longer finds the device at that path. From this, it throws up an error.

*****

I was hoping somebody could point me towards some material with information on error handling or maybe you have encountered and fixed this problem yourself. My boss and I would like LabVIEW to display a message saying ex. "Device *Name here* is unplugged from *Comport here*", and for LabVIEW to hold itself in a "Pause state", instead of crashing.

*****

I have attached the VI's below.

One important thing to note. The device I am using right now is a 64 bit Mac, which does not open the attached files because LabVIEW loves VISA support on 64 bit Mac systems! I will be able to open the files until tomorrow when I have access to the lab machine, but I am trying to get a head start with solving the problem.

Thank you,

Huntr

[Ben]

I have seen USB devices pick-up a new Com port number when uplugged and then replugged.

NI stuff (for the most part) avoids that problem by tracking the serial number of the widget.

If you want to code around that you will have to look for that "Time Out" error and then figure out which port if and any it may be on.

Ben

[Kevin_Alicat · Accepted solution]

Hi Huntr,

My name is Kevin Gudenkauf, and I am a test engineer at Alicat Scientific. I would be happy to assist in getting your setup to perform the way you'd like when things get disconnected.

Am I correct in assuming that initially (after disconnecting the Alicat) the readings drop out and don't return after reconnecting the device, with the error only being displayed in the pop-up window after the program is ended using the "End Program" button (this is the behavior I get on my PC)? (this is the behavior I get on my PC) The issue is indeed as you are saying: during the operation, the program tries to communicate with the Alicat but receives no response. On no response, the error wire picks up the "true" value with the associated error code, which is then passed through to the other subVIs. The simplified Alicat driver examples currently have limited error handling, where it is assumed that if there is an error on the input error wire, the device is no longer connected and requires additional actions to bring it back online.

The good news is that this can be resolved fairly easily, and in a manner that you're looking for. After the device is unplugged, the error wire takes on a true value to indicate that an error is present. You can then wire this error line into the selector of a case structure and let it display something to the user. The easiest method to enact a sort of "pause-on-disconnect" would be to add a one-button dialog subVI on the error case, which can halt execution of the main while loop until the device is reconnected and the button is clicked. Assuming the Alicat is plugged back into the same COM port and no additional initialization or steps are needed, clearing the error and releasing it should make the measurement reading subVI work again.

See below for a screenshot of what I mean, since it should explain it better than I can:

and the "no error" case looking like this:

Please feel free to let me know if you have any questions, and I will be happy to help get your program set up with the error checking features you're looking for.

Best regards,

[HuntrTrakr]

Kevin,

Thank you very much for your assistance! I may send you an email if I have any more specific questions about the MFC's or how to implement them into my LabVIEW system.

Thank you,

Huntr

[emmagift97]

Hello. Can you please send me the whole program so that I use it on my project 

[Kevin_Alicat]

Hi Emmagift97,

The program is actually available for download from our website here: https://www.alicat.com/support/software-drivers/labview-virtual-instrument-drivers/

The above alterations were shown to Huntr to help stop the example program in the event of an error so that the user could fix it and tell it to keep going. Please feel free to let me know if you have any questions, and I will do my best to assist.

-Kevin

[emmagift97]

Thank you so much kevin

But can those vi's work when connecting Alicat MFC's to an NI USB daq board?

[Kevin_Alicat]

Happy to help.

Those functions and programs are all based on NI-VISA serial communication with an Alicat device, and I believe the NI USB DAQ devices are for reading and sending analog signals, so I do not believe it would fulfill your needs. I see that you've made a recent thread on the NI USB-6000 here: https://forums.ni.com/t5/Multifunction-DAQ/Alicat-flow-controllers/m-p/4047109?profile.language=en

As the topic will be on analog communications rather than serial issues, I'll respond in that thread.

[emmagift97]

Thank you very much kevin.

I'll be waiting for your response in that thread 

[HuntrTrakr]

Hi emmagift97,

I no longer have access to those VI's as I was an intern at a company 2 years ago and they retained all of my work.

I took the fix suggested by Kevin (the accepted solution). As well as I can recall, the error checker would poll the serial port every n seconds to see if the device was reconnected. I did the re-connection logic subVI with the same subVI's you use to initialize the Alicat product. Once it was able to reinitialize, the error line would be set to "False" and the program would return to normal operation.

I was able to run this in parallel with 4 MFC's and 1 MFM. When one of the devices was unplugged, a warning box would pop up saying that "MFC # is disconnected at COM Port #". This had no effect on the other devices, and the system was able to operate normally.

I'm sorry I can't be of more help by sending you the VI's.