Reading a 488.2-format binary block with MessageBasedSessionReader

[ljcorsa]

I'm using VB.NET in VS2005 with NI Meas Studio 8.1. I'm trying to take advantage of binary transfers to improve data throughput.  I am currently running with ASCII format using MessageBasedSession, and all is working.  When I switch to binary format (REAL64) using a MessageBasedSessionReader object, it does not seem to parse the binary data correctly. 

---

pna = CType(NationalInstruments.VisaNS.ResourceManager.GetLocalManager().Open(PNAaddr.Text), NationalInstruments.VisaNS.MessageBasedSession)
pna.TerminationCharacterEnabled = True
pna.Timeout = 4000

pnaReader = New NationalInstruments.VisaNS.MessageBasedSessionReader(CType(pna, NationalInstruments.VisaNS.MessageBasedSession))
pnaReader.BinaryEncoding = BinaryEncoding.DefiniteLengthBlockData
pnaReader.BinaryEncoding = BinaryEncoding.RawLittleEndian

' -- single sweep --
s = pna.Query(":SENSE:SWEEP:MODE HOLD; GROUPS:COUNT 1; :SENSE:SWEEP:MODE GROUPS; *OPC?" & vbCrLf)
' binary format
pna.Write(":FORMAT REAL,64; :FORMAT:BORDER NORMAL" & vbCrLf)
pna.Write(":CALC1: DATA? SDATA" & vbCrLf) ' added a space to keep : and D apart 😄
Sdata = pnaReader.ReadDoubles(Npts * 2)

---

I have tried several variations on SWAPPED/NORMAL, RawBigEndian vs little, etc. I get data arrays returned, but they do not resemble the values I get from the ASCII transfer, and sometimes I don't even get all the data (the array size ends up smaller than Npts*2).  Does anyone have a working example?

Thanks,
Larry

---

[Can_W]

Hey Larry,
The VISA functions in LabVIEW only accept strings as valid data types. In order to do a binary transfer, you will first have to convert your data into a string, send it, and then convert it back once you receive it. Since you said that you already have something similar to this, I'm not sure how much the following resource will help. The following KnowledgeBase talks about sending data via LabVIEW. Here is also a link to a previous discussion forum of someone trying to do something similar. In it they use VISA commands to send data, but still required data conversion before and after.\

Hope this helps

[ljcorsa]

Thanks Can, but I'm using Measurement Studio 8.1.1 with VB.Net, not Labview.

The Agilent folks helped sort out the byte ordering issues -- the PNA sends binblocks as Big-Endian, so that requires ":FORMAT:BORDER NORMAL" and vi.BinaryEncoding = BinaryEncoding.RawBigEndian.  I can now receive small sets of data correctly.  However, if I increase the number of points in the trace and the size of the data block gets larger (perhaps 1KB?), I start to get NaN appearing in the binary data.  I am using SOCKET I/O, and my suspicion is that the underlying code in the ReadDoubles() method is not handling packet fragmentation correctly.   I have not tried watching the data with a packet sniffer, but that will be investigated soon.

I have no problem transferring any amount of ASCII data using the ReadCommaDelimitedDoubles() method (the ASCII data would almost certainly be read byte-by-byte.)

Is there a more direct way of getting support than this forum that I should be using?  I'm running out of time to get an answer.

Regards,
Larry

[Can_W]

Hey Larry,
Sorry about the confusion. Glad to hear that you were able to get something to work. The NaN that you are getting appears because you're using the ReadDoubles() command, it has special bits reserved for sign, exponential and other items. If you can, you may want to try reading it as an unsigned long, which does not have those bits reserved. Since you are running out of time, I would advise you call in or email National Instruments. This can hopefully get you faster responses. The link to do that is on the main web page, or you can click this link.

Hope this helps

[ljcorsa]

Well, doing ASCII transfers is not exactly a workaround when handling lots of data.

The local Agilent SE sent a little console app for the PNA to use as a test.    When I substituted my instrument descriptor to try it out, it failed until I set TerminationCharacterEnabled = True.  Turns out to be a side effect of using ::SOCKET instead of ::INSTR.

I changed  the instrument descriptor in my code to use a USB-HPIB converter, turned OFF TerminationCharacterEnabled, and had immediate success.  I then switched to the PNA's internal LAN converter, ie, TCPIP0::host::gpib7,16::INSTR, and had my fix at last.

This all begs the question of what is wrong with ::SOCKET.  Apparently TerminationCharacterEnabled will need to be toggled around the binary transfers, and it was suggested by Agilent that I experiment with the buffer sizes.  I mention this here just in case someone else should stumble on this problem.  Here is a link to the thread in the Agilent forums where so much help was obtained:

http://forums.tm.agilent.com/phpBB2/viewtopic.php?t=1827&sid=a533bf695da82dbc27843f1262731481

Thanks,
Larry

[Myford]

I am doing something similar again with an Agilent instrument, but the data format is limited to Real, 32. Like Larry, I have tried various options like FORMAT:BORDER SWAP to turn the data around without much success. I suspect the issue is the MessageBasedSessionReader  ReadDoubles function only looks for 64 bit (double precision) and I am stuck with 32 bit and there is no ReadFloats.

I have considered using ReadInt32s, but C# refuses to convert between integer and floating point types. What have I missed?