Weird VISA related problem

[LLindenbauer]

---

@MaSta wrote:

@LLindenbauer: Thanks for your intention to help, but I explained this several times now:

- it doesn't occur outside of LV and VISA

- the response time of the device isn't the problem, as shown in the video -> it's fairly stable when doing the same in our C# software

Regarding the first iteration: no, as the query is in the 3rd iteration. 

Sorry, I missed the video link.

You can bypass VISA by using .NET, like so:

(See https://learn.microsoft.com/en-us/dotnet/api/system.io.ports.serialport?view=dotnet-plat-ext-7.0 )

This may give you more options to diagnose the problem.

I find it curious that in your C# trace, the reply to "syst:err:all?" seems to come instantly, with TX and RX happening simultaneously. This need not be connected to the problem and your controller might actually be that fast. Still, If I were confronted with this task, I'd try to diagnose the hardware first.

[MaSta]

---

@LLindenbauer wrote:

---

I find it curious that in your C# trace, the reply to "syst:err:all?" seems to come instantly, with TX and RX happening simultaneously. This need not be connected to the problem and your controller might actually be that fast. Still, If I were confronted with this task, I'd try to diagnose the hardware first.

---

That's simply because the device replies in less than 1 ms. However, as mentioned, not using VISA Open VI seems to do the trick.

[daveTW]

Hello MaSta,

it also could be a problem with your VISA installation, your computer settings or something else.

Though I come a bit late, I tried to figure out what could be the problem with your VI and made an responder VI, talking via crossover FTDI cable. It looks like this:

It just collects every received char and answers on an occurring '?' with 1ms reaction time.

I had no errors, neither with single click nor continuously run.

For me there seem no problems with VISA.

Edit: not all important parts of the BD were visible

[MaSta]

Did you also have those random errors when running my VI? Like I showed on the video? 

[daveTW]

No, as I wrote before, neither with single starting rapidly and repeatedly nor with continuous running.

[daveTW]

So, on my machine your VI worked without problems.

Environment: Berlin, cloudy, Win10 x64, LV2019 x86, Intel XEON E5-1620 0 @ 3.60GHz, 8 GB RAM

[MaSta]

Like the title says, weird. I use LV2015 on Windows 10 with VISA version 21, supposedly from LV2021 installation.

Let's end this topic here.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

I use LV2015 on Windows 10 with VISA version 21, supposedly from LV2021 installation.

---

This sounds weird - according to this KB note…

[rolfk]

That chart is only about what NI tests. And since VISA is basically a shared library that gets directly loaded by the LabVIEW runtime dynamically when needed (the first time you call any VISA function) and doesn't require a VI based interface to be installed, it is VERY version independent. A VISA installer MAY put some extra VIs in a LabVIEW installation and those will only be available in LabVIEW versions that the installer supports, but the basic VI nodes are all built in primitives that under the hood access directly the system wide VISA shared  library. And VISA had a very stable API since its early days with only minor additions such as extra bus specific support for VXI and USB functions. And as long as you don't call those primitives in your LabVIEW program, you won't even notice that your old VISA version doesn't support them, but for this to happen you would have to install a really really very very old VISA version such as 4.something.

So in a nutshell, the version limitations that other NI drivers have for specific LabVIEW versions don't really apply for NI-VISA. But mistakes and accidents and unplanned API changes could happen and then your function call may behave strange, produce bad results or even outright crash. So if you operate outside of that version compatibility chart it may and usually will work, but if it doesn't it is your problem and your problem alone.