Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP/IP Visa write Termination Character

Solved!
Go to solution

Dear All,

 

I have done an application with LabView where I communicate to my instrument via  RS232. I use the VISA command.

This application is working OK.

Now, here is my problem, my instrument also have an ethernet interface, so I want to be able to communicate by using TCP/IP socket.

The problem is that I did not find in the properties of TCP/IP socket, an equivalent to the "End Mode For writes" of the serial properties.

If I want my instrument understand what I send, I need to add a 0x0A character to the sent string. When I use the RS232, this is done by the "end mode for writes".

I would like to avoid adding manually a 0x0A when I communicate by Ethernet in my whole programm because it is quiet big.

Do you have any idea ?

Thanks a lot for your help.

 

Best regards,

0 Kudos
Message 1 of 10
(10,313 Views)

Hoi

 

Make a simple subvi that checks on a visa property node if it is serial or not and add a LF to the string in case of ethernet.

 

Evven simpler is to add a LF in the lowest send vi always and remove the end enable for serial.

greetings from the Netherlands
0 Kudos
Message 2 of 10
(10,303 Views)

Hello,

 

What you are suggesting is exactly what I want to avoid because in this case I need to change all my programm !! and this is a quite big application.

As far as I have understood, I have to modify every time I use the VISA Write command !!

Any other solution ? 

Thanks.

 

Best regards

0 Kudos
Message 3 of 10
(10,299 Views)

From the Help:

Message Based Settings:Send End Enable

Short name: Send End En

Member of the TCP/IP Socket class.

Specifies whether to send an END indicator on the last byte of each write operation. This property is relevant only in VISA Write and related operations. The default is TRUE.

On Serial Instr sessions, if this property is set to FALSE, the write transmits the exact contents of the user buffer, without modifying it and without appending anything to the data being written. If this property is set to TRUE, VISA performs the behavior described in the Serial Settings property End Mode for Reads (ASRL End In).

On GPIB, VXI, GPIB-VXI, TCP/IP Instr, and USB Instr sessions, if this property is set to TRUE, VISA includes the 488.2 defined 'end of message' terminator.

 

What you could try is setting this property and the termination character to 0x0A and see if that works.

 

Also, this is probably too late but if your program is just using a large number of VISA Writes, you can now see the big advantage in creating an instrument driver where you would only have a handful of VIs to modify.

0 Kudos
Message 4 of 10
(10,291 Views)

Hello dennis,

 

I always read the help and look for information before posting on the forum.

I have already set the send end enable to true and define the termchar as 0x0A.

While performing read operation, the operation stop as a 0x0A is received. So it is working correctly.

 But, in the help, I understand that the send end enable will send the the 488.2 defined 'end of message' terminator, not necessarely the termchar character.

In order to investigate, I have use the NI Spy, and the result is different when I send manually 0x0A (I see it is the write operation). If I don't add the 0x0A character and even if the termchar = 0x0A & send end enable = true, I cannot see the 0x0A in the NI Spy.

Actually, I use a driver for this instrument, but as it is a very complex instrument, if I want to modify the driver, I have to modify hunderds of vi's which I would like to avoid if possible.

Thanks for your help.

 

Best regards,

0 Kudos
Message 5 of 10
(10,288 Views)

Or you could replace all these visa writes with a vi with the same connector that does this operation.

Replacing a vi (or function) is just a few mouse clicks, and you learn to modularise your code just as Dennis mentions.

greetings from the Netherlands
0 Kudos
Message 6 of 10
(10,286 Views)
Here's a modifed VISA Write like Albert was talking about.
Message 7 of 10
(10,281 Views)

Thanks a lot for your help.

For my understanding, what is the END character in the 488.2 standard ?

0 Kudos
Message 8 of 10
(10,276 Views)
Solution
Accepted by topic author ced09
The 'end' is defined in 488.2 as EOI which is actually one of the control lines. That is why the help information is a little confusing to me. I know that with the GPIB functions you can optionally add a LF or CR to the EOI and it is also something that can be set in MAX when you configure a GPIB board. I believe the default would be no character and I looked for a VISA property that would do something similar but could not find anything specific to changing the 488 end character. I was hoping that the termination character was the same thing but I guess not. Hopefully, someone with some deeper insight into VISA will respond.
Message 9 of 10
(10,267 Views)
Good Day,
 
I am also in a similar situation here to ced09, I have a device currently working using the rs-232 serial protocol and wish to use a ethernut (http://www.ethernut.de/en/hardware/enut1/index.html) TCP/IP to Serial module so I can control the device over TCP/IP.
 
Ive got to a stage where I can send strings to the device by adding the "\n" ("0x0A" or "LF") on the end of the current commands and this works fine, however no matter how i set the "TermChar" or "TermChar En" it wont add the specified character after the command string! This looks like a bug to me. So in the end I used the VISA Write mod function from Dennis and that seemed to settle things nicely > regarding search n replace... is it possible to do it for a whole project and not just VI that is open including the daughtered VIs?
 
The main problem that I am now facing is the VISA Read function... The first time I run the test vi (see attached) it runs through fine and completes with no errors, however the second time round, the VISA Read returns a timeout error code BFFF0015 i think it was. Then on the third run if the software its ok again!?!? Works, Doesnt Work, Works, Dosent Work (like a RS FlipFlop!)
 
This tells me that something is not closing properly on the ethernut board. If I reset the ethernut, it works first time, but then not second. Its like there is something still in the buffers somewhere on the ethernut that are not being cleared properly after each session. Any Ideas?
 
I used NI-Spy & Wireshark (TCP/IP Packet Viewer) to capture data to see what was going down on the lower levels. NI-Spy showed the timeouts i was having and Wireshark also confirmed that data from a *IDN? command was being sent back over TCP/IP, but the VISA Read did not grab it and therefore it showed up as a timeout in the spy. I checked my timeout value and increased to no prevail.
 
Sometimes I send the *IDN? command and the device answers via serial to the ethernut, but the ethernut does not transmit it further over TCP/IP. Its gets stuck in the ethernut somehow??? But only on the second run. Im finding it hard to debug this beast and slowly running out of ideas. Any suggestions or replies are greatly welcomed...

:. LV2010 SP1 ... W7 .:
0 Kudos
Message 10 of 10
(9,831 Views)