LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Add or change label and datatype. Numeric representation or string

In my application I often have to create a data structure which consists of several different datatypes.

ExampleExample

The way I create it is in a cluster with a numeric/string control.

1. Add new numeric/string control

2. Change the name of the label

3. Change the representation. 

This is done maybe 100 times and takes too long time and is impossible to make without errors

 

Is there a better smarter way?

From another Vi I have found a way to change the Label. But the numeric representation or string does not seem to be possible

I have the C++ header file

0 Kudos
Message 1 of 10
(1,993 Views)

This is all possible with VI Server\property nodes.

 

You probably have to turn on scripting (Tools>Options>VI Server) to get those properties.

 

You cannot change those properties in a VI that is running. So you need to either open a reference to a Vi that isn't running, or use scripting to create a new VI.

0 Kudos
Message 2 of 10
(1,980 Views)

Hey PR Kim,

 

Have you try the way provided by this link, it seem useful on changing the label:

https://stackoverflow.com/questions/47795038/how-to-batch-rename-the-labels-of-existing-labview-cont...

 

About the numeric representation, I normally set one of the numeric control with the particular representation that I wanted and crtl + c and v it.

0 Kudos
Message 3 of 10
(1,952 Views)

Thanks for the reply

I have looked at scripting as you suggested and found some examples that could be useful. More specific I have looked at "Creating New VI From Scratch.vi". I have never looked at scripting before but it looks pretty cool.

But I am not sure about how I can change the numeric representation of the control

Create new ViCreate new Vi

0 Kudos
Message 4 of 10
(1,934 Views)

If you have a numeric, the property should be there.

 

If it's not a numeric, you need to replace it with a numeric first.

 

A good rule with scripting is to settle for automating 95% of what you want. The other 5% will often take so much time, it's faster to all of it manually. Of course some tools need to work 100%.

 

Also, use as much premade code (including controls) as possible. It will be much easier to move a (duplicate of a) numeric into a cluster, than to change a string inside a cluster to a numeric. So, cheat...

 

If you tell us exactly what you want and how you want it, you can give you hints (even code) to get there.

 

This is not easy.

0 Kudos
Message 5 of 10
(1,907 Views)

Even without scripting, you could all but eliminate errors and probably drastically reduce creation time if you set up something like this on a block diagram somewhere (see spoiler). If, say, you want to add a new U16, just rename the U16 numeric constant, hold down CTRL, and drag it on in. When you're all done, you can right click the cluster and choose whatever autosizing you want.

 

You are using type defs where you are able to though, right?

 

Spoiler
FireFist-Redhawk_1-1599066929206.png

 

 

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 6 of 10
(1,900 Views)

As much as scripting sounds like the elegant and "correct" way to approach this, I'm pretty sure I'd end up doing something similar to what FireFist-Redhawk just illustrated.  Sure it's brute force and manual, but unless you're going to need to keep adding new data structure definitions every week or something, developing a scripting solution probably won't be an overall time saver.for a long time.  Especially if you aren't already quite experienced and knowledgeable in it.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 10
(1,891 Views)

A totally different approach is to avoid static types all together.

 

Store values in a config file, for instance.

 

On a side note... Last time I checked, I had 5 type defs in my application with 4k VIs. One was a small cluster, the other an enum.

 

All type def clusters can be replaced with a class, and this gets you a lot of benefits. Even without inheritance, encapsulation is really valuable once you get the taste of it.

 

If your application needs tons of type def clusters, those are probably objects, and OO would probably be worth exploring. You're already thinking in objects, so the benefits will probably become apparent pretty fast.

0 Kudos
Message 8 of 10
(1,857 Views)

Thanks for all the answers

I have done something like what Redhawk suggest for years. I was hoping that there could be a smarter solution.

We are right now i the development stage where I need to have the data structures right now but I also know that there will be changes to them in the coming month or maybe 2 month

0 Kudos
Message 9 of 10
(1,852 Views)

For me, data == class, data structures == class hierarchy... Well, almost.

 

Anyway, I think scripting could help, but without a very detailed requirement, any suggestion will miss the mark completely. Scripting is very tricky, and the tiniest change in requirement could need a completely different scripting approach.

 

There are several ways to integrate the scripting in LabVIEW. Right click menu plug ins, quick drop plug ins, provider framework, the normal menu... Or you can make a VI (as complex or low level as you want) to execute the script. But without knowing exactly what you want, it's hard so suggest anything.

0 Kudos
Message 10 of 10
(1,849 Views)