Add endian-byte-swap to Call Library Function parameter options

[550nm]

I would like to suggest having a "reverse bytes" option for each parameter within the Call Library Function.

There would be both "Reverse Before call" and "Reverse After call" options.

As the CLF's purpose is to interface two [potentially] different environments, it seems the correct place for a translation to occur, if needed.

Cheers!

[Darin.K]

Actually I would be happy if the Byte/Word Swap functions were not the size of a house for a 1 in 1 out function.

[550nm]

Sorry, was this option added after LV2011SP1?

[Darin.K]

Sorry, was this option added after LV2011SP1?

No, I was simply lamenting the fact that the current method requires using those functions which are needlessly large for single input/output functions.  A few of them stack up quickly.  A smaller footprint would make the current solution (manually adding those functions) more palatable.

[AristosQueue (NI)]

550nm:

Unless I am sorely mistaken, the processor is what determines endianness for all computations on a machine. You can't have a DLL that has a different endianness than the EXE on the same machine ... none of the mathematical operations would work (other than the single-byte data types which are independent of endian). If you have a DLL that needs all the bytes flipped around, that's a pretty unique use case, one you should be coding yourself at the boundary. So, no, LV's Call Library Node does not seem like the place to be swapping endian-ness.

-- AQ

[Brian_Powell]

I would like to know more details about what you're doing with this DLL.

To expand a bit on AQ's post, it's not uncommon to need to swap endianness when your data is leaving the current machine and going over the network (or some other transport) to another device, which might prefer its data in a different format.  When you need to format your binary data for transmission over a network, you usually need to flatten the hierarchy of data.  That's why we put endian options in Flatten To and Unflatten From String, rather than put it in all of the functions that transport data (GPIB, VISA, TCP/IP, Network Streams, etc., etc., etc.)

One question I have is whether "Flatten" followed by the CLFN is able to encode the data correctly for this DLL.  If not, can you explain why not?  If it can, then are you just asking to optimize these two nodes into one?  (Or potentially three, if you have Flatten, CLFN, Unflatten.)  Because I agree with AQ on the unusual-ness of this use case, I'm reluctant to vote for it.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.