Yes , as I wrote before first of all I Have used original labview software. After using diagnostics tool I Have reached this subVI and post an issue. I dont know what commands I should use, there is nothing about it in manual. What tool allows me to snoop What is being sent by any software from and to Device ? I'm new to this stuff, That is Why I came Here

What do you think the entire RS-232 / RS-485 Output and Input section is all about? Those look suspiciously like commands to me.

I have to admit that they do appear to be quite complicated - which is probably why they supply drivers in the first place. Furthermore, the settings aren't "random" - they all appear in the manual.

Instead of giving up on the manual, read it. Then use that knowledge to set up the drivers - it's all there. Then run the examples. Then come back and shower us with accolades because you got it up and running with our help.

Bill(Mid-Level minion.)My support system ensures that I don't look totally incompetent.Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.Humble author of the CLAD Nugget.

My name is Kevin Gudenkauf, and I am a test engineer at Alicat Scientific. I would be happy to help troubleshoot the issues you are experiencing and answer any questions that get brought up.

First: the previous statements from the other members are all definitely valid. Alicat devices have RS-232 communication by default, unless ordered otherwise, and make use of this in a simple text command/response format. At the most basic level, the communication can be done in an old-school terminal style where a single command is sent by the user and a response is read back out (we actually have a free Serial Terminal application on our website that is pre-configured for speaking with our devices: http://www.alicat.com/support/software-drivers/). Our Flow Vision SC program and the LabVIEW drivers are actually making use of the same set of RS-232 commands, but simply take it one step further, parsing the data and bundling the commands into more user-friendly user interfaces.

The LabVIEW examples all include a sub-VI in the initialization phase ("COM Port Initialization.vi") that establishes a connection with a desired COM port and sets the necessary COM port settings (stop bits, parity, termination characters, etc.), and should be present in any LabVIEW code that is establishing a connection to an Alicat device (in place of a VISA Read). The user-definable settings should be set to match the settings of the Alicat (COM port should be set to the COM number that the Alicat is connected to, baud and unit ID should be set to match the values shown on the Alicat's front panel menu).

If the device is operating as intended through Flow Vision but not when running a LabVIEW driver example (assuming you have fully closed all other programs that try to access the specific COM port, such as Flow Vision), the most common issue I have seen is actually that the downloaded driver folder has not yet been unzipped and is being run from the compressed folder. This is far more common than you may think, and is thankfully the easiest to solve (unzipping the folder and trying to run an example program from there).

If it is still not communicating properly with all other programs closed first and the files being located in an uncompressed folder, it is usually accompanied by other programs (such as Flow Vision or Serial Terminal) having issues as well and requires a little more troubleshooting to narrow down the cause (most often due to a missing ground reference or swapped 232 Rx/Tx wires). In these cases, Serial Terminal is actually the best fallback program for helping to determine where the issues lie as it can pinpoint things like garbled return text due to a floating ground reference.

Please let me know if this helps or if the issue is still present, and I will be more than happy to troubleshoot this further for you - either by forum posts or through email (kevin@alicat.com).

My name is Kevin Gudenkauf, and I am a test engineer at Alicat Scientific. I would be happy to help troubleshoot the issues you are experiencing and answer any questions that get brought up.

First: the previous statements from the other members are all definitely valid. Alicat devices have RS-232 communication by default, unless ordered otherwise, and make use of this in a simple text command/response format. At the most basic level, the communication can be done in an old-school terminal style where a single command is sent by the user and a response is read back out (we actually have a free Serial Terminal application on our website that is pre-configured for speaking with our devices: http://www.alicat.com/support/software-drivers/). Our Flow Vision SC program and the LabVIEW drivers are actually making use of the same set of RS-232 commands, but simply take it one step further, parsing the data and bundling the commands into more user-friendly user interfaces.

The LabVIEW examples all include a sub-VI in the initialization phase ("COM Port Initialization.vi") that establishes a connection with a desired COM port and sets the necessary COM port settings (stop bits, parity, termination characters, etc.), and should be present in any LabVIEW code that is establishing a connection to an Alicat device (in place of a VISA Read). The user-definable settings should be set to match the settings of the Alicat (COM port should be set to the COM number that the Alicat is connected to, baud and unit ID should be set to match the values shown on the Alicat's front panel menu).

If the device is operating as intended through Flow Vision but not when running a LabVIEW driver example (assuming you have fully closed all other programs that try to access the specific COM port, such as Flow Vision), the most common issue I have seen is actually that the downloaded driver folder has not yet been unzipped and is being run from the compressed folder. This is far more common than you may think, and is thankfully the easiest to solve (unzipping the folder and trying to run an example program from there).

If it is still not communicating properly with all other programs closed first and the files being located in an uncompressed folder, it is usually accompanied by other programs (such as Flow Vision or Serial Terminal) having issues as well and requires a little more troubleshooting to narrow down the cause (most often due to a missing ground reference or swapped 232 Rx/Tx wires). In these cases, Serial Terminal is actually the best fallback program for helping to determine where the issues lie as it can pinpoint things like garbled return text due to a floating ground reference.

Please let me know if this helps or if the issue is still present, and I will be more than happy to troubleshoot this further for you - either by forum posts or through email (kevin@alicat.com).

Great to see Alicat patrolling these boards!

Bill(Mid-Level minion.)My support system ensures that I don't look totally incompetent.Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.Humble author of the CLAD Nugget.

Well, to be honest I don’t know what I’m doing wrong. First of all I’ve used Serial Terminal for starting communication with serial port, everything worked fine. After this I have opened a LabVIEW soft called Full Driver, and communication timed out. After a few trials finally device have sent some data and it worked. That was really nice! But after disconnecting the device and plugging it into other PC or even plugging in again to the same PC that it started working it crashes again. I don’t have any clue why does this happen. Also I don’t have a clue why it doesn’t work. When I’m using COM Troubleshoot after rebooting PC, it shows me values, then I use Serial Terminal – it says connection is OK and it works. Then I’m opening LabView device, it Read times out and port is getting blocked, after this Serial Terminal nor COM Troubleshoot is working properly. I’m using only your software without any modification.

Maybe I should bond device with NI Driver Wizard or something? I have no clue.

Hmmm. That is definitely puzzling, the connections are usually an all-or-nothing sort of thing where I usually see issues connecting on all programs or no issues on any. It sounds like there may be a few issues we'll have to work around, and I'll be happy to assist.

1) With Serial Terminal working, I would recommend testing to see if you get any odd characters returned (such as question marks/other punctuation or even emoticons like a smiley face). To test this, simply connect using serial terminal and send the device's unit ID (such as "A") multiple times (at least 10-20 times). If the hardware connecting the Alicat to the serial port doesn't have a good ground reference, you can get intermittent errors that can cause issues when trying to parse it using an automated program like the LabVIEW drivers. If all of the data strings returned contain the same data format (starting with the unit ID and containing the same number of space delimited data columns) with no errors (bad characters, truncated data strings, blocks of no data, etc.), then the connection should be sound and we can look elsewhere for potential solutions.

2) To simplify things, we should start with a smaller program that is making very use of a very limited number of sub-VI's. If you could run the "Alicat Simplified Driver Example.vi" instead of the "Full Driver Example.vi", we can see if the issue persists. with this example, you can also create a probe on the error lines out of each sub-VI called (right-clicking the yellow error wires after each sub-VI in the block diagram and selecting the "Probe" option. Then, when running the program, you can see if it is getting hung up on the initialization, the data frame format generation, or the measurement acquisition which will help specify where to go for our next step.

3) It sounds like the program is being closed without the connection to the COM port being closed, which can cause the COM port to become locked up and unselectable/unable to be opened. This very well may be a flaw in the example's ability to handle being aborted, and I'll be taking a look at this later to see if we can improve it. In the meantime, you can force the COM port to close by creating a new VI that simply contains a "VISA Close" block with a control wired up to the VISA session (I'm . You can then select the COM port that is locked up and run the VI; the result is that the VISA session should be closed and the COM port number should be usable in other programs again.

4) There is also a bug that still needs to be fixed in the string-to-number conversions that take place, where it was coded using the default decimal separator rather than fixing the separator to a period. If you are in a location where Windows defaults to a comma for the decimal separator, then this could cause issues in the string-to-number conversions. This can be fixed at a lower level in the code by forcing a period to be used in the "scan from string" and "fract/exp string to number" sub-VI calls, or by altering your system's localization settings to make use of a period for the decimal separator to match the Alicat's output.

Hopefully these will help narrow down the issue and bring you one step closer to using the devices with LabVIEW.