viWrite problem on a socket source

[Naemeh]

I have an ethernet device (NetBurner MOD5270), which runs a TCP host program. I want to connect my PC to this ethernet device, using VISA library. I have configered the device in MAX as a SOCKET resource-> TCPIP0::10.1.1.30::37482::SOCKET. When I run VISA Test Panel from MAX, I can read and write to ethernet. But when I run my user interface I have a couple of issues:

1. How can I connect to the server using a visa function? I am currently using ConnectToTCPServer but I was wondering if there is a way to establish connection using a VISA function?

2. I can establish the connection, and a VISA session to the socket. When I write to the socket using viWrite command, the server is supposed to write back a confirmation phrase, but it does not do so. Only when I disconnect from the server by DisconnectFromTCPServer, the number of bytes which I tried to write appear on the server debug screen.

The same server code works fine with normal "ClientTCPRead" and "ClientTCPWrite" commands.
Any suggestion on how this can be solved?

[E.Okawa]

Hello Naemeh,

Thanks for posting in our discussion forum.

It sounds as if the program may need an termination character to indicate the end of the write statement.  Since you have successfully established a session, and you can communicate properly in MAX, we know that the VISA commands can work.  I have attached a basic read/write program that uses a carriage return to assert the end of the write statement.

What version of VISA are you using?  Are you seeing any errors?  How long does the program remain at each function?  If the attached example does not help, could you get an NI-SPY capture to further investigate the behavior?

Thanks
Eric Okawa
 

[Naemeh]

Thanks Eric for the response. I perhaps forgot to say I am using LabWindoes/CVI 8.5.0 to build my user interface, so I would appreciate if you could provide a .c sample.

I also think the issue is with the ending of viWrite. It gives no error when it writes to VISA session. I am not sure if the data is transfers to my ethernet device, but I know that ethernet device locks on read, and does not return untill I disconnect my PC from it.

I will review your sample program and see if it solves the issue as soon as I get it.

Thanks

[E.Okawa]

Hello Naemeh,

I have attached a cvi code that simply opens a resource, writes and reads, and then closes it.  You will need to put the specific resource in the viOpen resource quotes.  Also, the program is not currently outputting a value.  You can check the output by running it with NI-SPY or setting a breakpoint.

The main things to note is that the behavior sounds as if the write string is not being terminated.  You might want to play around with termination characters, such as \n and \r.  Also, could you get some NI-SPY captures of the communication using the program, as well as using VISA test panels in MAX (since these work properly, we can compare them)?

Thanks

[markus kossmann]

Hi;all

I see the same problem here,using CVI 7.1. I'am trying to control a program written by a collegue over a VISA socket connection. Reading the socket with viRead() works fine, but writing with viWrite() goes to nirvana. And playing with the termination characters didn't change anything. My collegue said, that he is using CRLF as termination , but putting /r/n at the end of the string to be written didn't help. And no error messages seen in NI-Spy when running the program.   

When digging documentation there is one question, I couldn't answer: What exactly does VI_ATTR_SEND_END_EN on VISA Socket resources ? The documentation for the Socket resources ( in CVI 7.1)  says that it is supported , but the Documentation for VI_ATTR_SEND_END_EN  mentions only VISA INSTR resources.  

[jb5475]

I'm having a similar problem with viWrite in a program we've written in C++ (VS2005). We constantly see extra characters getting dumped down to the instrument in question. Attempted tweaks to the termination character without resolve. We're explicitly checking any/all strings for their length and using this in the viWrite command, which appears to work since the status value returned doesn't indicate otherwise. Took some queues from the examples provided by the install (we're using VISA 4.5 by the way) and utilized instances of viFlush() and fflush(). Both only appear to resolve the issue temporarily and the same performance eventually reappears (typically after 5 correctly sent command iterations).

We have another tool we use for Ethernet/sockets communication that works flawlessly, but it would be nice to use a single tool (especially since the documentation indicates that it is a better or easier solution than typical sockets programming).