Jump to content

Bounded and fixed strings


Recommended Posts

I was fooling around with variants earlier by flattening them to strings, editing the bytes, and converting them back, then creating constants from them with scripting. By editing a string variant, I was able to make this:

post-15106-0-56676900-1341796139.png

This is a fixed-length string. If I right-click it, it gives me an option called "Set String Length", which isn't there on normal strings. It lets me set fixed, bounded, or variable (which changes it to a regular string and removes the menu option), as well as setting a length. I tried Googling it, and I couldn't find anything about it. I also can't find anything in LabVIEW's help files.

Can anyone from NI enlighten me as to what this is for? Is it some kind of hidden data type that's still being tested? I wouldn't find that hard to believe, considering the Set String Length dialog looks like it was quickly thrown together (no offense!) Is this used anywhere, and is there any way to create this other than hacking variants or VI files?

EDIT: Found how to do it:

preAllocateStringsUIEnabled=True
preAllocateUIEnabled=True
preAllocateEnabled=True

Then the aforementioned menu item will always appear.

Edited by flarn2006
Added INI keys
Link to comment

This is a fixed-length string. If I right-click it, it gives me an option called "Set String Length", which isn't there on normal strings. It lets me set fixed, bounded, or variable (which changes it to a regular string and removes the menu option), as well as setting a length. I tried Googling it, and I couldn't find anything about it. I also can't find anything in LabVIEW's help files.

It is in the help file if you know what you're looking for :)

http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/type_descriptors/

See section titled String, Path, and Picture Data Types.

Br, Mike

Link to comment
It is in the help file if you know what you're looking for :)

http://zone.ni.com/r...pe_descriptors/

See section titled String, Path, and Picture Data Types.

Br, Mike

Oh okay, thanks. That type descriptor thing will probably be useful when editing variants. But I'm still kind of disappointed that I didn't discover something that hadn't been released.

  • Like 1
Link to comment
  • 7 years later...

I'm trying to replicate this as it's tantalizing for dealing with serialized data from other apps...specifically I'm reading a struct into a cluster and in the middle of some other data there's a string/char array of length 20.

Currently I have to pull 20 characters from the string with string subset, but if I could make a cluster with a fixed width string I'm imagining casting the entire binary string into a cluster in one operation.

The screenshot in the OP looks like a snippet but I can't import it and it doesn't look like it has the necessary embedded information. Does anyone know how to create a string constant with the context menu option of "Set String Length?" The linked type descriptor page does not mention this concept, it only discusses standard strings.

Link to comment
On 5/13/2020 at 10:47 PM, avogadro839 said:

Does anyone know how to create a string constant with the context menu option of "Set String Length?"

I wouldn't recommend using this internal feature as it appears to be somewhat unstable. Doing a quick test I crashed LabVIEW a few times. But if you really want, you may call "Prealloc Length" (aka "PreallocLen") private property on a String control / indicator and after that "Set String Length" context menu entry is available with RMB click.

BTW, that thread about fixed/bounded arrays also belongs to here:

String_Len_BD.png.59cce5b11c93eedf6ddb774e1d0ccbd7.png

String_Len.vi

Edited by dadreamer
linked the similar thread
Link to comment
18 hours ago, avogadro839 said:

I'm trying to replicate this as it's tantalizing for dealing with serialized data from other apps...specifically I'm reading a struct into a cluster and in the middle of some other data there's a string/char array of length 20.

Currently I have to pull 20 characters from the string with string subset, but if I could make a cluster with a fixed width string I'm imagining casting the entire binary string into a cluster in one operation.

The screenshot in the OP looks like a snippet but I can't import it and it doesn't look like it has the necessary embedded information. Does anyone know how to create a string constant with the context menu option of "Set String Length?" The linked type descriptor page does not mention this concept, it only discusses standard strings.

Even if you make the string fixed size, LabVIEW most likely won't embed it into the cluster like a C compiler does. That simply was not a design criteria when fixed arrays (and strings) were implemented. They are mostly meant for FPGA, where variable sized elements have a very high overhead to be implemented. The fixed size option was documented at least since LabVIEW 3.0 in the data type documents and likely before but there was no public functionality to enable or access it and it only really got used with the introduction of FPGA support around LabVIEW 7.1.

Outside of FPGA targets it's not an exercised feature at all, and for strings it's nowhere really used. It is more a byproduct of Strings being in fact just a special type of arrays with its own wire color and datatype, but the underlaying implementation is basically simply an array of bytes.

Could LabVIEW inline fixed size arrays in Clusters? Sure! But that was initially never a design criteria. The support to interface to external libraries was added long after this datatype system was implemented, so changing that then to support C style fixed size arrays inside structs would have meant backwards incompatibility or a lot of extra work in the Call Library Node configuration. 

Edited by Rolf Kalbermatter
Link to comment
1 hour ago, Rolf Kalbermatter said:

They are mostly meant for FPGA, where variable sized elements have a very high overhead to be implemented.

could be valuable on rt if enforced. have to do this yourself with byte arrays and replace subset.

Edited by smithd
Link to comment
8 minutes ago, smithd said:

could be valuable on rt if enforced. have to do this yourself with byte arrays and replace subset.

They can be used in RT which can be useful when interfacing to FPGA code. However they are not meant to save you from having to use explicit array subset and similar functions. For one thing the normal functions like VISA/TCP/File and whatever Read do not support returning fixed size arrays at all. Second what would you expect functions like Append to String/Array to do with a fixed size input value? There's only a very limited subset of LabVIEW functions that can be meaningfully used with fixed size arrays/strings without creating a hell of a lot of possible implementation choices that are all valid in their specific use case.

Fixed size arrays/strings is a compile time decision. Most LabVIEW functions have a runtime operation however.

Edited by Rolf Kalbermatter
Link to comment

Thanks for the info, I was able to create a bounded-size string, and in addition to all the interesting errors mentioned, the unflatten from string VI does not work with this type.

Definitely an interesting topic, but it seems my hope to use these in practice is bunk.

Link to comment
16 hours ago, avogadro839 said:

Thanks for the info, I was able to create a bounded-size string, and in addition to all the interesting errors mentioned, the unflatten from string VI does not work with this type.

Definitely an interesting topic, but it seems my hope to use these in practice is bunk.

I'm fairly certain that it would work to unflatten a fixed size data string but only if the control in the data type to unflatten to is a preallocated data string with the correct size. Yes that limitation would not need to exist, but fixed size arrays/strings are anyhow an odditity in LabVIEW so why not enforcing such a rule.

At least that is what I remember from LabVIEW 5.x times.

Edited by Rolf Kalbermatter
Link to comment
On 7/9/2012 at 7:12 AM, flarn2006 said:

preAllocateUIEnabled=True

Did you know that this option shows "Autopreallocate arrays and strings" checkbox on VI Properties -> Execution tab?

2020-10-05_14-58-45.jpg.43efc9410611ac543d061f327a12426c.jpg

Here's the excerpt from the LabVIEW Help about this setting.

Quote

Autopreallocate arrays and strings(FPGA Module) Optimizes array and string operations. This option forces LabVIEW to preallocate memory at compile time rather than dynamically allocating memory at run time. By default, the FPGA Module displays this option for VIs under FPGA targets in the Project Explorer window. This option must be enabled before you can compile VIs that use arrays or strings for FPGA devices. LabVIEW disables the Autopreallocate arrays and strings option on installations of LabVIEW without the FPGA Module. If you create a VI in a version of LabVIEW that does not have the FPGA Module installed and you later target that VI to an FPGA device, you must explicitly place a checkmark in the Autopreallocate arrays and strings checkbox and test the behavior of the VI on the FPGA device to verify that it is operating as expected.

 

Link to comment
7 hours ago, dadreamer said:

Did you know that this option shows "Autopreallocate arrays and strings" checkbox on VI Properties -> Execution tab?

2020-10-05_14-58-45.jpg.43efc9410611ac543d061f327a12426c.jpg

Here's the excerpt from the LabVIEW Help about this setting.

 

Oh, no I didn't. I actually forgot that the fixed-length string UI was used for FPGA's.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.