VISA TCP/IP error when using LabVIEW but NOT when using NI MAX

[Jim_Cavera]

This is a strange one.  I have an instrument (B&K Precision 2563 MSO) that I am trying to send messages to/from via its Ethernet connection.  In MAX, I can add the instrument and use the test panel to send an *IDN? query.  Everything works as expected.  I can also do the same thing when I use the Instrument I/O Assistant, but that ONLY works so long as the panel is open, meaning that when I hit the "Run" button on the assistant, it works properly and I can parse the information when it is returned.

When I do the smallest possible VI, or when I close the I/O Assistant and attach wires to it, I always get a -1073807343 error (0xBFFF0011) on the write.  I have tried this out on LabVIEW 2009, 2015, and 2017 with the same results.  The primary machine (LabVIEW 2015) is a Windows 10 machine and is new, out of the box, with nothing on it but LabVIEW, the drivers for the instrument from the company, and Wireshark (which was added after the problem surfaced in order to do the following debugging).

I threw on a copy of Wireshark so that I could see the messages to and from the instrument.  When I used NI MAX, the VXI-11 messages looked good.  When I used the smallest possible open-write-read-close VI's in LabVIEW, the messages looked... ummm... smaller?  I'm no expert on VXI-11 protocol, so no idea on this one.

SO... I coded up some TCP/IP VI's and copied the important parts of the good VXI-11 messages that NI MAX generated when running the IDN query.  And they ran with no issue and I got the data back that I expected.  I'm enclosing a screen shot of the VI with both parts -- VISA read/write and TCP/IP read/write.

Though I know that I could re-code all of the drivers to use TCP/IP VI's, that would be a monstrous time-sink.  I would like to get the VISA code working.  Please advise.

[Bob_Schor]

Well, it would have been easier to find the "flaw" (or "Why did you do it that way?" feature) in your code if you had attached it.  But you didn't -- shall we guess?

I have several balances that talks serially, with the traffic going through a port concentrator that uses TCP/IP for the transmission medium.  This might not be exactly analogous to your situation, but here is my "Open Balance" routine, after which I write and read VISA commands:

The sub-VI "Get Balance IP" uses the Station ID (here 1) and returns a VISA Port string (shown here as a comment, starting with TCPIP0::<IP>::<Port, 1>::SOCKET).  This works for me ...

Bob Schor

[Jim_Cavera]

There's no problem finding the instrument.  I know the address, NI MAX gives me the proper string, it works fine when sending the IDN query inside of I/O Assistant, etc.  The error occurs at the VISA Write VI (in the disabled portion of the original picture).

[RavensFan]

Turn on the display style for the string constant in the disabled part of your original picture.

If that is normal display, then the constant is wrong because you'd be sending a backslash and "n".

If it is \code display, then the constant would be correct because "\n" in \code display represents the line feed character.

[RTSLVU]

I ran into a similar thing, but that was several years ago so I can't remember the exact details but...

I think when using VISA for TCPIP connections it seemed to work better if I got it all setup and working in NI-MAX.

Then created a VISA Alias and used that VISA Alias as the VISA resource in my LabVIEW program. (instead of TCPIP::bla.bla.bla.bla::)

I know it should not make any difference, but it did...

[Jim_Cavera]

With regards to the display style in the disabled image... yep, it's in "show \ codes" format.

With regards to the setting an alias in NI MAX... yeah, I tried that.  No change in the behavior.

[RavensFan]

---

@Jim_Cavera wrote:

With regards to the display style in the disabled image... yep, it's in "show \ codes" format.

---

Be sure to make the display style visible on that constant so it is obvious that it is \codes.

[Bob_Schor]

@rtslvu:

     We were looking at 24 VISA instruments being read.  Eight years ago when a colleague developed this code, we "hand-coded" all of the Aliases in MAX, as you suggested, and it worked fine.  It did tend to clutter up MAX a bit, but so what?

     A year ago, I did a complete re-write/re-development of this Project, and in the meantime, we'd updated the OS, updated LabVIEW, etc. so the old MAX settings were long gone.  That's what prompted me to come up with an algorithm/sub-VI to make the long wordy string "on the fly" (since we only need to do it once when starting the up-to-24 Stations with VISA devices).  Haven't seen any problems (other than every once in a while, one of the ports will "freeze", probably because of a VISA "hiccup").

Bob Schor

[Jim_Cavera]

For making this easier, here's the VI that the screen shot is of.  It's in LabVIEW 2009 format.  Again, same behavior in LV 2009, 2015, and 2017.

[Jim_Cavera]

Some additional information -- two wireshark captures.  The first (from_instr_assist.pcapng) is from hitting the "Run" button on the panel of the Instrument I/O Assistant.  Recall that, once the panel is closed, the configured assistant no longer works and gives the same error as all of the other, low-level VI's.  The second (from_bk_00.pcapng) is from the bare-minimum, open-write-read-close VI.

Both send the VXI-11 messages for opening and closing a connection, but only the first one actually sends out the *IDN? write and subsequent read request.  The bare-minimum VI doesn't send either of those.  So apparently, it's getting hung up before it even executes the viRead and viWrite commands.

Anyways, more food for thought.