How can i use the TCP/IP to control the instrument via VISA resource?

[crich19]

I had what seems to be the same issue as you have described but with another device (I understand that this may not matter to you anymore , but it would have helped me were there a response). I was able to resolve the issue I was experiencing in the following way:

I used wireshark to find what I was sending to my device when I was using NI Max. I sent the command "*IDN?\n". I noticed that it sent 2a 49 44 4e 3f 0a. The 0a is an ASCII standard for newline or \n. Essentially, it sent what I expected.

I ran the same write command on my LabVIEW VI. It is literally the same code I found in the NI-Visa Driver example in the following link: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000x3gXCAQ&l=en-US. 

Wireshark exposed the difference. LabVIEW VISA Write sent I noticed that it sent 2a 49 44 4e 3f 5c 6e. It sent ASCII characters "\" and "n" instead of the ASCII newline character.

I found a work around. In the string folder, there is a string Line Feed Constant. I combined it at the end of the write command (the write command does not have "\n" anymore). I made sure that VISA was not sending any additional end Characters as well. This sent the correct write string to my instrument, and it responded as expected. The read portion did not show any errors after these changes either. 

       

Below is a snip of the VI I have made that is currently working for me. I will make changes to the VI to tailor it to my needs, but I hope this will be helpful to anyone that seems to have this issue.

[rolfk]

Actually better yet: Right click on your string constant and select "'\' Codes Display".

Et voila!👌 Now you can enter your \n in the string and it is sent as 0x0A character code.

And to make things even nicer, right click again and select "Visible->Display Style". Now you see a glyph at the left side of the string constant/control that indicates what display style the string is currently using.

[crich19]

Thanks, I did that and it cleaned it up a little more!

[busybboy]

Hello, I'm having the same problem, here's how to solve it.

I solved it by synchronizing visa writing.

[antsundq]

Hey all, 

We had a very similar issue which I do not understand trying to communicate with an Electro Automatik power supply. We had some code for an earlier version of the PSU, which worked, but when we got the new unit it refused to communicate even if it should have been a "drop in replacement". I only found this thread after we got it working, so here are a few points we picked up.

- In MAX we could get the instrument to respond to *IDN?\n exactly as described earlier in this thread

- We discovered that the termination character has changed from \r to \n (so much for "drop in replacement")

- The device does not support fancier protocols, so we had it added as a raw socket

- We were trying to communicate using the VISA API connected to TCPIP0::192.168.200.16::5025::SOCKET

- VISA Open was successful, but got error on VISA Write

- Setting synchronous mode did not solve it (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q0000019jYeCAI&l=fi-FI)

- Using Wireshark, we saw that the payload of the *IDN?\n command was identical regardless if we sent it from MAX or LabVIEW, but we only got a response through MAX

At this point we were quite frustrated and decided to just swap the VISA driver for LabVIEW native TCP, and behold: it started working! 

I have tried to understand what differs between VISA and native TCP/IP communication, and eventually stumbled upon this thread. I have thus far not found any kind of explanation; does anyone see what went wrong for us using VISA?

/Anton