LabVIEW
typecast does not accept "All" types of data
pawel wrote:
> That was just an example. I was thinking about more advanced solusions,
> which actually involve LV only on one side, so the interface must be well
> defined and understandable for others as well.
The LabVIEW flattened bytestream format is very well defined and also
documented in the online documentation "Search the LabVIEW
Bookshelf->Application Notes and White Papers->LabVIEW Data Storage
Formats". It is the same format LabVIEW will generate when you wire any
datatype to the Write File function for instance.
It has been virtually consistent since LabVIEW 3.0 with one change only
between LabVIEW 4 and LabVIEW 5 where the Boolean was changed from a
16bit signed integer to a 8 bit unsigned integer.
A more well defined binary format is almost unthinkable and LabVIEW at
least supports it out of the box without the need for any bothering on
your part.
Rolf Kalbermatter
> That was just an example. I was thinking about more advanced solusions,
> which actually involve LV only on one side, so the interface must be well
> defined and understandable for others as well.
The LabVIEW flattened bytestream format is very well defined and also
documented in the online documentation "Search the LabVIEW
Bookshelf->Application Notes and White Papers->LabVIEW Data Storage
Formats". It is the same format LabVIEW will generate when you wire any
datatype to the Write File function for instance.
It has been virtually consistent since LabVIEW 3.0 with one change only
between LabVIEW 4 and LabVIEW 5 where the Boolean was changed from a
16bit signed integer to a 8 bit unsigned integer.
A more well defined binary format is almost unthinkable and LabVIEW at
least supports it out of the box without the need for any bothering on
your part.
Rolf Kalbermatter
pawel wrote:
> That is correct, but still you can recover the information
> if you know what to expect.
Well theoretically for one string or array indeed, but that is a very
cumbersome work. LabVIEW would have to parse the bytestream both from
beginning and end at the same time to get that information, a lot of
work to do for a Typecast which by definition is more or less a NOP at
runtime (LabVIEW does do some boundary checks on the string possibly
padding strings which are to short to be converted in the desired
datatype, but that is about it)! Also it is even more counterintuitive
that this function would work for clusters with one string but not for
clusters with two strings.
> E.g. your cluster can look like {U32, U32, String1, String2}, where
> you define that the first two U32 tels about the length of String1
> and String2. That would be propably most often meet during the network
> communication and some generic typedefs.
But that is exactly what "Flatten to String" is for!! With that, for
your hypothetical cluster with two strings you do not even need to fill
in any extra integers anywhere which you would have to fill in manually
as well. Flatten to string will simply create a bytestream for you in
the folliwing manner:
int32, string1, int32, string2
and the best of it all "Unflatten from String" will simply return this
back into a proper LabVIEW cluster again.
Rolf Kalbermatter
> That is correct, but still you can recover the information
> if you know what to expect.
Well theoretically for one string or array indeed, but that is a very
cumbersome work. LabVIEW would have to parse the bytestream both from
beginning and end at the same time to get that information, a lot of
work to do for a Typecast which by definition is more or less a NOP at
runtime (LabVIEW does do some boundary checks on the string possibly
padding strings which are to short to be converted in the desired
datatype, but that is about it)! Also it is even more counterintuitive
that this function would work for clusters with one string but not for
clusters with two strings.
> E.g. your cluster can look like {U32, U32, String1, String2}, where
> you define that the first two U32 tels about the length of String1
> and String2. That would be propably most often meet during the network
> communication and some generic typedefs.
But that is exactly what "Flatten to String" is for!! With that, for
your hypothetical cluster with two strings you do not even need to fill
in any extra integers anywhere which you would have to fill in manually
as well. Flatten to string will simply create a bytestream for you in
the folliwing manner:
int32, string1, int32, string2
and the best of it all "Unflatten from String" will simply return this
back into a proper LabVIEW cluster again.
Rolf Kalbermatter
pawel wrote:
> Hi Rolf<br><br>I think you are right under the condition that you
> have an influence on the interface to the other parties. Unfortunatelly
> I need to undergo some restrictions from another custommer and I have
> an interface strictly defined by them. There is nothing wrong with it,
> since I can accomplish their expectations, but I wanted to do it with
> a least trouble and effort :). <br><br>To do that I have found a typecast
> a little too "strict", shall I say. With a bit of more functionality I
> could make my task much easier and more LV-style. Now I need to do it
> more C-style, which I do not really care.
Hi Pawel
I see! The problem with this is that LabVIEW does not have anything
which can simply represent C style pointers. It is the strict typed
language definition which makes this possible but which is also the
reason that you do not really have to worry about memory allocation and
deallocation anywhere (well you do for performance reasons sometimes but
it is not strictly necessary in order to get a LabVIEW function to work).
For these situations the most simple solution is in fact to create an
interface DLL which translates between LabVIEW and your C interface.
The workaround would be to treat the embedded pointers as uInt32 as far
as LabVIEW is concerned and do some magic with MoveBlock calls as
explained in a different recent post of mine on those uInt32. But you
will find out soon that this is only practical for one or two functions
to do in this way. For more functions whith such parameters you will
inevitably find that starting up a C compiler and creating a DLL/shared
library project instead is a lot simpler, faster and less error prone.
Rolf Kalbermatter
> Hi Rolf<br><br>I think you are right under the condition that you
> have an influence on the interface to the other parties. Unfortunatelly
> I need to undergo some restrictions from another custommer and I have
> an interface strictly defined by them. There is nothing wrong with it,
> since I can accomplish their expectations, but I wanted to do it with
> a least trouble and effort :). <br><br>To do that I have found a typecast
> a little too "strict", shall I say. With a bit of more functionality I
> could make my task much easier and more LV-style. Now I need to do it
> more C-style, which I do not really care.
Hi Pawel
I see! The problem with this is that LabVIEW does not have anything
which can simply represent C style pointers. It is the strict typed
language definition which makes this possible but which is also the
reason that you do not really have to worry about memory allocation and
deallocation anywhere (well you do for performance reasons sometimes but
it is not strictly necessary in order to get a LabVIEW function to work).
For these situations the most simple solution is in fact to create an
interface DLL which translates between LabVIEW and your C interface.
The workaround would be to treat the embedded pointers as uInt32 as far
as LabVIEW is concerned and do some magic with MoveBlock calls as
explained in a different recent post of mine on those uInt32. But you
will find out soon that this is only practical for one or two functions
to do in this way. For more functions whith such parameters you will
inevitably find that starting up a C compiler and creating a DLL/shared
library project instead is a lot simpler, faster and less error prone.
Rolf Kalbermatter
