Is Labview handling automatically big endianness?

[Labview User]

I am working with a Labview Application that communicates through a serial line with another computer. I am using VISA subroutines.

My PC has an Intel processor which is Little Endian. I have read that Labview is Big Endian. My question is: Is Labview handling automatically the endianness of the processor or do I have to handle the conversion to Big endian myself?

I have also read that network communication is normally Big endian. Another question is: the data I send through the serial line will be Big endian (like Labview) or Little endian (like Intel processor) or it doesn't depend on them and handles itself the endianness of the data?

For the serial line I am using a RSR-232 bus.

Thanks very much!

[waldemar.hersacher]

LV does not handle any Little / Big endian conversions over VISA serial VIs and functions. These functions handle strings and are always treated as single bytes. Litte / Big Endian is only a question if you have a serial transmission with multibyte values.

In networking with TCP/IP you have a socket number. This is a 16 bit value so you have to define which byte to send first. This is defined by a RFC internet standard.

For your serial communication you have to implement the Litte / Big Endian conversion by yourself. This is true if you send the data in binary form.
If on both sides a LV application is running you can send your data by first convert it with flatten to string into a string, send it over your serial line and do an unflatten from strin
g. This may do a Litte / Big Endian conversion but I have that not testet, because I have no LV on MAC available.

Waldemar

[Scott Seidman]

"waldemar.hersacher" wrote in news:506500000005000000B82D0100-
1042324653000@exchange.ni.com:

> LV does not handle any Little / Big endian conversions over VISA
> serial VIs and functions. These functions handle strings and are
> always treated as single bytes. Litte / Big Endian is only a question
> if you have a serial transmission with multibyte values.
>
> In networking with TCP/IP you have a socket number. This is a 16 bit
> value so you have to define which byte to send first. This is defined
> by a RFC internet standard.
>
> For your serial communication you have to implement the Litte / Big
> Endian conversion by yourself. This is true if you send the data in
> binary form.
> If on both sides a LV application is running you can
send your data by
> first convert it with flatten to string into a string, send it over
> your serial line and do an unflatten from string. This may do a Litte
> / Big Endian conversion but I have that not testet, because I have no
> LV on MAC available.
>
> Waldemar

After all these years on multi-platforms, why doesn't labview add this
functionality to their read/write commands, as does Matlab??

Scott

[Labview User]

So, if I understood correctly, everytime I have a Labview program with VISA subroutines, I cannot abstract from the endianness and I have to program bearing it in mind.

Which means that I need to know the endianness of my PC, and then decide how I want to transmit the data through the serial line, right?

However, I am confused, because if Labview handles data in big endian, shouldn't it also be big endian the data I am sending through a serial line, when using VISA? Or does the serial line work with the endianness of the processor?

I am missing some more specific information at this matter in Labview documentation. I have found some attributes in VISA that are related to this, but I haven't found detailed information about them. They are SRC BY
TE ORDER, DEST BYTE ORDER and WIN BYTE ORDER. Have someone used them?

Thanks very much for your comments!

[waldemar.hersacher]

As you can see from the VISA Write and VISA Read functions they have String as input and output. And these functions are not polymorph so you can use only this type.
There are only two functions with which you can convert data to String. One is the "Byte Array to String" in the String >> String/Array/Path conversion palette. In this case the bytes must be already in the correct order. The other is the "Flatten to String" in the Advanced >> Data Manipulation palette.
Using this function you will get flattened data. This data is always in big endian form. This data will be converted correctly into the representation the machine has which runs the "Unflatten from string" function.

Think of sending a cluster of a I16 followed by a I32. The I16 has the value 0x0102 and the I32 has the value 0x11121314.
Using "Flatten to string" you get the data string containing 0x01 0x02 0x11 0x12 0x13 0x14. This is the Big endian representation. If you need the Litte endian representation you have to unbundle the cluster, split number and build array.
The VISA functions do not have any type information so they do not know which bytes/words to swap.
If you have the bookshelf installed go to Help>>Search the LabVIEW bookshelf >> Application Notes and white papers >> LabVIEW Data Storage to learn about the Flatten and Unflatten functions and how LabVIEW generates the data strings.

So connecting two LabVIEW applications with serial line and using flatten and unflatten you do not need to worry about endianness because these functions do this for you. If you connect a LabVIEW application together with a non LabVIEW application you have to provide the correct endianness by yourself if you do binary transfers. You can format your data into a string with the string functions and scan the string on the receiving part. This way you will transfer text and you do not have to worry about endianness because the format and scan function will do this for you.

The Byte order attributes are only valid in the VXI classes and are used for low level memory access of VXI devices. This is described in the NI-VISA programmers reference manual which is installed with your VISA.

Waldemar

[Noel]

To add to all your comments . . .
I just posted an example to DevZone which illustrates how to handle various binary code encoding schemes when communicating with instruments using VISA.

http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=C993A8A8911F19DDE034080020E74861&p_node=DZ52000&p_source=external
(just in case the link doesn't work, I'm also attaching the VI to this document)

The example uses the Tek oscilloscope, but is applicable with all instruments. The example works on all platforms that LabVIEW runs on -- therefore, it works on PCs (Win32 machines that are little Endian) as well as Macintoshes (big Endian). Basically, when communicating with instruments using LabVIEW, you do not need to worry about your host computer's
memory model. You just need to worry about the byte order of the data being sent from the instrument.

[Dan_Mondrik]

The VISA attributes related to byte order are for buses that allow multi-byte-wide data accesses in various formats, like VME/VXI. They are not applicable to Serial. Note that if you used the most appropriate class type (Serial Instr) you would not be exposed to attributes that don't apply. The generic Instr class lists all attributes for all interface types.

Every serial bus API, by the way, takes a data stream to transmit as an array of bytes. It assumes you have already formatted it in the endianness of your choosing. VISA does not make any abstractions above that. Note that any protocols specifying endianness over a serial bus are higher-layer protocols. So you have to be in control of that yourself.

Typically you have instrum
ent drivers that handle things like protocol specific data mangling, rather than that being down at the I/O layer itself.

Dan Mondrik
National Instruments