VISA Read overrun error - PeakTech multimeter with serial communication

[Blokk]

Hello!

I face a strange problem, someone with deeper knowledge might give me a hint what can cause it... Story:

I just purchased a multimeter recently (PeakTech 3430), and I started to make the LV driver using VISA functions.

I made a simple VI, see snippet below, and I setup the VISA Serial with the parameters regarding to this MM model (see attached pdf file, page 7.).

This works just fine, I installed first the USB-to-serial driver from the company website (Silicon Labs CP210x USB to UART Bridge - appears as COM3 in my PC).

I plug in the USB cable, turn on the "PCLink" feature in the MM. I run my VI, it works just fine (the comm protocol states CRLF termination characters, so for simplicity I just set LF as termination, and I read more bytes than expected).

However, what is really strange, if I stop my VI, and try to run it again, I get an "overrun error", see the snippet's FP for full error description. My VI will start to function properly again only if I unplug-plug back the USB cable to my PC. After this, my VI runs again just fine.

What can cause this? If this is a flaw in the MM firmware, I cannot really do much, but maybe there is a trick at the LV side to eliminate this problem?

Thanks!

[RavensFan · Accepted solution]

How are you stopping your VI?  You are using the Stop button on your Front Panel and NOT the abort button on the toolbar, aren't you?

(Okay, I know I shouldn't have had to ask you that.  But you never know?  )

If you use the Stop button, you shouldn't have a problem because the loop will end and the Close VISA will shutdown the serial port.  Then you shouldn't have any issue.  Unless there is a bug in their USB driver that is not handling the Close request from VISA properly and is leaving the serial port open.

if you put a VISA resource drop down control on your VI, does it look like the port is still open after you stop your VI?  (A symbol will appear next to any open Com ports.)

I thing there are two things you could do.

1.  Do a VISA read before the loop, ignore the data and clear any error.

2.  Do a Flush Buffer on the receive buffer before the loop.

Just throwing a couple ideas out there.  But the fact you say you need to unplug and re-plug the USB cable to get it to work makes me think these ideas won't work.

I wonder if there are any more hard-core functions, perhaps a Windows dll that could be executed that would programmatically kill the USB port and cause Windows to re-enumerate them.

[Blokk]

Of course I stop my VI as it should be done! 😛 😄

Man, you know the magic!!! "Do a VISA read before the loop, ignore the data and clear any error."

Ok, now I am interested why this trick solves the problem and eliminates the need of USB cable "re-plug"!? 🙂

[RavensFan]

---

@Blokk wrote:

Of course I stop my VI as it should be done! 😛 😄

---

When I started the reply, I didn't realize who I was replying to, so I was thinking along the lines of a newbie who has just discovered the Abort and Run Continuously buttons.  After I posted, then I saw "Blokk" and realized you're too experienced to make that simple mistake. 

Here's what I think happens.  Before, when you got the error, the loop immediately ended because of the error wire ORed to the stop condition and the VISA close executed, although it doesn't seem to be doing the job.  So when you restart, you're right back to the same situation you were on the previous run of the loop.  A period of time where an improperly closed Com port had data overflow the buffer.  But when you do the first read, followed by the loop of real reads, it is all happening quickly enough that the first read catches the buffer error and the reads in a loop can then run cleanly.

My gut feel is that this is a bug in their driver software, and ideally they would fix it.  I think pulling the USB cord was essentially the "Abort button" method of closing the com port.

I'd still be curious to know if the VISA resource control shows the port as being open after you run your VI one time before restarting it.

[Blokk]

I put together a quick project, not fully tested for bugs, and parts can be simplified for sure! Someone might find it useful, so I put it here to be easily found via forum search...

[satman]

Putting the ignore error outside of the loop helped greatly, however there is still out of bound errors noticed after a longer duration.

Is there any reason why we wouldn't put the 'ignore error' function outside of the loop as well to handle the errors that were not caught initially?

[XanderD]

Thanks a lot for the vi!

I still had to struggle with persisting "overrun error" right after starting the vi. I still need to find the right order of plugging in, activating PC-Link and starting the vi or or the windows app to clear the error.

[XanderD]

The function delivered occasionally several-seconds old voltage values from the meter, that must have resided in some buffer. I had to place "VISA Clear" functions on several positions in my vi to clear the buffer. That helped and reduced the lag to about 100ms.