Communicating with an Extech HD300 Anemometer

[Gzimmer]

Hope this isn't considered grave digging, but in the time since I last posted, I've made quite a bit of headway.

I've discovered that the values for most fields are sent in hex bytes that can converted properly according to IEEE754 standard 32bit single precision floats. Most of the difficulty I'm having now is related to VISA controls.

I'm intermitteningly getting: VISA:  (Hex 0xBFFF006C) An overrun error occurred during transfer. A character was not read from the hardware before the next character arrived.

EDIT: The second circuit is for fixing when the VISA gets stuck open, I found it works occaisionally. I also saw some success when changing the read from synchronous to asynch.

[Albert.Geven]

In your while don't open and close the port.

Open before the while and close after the while.

opening and closing takes a lot of time.

[Gzimmer]

Thanks, I've eliminated the case structure and have clear and open outside of the while. I'm not sure what to do for a close however, since in proper usage, the while loop would continue collecting data indefinitely. Attach it to the while loop stop maybe?

[Albert.Geven]

You only have to close the connection when not communicating, and that is after the while loop stops.

The only thing you need to do is either or both visa reosurce/error IO wires to connect from the wile to the close and the close will be handled after the while.

This is called sequencing by wires. Only those functions are called when all inputs are available. and in the case of the wires through the while it is after the while.

[Gzimmer]

Well, I have managed to have a proper sustained connection with one of  the four identical sensors I use in my system. Unfortunately, I cannot get 2 of them to connect at all, and the other only works occaisionally. I'm beginning to think this is a driver/hardware issue now. The devices connect via USB but are serial with a CP2102 USB to UART Bridge Controller converting them from their nature serial. I'm beginning to feel like this is just the mercurial nature of COM ports and serial interfaces rearing their heads.

Latest version of main VI attached.

[Gzimmer]

I've been disabling and reenabling the com ports in device manager to try and force them closed. Right now 2 of the sensor will allow me to open a test panel in MAX, but the other two return a busy error (0xBFFF0072).

When used in my program, one of the working com ports worked perfectly fine once. Then I switched to the other working com port and got timed out. Then when I tried the first working one again, I got the overrun error (0xBFFF06C).

[Gzimmer]

This isn't a bump, this is an update so that when someone else tries do this themselves, they might learn from my mistakes.

So, from a fresh reboot and untouched com ports, all 4 sensors are recognized in MAX and I can open test panels with all of them. Weirdly, half of them are recognized as being 4800 baud and the rest are set at 9600 baud. All but one sensor report having a conflict in settings with VISA vs Windows port settings. I went through each of these and set them all to 4800 baud. Today, none of the sensors decided to work after all that, each timing out when hitting the VISA read command on my VI.

[Gzimmer]

Here's my latest version. I'm consistently getting data back now. However, the sensors like to either give me overflow errors and send me 4 datapoints at once which throws overflow errors (possibly the same error here as I also run a Dell) or I will recieve only a few bytes of the 50 I'm working on. When I get an overflow, the bytes at the serial port is only ~400 so it shouldn't be overflowing. I think I'll try and deal with the overflows with header detection and disregarding anything past the first datapoint.

[Albert.Geven]

Why are you flushing the data inside the while?

[Gzimmer]

In the thread I linked above, it was one of the suggested remedies to the overflow problem. Which I still run into, despite only ~300-400 bytes being sent.