LAN Communication with another software (Instrument)

[basetgh]

Hi

I am trying to send and receive commands using Labview to another instrument (that has its own software).

I cannot use GPIB or USB and LAN communication is the only way I can communicate. 

I am using TCP/IP to send and receive commands and it seems that this method does not work. the fellowing software gets error56 (which is very common and I was not able to sort it out).

I am using TCPIP0::123.254.3.4::5025::SOCKET

Commands I am sending: *IDN?   *OPC?    :RUN 

expecting to get different response for eazch command. 

is there anyother method or simple software that helps me to communicate or TCP/IPis the only way. If it is, then what is the problem of my software ? (i have changed the timeout to -1 or 30000ms and still I get the same error or I dont  get anything for -1)

I would be very greatful if anyone could help.

thanks,

[Guilherme_Correa]

Hello,

I would suggest that you make a few tests before having your problem solved.

First, try to ping the instrument using the command prompt.

Second, just open and close the connection using LabVIEW.

Then, use the error cluster to properly propagate the error in your VI

Finally, check the command sintax for your instrument, you may got the instrument to close the connection because it did not received the command properly. It could be as simple as putting a carriage return in the end of the string, or even wrong sintax.

Let me know the outcome from those tests.

Best of luck.

[jamiva]

Have you tried communicating the instrument using NI Max?? It may be easier to debug the instrument comms, than by using a VI.

Couple of other things to look at in your VI:

As Guilherme said, MAKE SURE you follow your command with a \n character. Right click your "Command to Send" control and select "\ Codes display". If you don't see newline character there, you need to add it.

Most instruments use port 5025. Some do not. If you are not 100% sure, read the manual.

Your TCP "bytes to read" is unwired. I always wire it with something. Usually a VERY large number. See next comment.

Your "Mode" is also unwired and defaults to "Standard". MOST reads are terminated by a CRLF. I would try changing it to that mode. The read will automatically terminate when a CRLF is read. Thus the reason you put large number in "bytes to read"

Once you get the VI to communicate, I would suggest you use VISA commands instead of the low level TCP commands you are currently using. Use your TCPIP0::123.254.3.4::5025:SOCKET as the resource.

[basetgh]

Hi Guilherme 

Thanks for your reply.

I am not sure exactly how I can ping the instrument. after googling I used the following link ( https://forums.ni.com/t5/Example-Program-Drafts/Ping-a-Computer-Name-IP-or-URL-Using-System-Exec/ta-... ) and pinged my instrument and the result is attached. 

then I just used open and close connection in lavbiew and seems there is no error.

The commands are fine as I used another software (provided by the company and is like NIMAX) and the commands working fine. 

[Guilherme_Correa]

That's fine, you can ping, open and close the connection to the instrument. 

This shows that the command you are sending is using the wrong syntax.

As noticed by jamiva, you are sending VISA commands using TCP/IP functions. As long as the instruments can handle TCP connections, there is no problem. However, if your syntax is wrong, you will receive errors.

Just make  a few changes to your code to include the end of line constant to every command sent, and alos the mode constant to the TCP read function.

If does not work, try to change first the mode from Standard to all others.

If that does not work either, change the end of line constant to other constant such as line feed or carriage return and repeat the tests.

[basetgh]

---

The point is that when I open NIMAX and I send command using VISA TEST PANEL in NIMAX, the instrument response is exactly what I want. It even starts any kind of measurement I require. However in VISA TEST PANEL when I send *IDN?\n, return data is correct, but it gives error saying Visa: (Hex 0xBFFF0015) Timeout expired before operation completed.

increasing/decreasing the timeout doesnt change the error, doesnt change the response data just finishes the operation slower/faster, gives the same response and error. 

I also used Instrument I/O Assistant and this function works well in Labview. However this method is not useful as I am not flexible in reading commands using Instrument I/O Assistant.

therefore it must be my code that does not work well. 

[basetgh]

I also tested this and does not work.

I changed my code to sending command only and the instrument started working. when I use read command I get this timeout error. 

[jamiva]

It sounds like you do get a response from the *IDN?\n. What is the message you get back. In other words, what is the very last character you receive? (may need to convert the return string to hex in case it is a non-printable character). I have seen some instrumnents that DO NOT use \n as the termination. This may be one of those devices.

[Guilherme_Correa · Accepted solution]

The reason why is working when you write using the VISA Interactive Control is due to the I/O Settings, in this Tab the Send On Writes is enabled  by default, and the also defines the termination character to be Line Feed (\n).

If you change the code to use line feed instead of carriage return it should work.

[basetgh]

Perfect. SOLVED!

Thanks a lot. This little issue took me some time.