Weird VISA related problem

[MaSta]

Hello!

In my project I write up to three SCPI commands via VISA out to a device. See attached VI. In a test it was two commands. The second is empty and skipped. After every send it waits 50 ms.

The same code as in the test VI is also embedded in my project. Running it standalone reveals a weird behavior:

1) When executing the VI over and over with the LabVIEW execute button, it will randomly throw a VISA timeout error out of the Read VI within 50 executions.

2) When executing the VI with auto-repeat for a while, the error wouldn't occur

3) When doing the same thing outside of LabVIEW (we have our own software with a small scripting feature) and sending the two commands in a 15 ms intervall it will never throw an error, so it's basically not caused by our device not responding.

We are clueless why the VISA error occurs and why LV has a different result depending on how you run the VI.

[GerdW · Accepted solution]

Hi MaSta,

---

@MaSta wrote:

We are clueless why the VISA error occurs and why LV has a different result depending on how you run the VI.

---

How long does your device need to process the RESET (or that ERR request) command? Many devices will take significantly longer than just 50ms!

Also:

4) What happens when you place a while loop around the FOR loop to repeat the device-banging stuff instead of using RunContinuously? RunContinuously may have some side-effects…

You may simplify your VI like this:

What's the point of the 10ms wait before VISARead when you wait for a TermChar?

What's the baudrate of the serial port?

[MaSta]

The time for reset isn't the problem. Like I wrote, doing the same thing somewhere else with 15 ms per cycle gives no error. To emphasize: the problem only occurs when starting the VI manually over and over by clicking the run button. It doesn't occur when looping it. Runlooping was only for a test. The actual code, as embedded in my project, also does this VISA error when only run once in a sub VI. I sometimes get the feeling, VISA is too slow for the LV code. I also see that when opening the MAX and unfold the ports tree, it takes like 30 seconds to list a few COM ports. LabVIEW has always been that weird, though there thousands of background services running. When I run the code part in debug, it's also fine. The next time in normal mode - bang! Error.

The 10 ms: well, I sometimes forget that the read VI has a timeout. Waiting for the TermChar is a disputable thing. You cannot always expect a device to send it.

Baudrate: none. VCP.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

Waiting for the TermChar is a disputable thing. You cannot always expect a device to send it.

---

When your device complies to SCPI then it appends a TermChar to responses…

---

@MaSta wrote:

1) When executing the VI over and over with the LabVIEW execute button, it will randomly throw a VISA timeout error out of the Read VI within 50 executions.

---

Would it help to resend the command in case of TimeOut error to have your device respond?

(What's the use case of executing the VI again and again using the Run button?)

[MaSta]

Oh, that's a common misunderstanding. SCPI, or at least its standard, doesn't define the use of a termination character. This came from GPIB. We just continued to use it when SCPI was also used on other interfaces.

Resend: yes, probably. But again: it's not our device causing this! It's definitely VISA.

By the way, how do you guys make these enframed screenshots?

[GerdW]

Hi MaSta,

---

@MaSta wrote:

By the way, how do you guys make these enframed screenshots?

---

Select some code, then Edit->Create VI snippet from selection…

Attach the PNG to your message. This not only shows the code, but also contains it!

[MaSta]

A PNG can contain LV code? I doubt that. But I found it now. Never noticed

[MaSta]

Video: https://1drv.ms/v/s!AtqKRqgEh2kzmjac4uTe_878N9oi?e=CFdedo

[rolfk]

PNG stores its data in so called Chunks. Each chunk starts with a 32-bit length and a 32-bit identifier in the form of a FourCC (four character code) that tells what kind of data is included. The first character indicates if a chunk is critical if it is uppercase. The second character indicates if the chunk is public when it is uppercase or private, when it is lowercase. PNG reserves all public codes for itself but anyone is free to add private chunks into a PNG stream. And NI just did that, by embedding the diagram binary byte stream into it when you create a snippet. And on dropping such a PNG file on a diagram it will recognize that it contains this specific private chunk and extract it.

Now there is a potential problem however which at the time this feature was implemented did not really exist. Webservers and firewalls that do stateful packet inspection will recognize if a stream contains PNG image data and may be configured to only pass along public chunks in the stream to prevent malicious payloads embedded in an image. So depending how you download these snippets, they may actually end up being nothing more than a simple PNG image.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

A PNG can contain LV code? I doubt that. But I found it now. Never noticed

---

Many image formats can contain arbitrary information! And LabVIEW code is just another kind of "arbitrary information"…

Did you ever wonder how digital cameras store information like exposure settings inside of JPG images?