"Type Cast" Memory Usage

[dpg1]

Hi Guys,

As you may remember from last week, I'm rewriting my LabVIEW program because it was badly coded (I have nobody to blame but myself).

Something I've noticed is that dozens of times in the BD, I put a constant "0" (EXT :S) into Type Cast, with the "type" unwired, so the output is a string. Is this using a significant amount of memory (this is done thousands of times a minute during program operation)? I can't find out what the cast value is - can any of you tell me what it would be as a string? I'd love to just be able to wire a constant into the VI I wire the cast value into.

Thanks in advance,

David

[jyang72211]

Do you just want to turn a number into a string?  If so, you can just use one of those number to string function.

yik

[Ben]

One of my old "G-Daddies" (Jay Grassle now a VP at NI) taught me years ago saying;

"Ben, if you don't know how a function works try 'ctrl-n' "

ctrl-n is the short-cut for create anew VI. For your case I would ctrl-a, ctrl-c, ctrl-n, ctrl-v.

In the new VIs diagram put an indicator on the output of the type cast adn run the VI. Look at the indicator to find the answer to the Q you posted. THen copy the control back to the original VI paste it and change it to a constant.

As to the academic question.

provide the output fits in the same memory as what you are type casting and the wire is not branching etc, the type cast just tells LV to "concider this wire to be of this type" so it could end being a "no-op" in the end.

Ben

[nathand]

---

Ben wrote:

provide the output fits in the same memory as what you are type casting and the wire is not branching etc, the type cast just tells LV to "concider this wire to be of this type" so it could end being a "no-op" in the end.

---

Key phrase here is "fits in the same memory."  LabVIEW stores text as Pascal strings with a 4-byte length preceding the actual data.  A typecast to a string must make a copy of the data in order to add the 4-byte length.  In the original poster's situation this is not using a significant amount of memory and not a problem, but it is worth taking into account if you're typecasting very large clusters or arrays into strings.  I expect that the string representation of an extended-precision 0 is simply 16 bytes (I think that's extended-precision) of 0's, but you could confirm by investigating how extended-precision numbers are stored, or as Ben suggested, put an indicator on the block diagram.  If you turn on the \ code display, it will probably look like "\00\00\00..."