Binary Read

[sorinxxxx]

Hi everybody

I read so many lines and topics about this BinaryRead that I wonder how could I not make it work properly.

Shrtly I have a LXI instrument that I used through TCPIP interface. The LXI instrument is called trough an IVI-COM driver that use NI-VISA COM.  

Sending SCPI getting back responses no problem. The problem start when I need to read back an IEEE Block from the VXI instrument. My driver is based on VISA-COM library and implemented few formatted interfaces As IFormattedIO488, IMessage but no ISerial as I don't need to use the serial interface. The binary response coming from the instrument is:  #41200ABCDABCDXXXXXXXXXX0AXXXXXXXXX that is made of 1200 bytes representing 300 float numbers.

To avoid catching the 0x0A termination character that is part of the binary stream I disable the termination character using the IMessage interface and setting TerminationCharacterEnabled = FALSE.

When I am reading the binary stream the ReadIEEEBlock is always stop reading at 0x0A character no matter what.

I read al over the places in this forum that to read binary streams properly from any instrument you need two settings not only one that I just mentioned.

The first I am able to control is about EnableTerminationCharacter to FALSE and is done. 

The scond one is about VI_ATTR_ASRL_END_IN attribute that could be set trough ISerial interface only and I could not access that interface from my IVI-COM driver.

As we don't plan to use the serial interface with our TCP/IP instruments what other options do I have to allow a full read of a binary stream of bytes even when an 0x0A is inside.

Our IVI-COM drivers are written in C++ and use NI-VISA version used is 4.4.1.

As a last resort I tried to change the Termination Character through IMessage interface to TerminationCharacter = 0x00 (NULL) but the ReadIEEEBlock always stops at 0x0A character???

The binary reading is done inside the IVI-COM driver and if successfull the full array of float data points is passed further to a potential client application inside a SAFEARRAY **pData object passed as a parameter to a public IVI-COM function. The problem is that I could not make the reading to pass beyond 0x0A character trough VISACOM interface.

Thanks

Sorin 

  

[yytseng]

TerminationCharacterEnabled is for TX only, will not effect to ReadIEEEBlock. The key property is EndIn for ReadIEEEBlock.

Here is a brief example for RS-232. FYI. 

 Dim idn() As String Dim sfc As VisaComLib.ISerial Set ioMgr = New VisaComLib.ResourceManager Set instrument = New VisaComLib.FormattedIO488 Set instrument.IO = ioMgr.Open("ASRL3::INSTR")  Set sfc = instrument.IO sfc.EndIn = ASRL_END_TERMCHAR idn = instrument.ReadList(VisaComLib.IEEEASCIIType.ASCIIType_BSTR, ",") ActiveSheet.Cells(1, 1) = idn(1) ActiveSheet.Cells(1, 2) = idn(2) ActiveSheet.Cells(1, 3) = idn(3)  instrument.WriteString ":TEST?" sfc.EndIn = ASRL_END_NONE ydata = instrument.ReadIEEEBlock(VisaComLib.IEEEBinaryType.BinaryType_UI1) sfc.EndIn = ASRL_END_TERMCHAR

If you turn on the NI Spy for checking, the ReadIEEEBlock will set this EndIn property to NONE before reading this kind of binary block data and reset to TERMCHAR on finished.

But, this feature only support GPIB/USBTMC/VXI-11.

Otherwise, RS-232, TCPIP Socket... you should do it by yourself.

As you said, this is an LXI(VXI-11) instrument. You should use the VXI-11 as the best choice.

FYI 

Using TCPIP Socket you have to do this trivial coding.

In my viewpoint, this gap is design for prevent the other programmer jump into "instrument control field".

[sorinxxxx]

Hi yytseng

I understood that I could use the ISerial interface to set the EndIn attribute to NONE but my driver did not implemented. The instrument resource is open with TCPIP0:10.13.38.184:INSTR3:INSTR resource name and the LXI module implemented on the instrument is based on VXI-11. The function ReadIEEEBlock is calling the NI VISACOM but is not automatically switching EndIn to NONE when binary reading is performed. Our LXI module is transparent to low level trasnsfer of bytes, their order etc. What is implemented in LXI module are the VXI-11 interface to open, close, event channel that high level functions not specific flags as EndIn. I guess the only option I have now at this stage is to find a way to retrieve the ISerial interface but since my resource name is not a serial but a TCPIP one I get "ISerial" interface is not implemented error. Setting EndIn to NONE from other place than a ISerial interface seems to be impossible now. Your example with RS232 is useful except I need to do that on TCPIP and that interface does not have EndIN option.

 Why VISACOM implementation of ReadIEEEBlock that calls read in sequence "#", then "4" for number of bytes, then "1200" as the total number of bytes to read does stop only after 506 bytes read when 0x0A is detected? As this is defined in VISA-COM standard the function ReadIEEEBlock should not stop at termination character but continue to read until the full number of bytes requested is read!

I will try to port your ISerial code into TCPIP interface and let you know how that go

Thanks

Sorin

[sorinxxxx]

My instrument has a TCPIP::IPADDRESS::INST3::INSTR resource name so is not a TCPIP SOCKET interface but a VXI11 instrument.

As the EndIN property does not exist on this type of interface the only option to prevent STOP a Read on 0x0A is to set TermCharEnable=FALSE. I do that but then who is taking care of checking TermCharEnable=FALSE flag is the VISA or the VXI11 instrument. I know that VISA read stops at 0x0A but the STOP is generated first by VXI11 instrument and then STOP signal is sent to VISA to STOP or is the VISA only that decides to STOP since it found an 0x0A character in the stream?

But If the VXI11 instrument initiates the Read STOP because it detected the 0x0A character without checking first the TermCharEnable=FALSE flag then the problem is inside the VXI instrument interface not in VISA read itself!

In this case my idea of solving the VISA read problem by focusing on VISA only w/o considering the VXI11 instrument in this process is totally wrong!

If VXI11 implementation is not properly done on the LXI instrument then the only way to solve this issue is only by fixing VXI instrument first then check again binary read call?

Btw I send the same command using an ASCII formatted response and of course stops at the same 0x0A character found at byte 441 of the 2000 bytes binary stream output.

Thanks

Sorin

[Online_Courses]

Message Edited by Online Courses on 04-26-2010 04:22 PM

[yytseng]

In case of RS-232, the VISA will decides to STOP since it found an 0x0A character in the stream. As I think, you may meet the same issue. But, there have no workaround for your situation.

As you said, it's obviously have an bug while using ReadIEEEblock with VXI-11.

You may post the testing results by NiSpy.

It may help NI to realize this bug.

[sorinxxxx · Accepted solution]

Hi yytseng

Yes I could confirm that the bug is coming from VXI-11 implementation on LXI instrument itself. Until reading Binary all previous responses were terminated by LF(0x0A) character that was the ending character on device_write function. The VXI-11 specification is very bad when talking about END indicator on device_write then talking about END indicator on device_read which is not necesarily the same for device_write and device_read. I talked to the guy that implemented VXI-11 module on LXI instrument and both have agreed to lack of clarity regarding termination character from write and read processed. In the end as our instrument for binary read use only the form #41200ABCDABCDXXXXXX format the only termination character to be set is TermCharEnabled=TRUE and TermChar=0x0A that could be done trough IMessage interface of the VISACOM interface.

So the problem was not inside the VISACOM but inside LXI VXI-11 instrument that was sending the response to VISA as soon as was detecting an 0x0A byte value inside the binary stream. Now after the change BinaryRead pass beyond 0x0A character but I end up in having trouble to read in one ReadIEEEBlock call huge amount of float data up to 100.000 points that means 400.000 bytes because the buffers used between LXI instrument and VISA are very small around 1 Kb only.

Anyway the solution to my original question was the improper implementaion of the VXI-11 instrument with respect to device_read termination character processing

Thanks for your help

Sorin