LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Elegant way to embed a FP into a parent's FP

Hi.  Someone showed me a nice display that looks like;

 

pushkin_0-1633408687215.png

pushkin_2-1633410183873.png

Each of these is feed with a boolean and a string indicating the background colour and the text displayed (respectively).  Each is a cluster and is within an array of clusters.

 

The management of this is with a program like;

 

pushkin_1-1633409060136.png

 

My wish is to get the most elegant way to put the indicators into the controlling vi and in-turn have the FP of this vi embedded into the parent's FP.

 

Also, multiple locations may need to be used/displayed on the same FP.

 

PS; If it's all too hard then I will have to use variations of the above.

 

Regards JC.....

0 Kudos
Message 1 of 13
(1,110 Views)

Do you just want to have the same indicators in your main VI as in your subVI or do you actually want to have the entire front panel of subVI in your main VI?

 

If it's the first you can just copy indicators from subVI and paste them into your main VI.

0 Kudos
Message 2 of 13
(1,091 Views)

Have a look at this post of mine. Seems you want to do the same thing that was requested over there:

 

Sub Panels 

"Good judgment comes from experience; experience comes from bad judgment." Frederick Brooks
0 Kudos
Message 3 of 13
(1,071 Views)

Consider making an XControl (or a Y Control)

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 13
(1,048 Views)

@pushkin wrote:

Also, multiple locations may need to be used/displayed on the same FP.

.


This is not a VI, just a control that you can place anywhere on the front panel (multiple copies in the same front panel, in several VIs, etc. You need to make it a suitable type-definition so you can globally make changes if needed.

 

(Embedding a front panel as sub panel into another VI seems like a different topic, but please clarify your requirements in more details)

0 Kudos
Message 5 of 13
(1,029 Views)

Hi.  Thank you for your comments.

I check out Sub Panels of Dobrino.  This would do the trick (of being an embedded "object" from else where).  I presume that this technique would always treat the FP of the other VI as a simple whole unit. (?).

 

I am unsure about my initial wish.  However, a previous technique that I forgot about and have used is;

To use a reference to the FP indicator, and pass into a VI (along with the simple IO request).  This in turn updates the FP of the parent/calling VI.

 

PS: Are the any white papers that cover this aspect of LabVIEW and the use of references.

In C you learn about variables, pointers, structures and casting operations.  Your develop a intuitive understanding about how this relates to memory mapping.  LabVIEW seems to be devoid of any such material.

 

Regards JC......

0 Kudos
Message 6 of 13
(983 Views)

Hi pushkin,

 


@pushkin wrote:

In C you learn about variables, pointers, structures and casting operations.  Your develop a intuitive understanding about how this relates to memory mapping.  LabVIEW seems to be devoid of any such material.


Please try to avoid comparing LabVIEW to C! You should rather start from scratch when learning LabVIEW…

 

LabVIEW will take care of memory handling for you (most of the times), so no need to learn about "memory mapping".

Instead you need to get a "intuitive understanding" of THINK DATAFLOW! as that is the basic principle (aka mantra) of LabVIEW! There's a chapter in the LabVIEW help on this very topic…

Once you learned about DATAFLOW you also should have learned that a wire is a variable in LabVIEW.

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 7 of 13
(979 Views)

Hi GerdW.

I do not mean to upset anyone. 

With C we have a structured learning path (with many available text books).  I am not suggesting a 1 on 1 comparison.  LabVIEW seems to be a sea of endless icons available/configured with an endless sea on drop down boxes and dialogues.

 

Regards JC.....

0 Kudos
Message 8 of 13
(971 Views)

Hi pushkin,

 


@pushkin wrote:

I do not mean to upset anyone. 


Me neither.

I just pointed out the main difference between LabVIEW and usual text-based programming languages…

 


@pushkin wrote:

With C we have a structured learning path (with many available text books).  I am not suggesting a 1 on 1 comparison.  LabVIEW seems to be a sea of endless icons available/configured with an endless sea on drop down boxes and dialogues.


With LabVIEW you get all those Training resources as offered at the top of the LabVIEW board.

NI also provides learning courses! (There are also books on LabVIEW.)

 

Well, there's a lot of function (aka icons). But aren't there also a lot of functions in "endless seas" of C function libraries?

Most of the LabVIEW functions come with example VIs in the example finder!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 9 of 13
(969 Views)

@pushkin wrote:

Hi GerdW.

I do not mean to upset anyone. 

With C we have a structured learning path (with many available text books).  I am not suggesting a 1 on 1 comparison.  LabVIEW seems to be a sea of endless icons available/configured with an endless sea on drop down boxes and dialogues.

 

Regards JC.....


I've seen this one too many times. People that have worked "long enough" with text-based programming languages, in general, must go through an initial shock when trying to make the transition to LabVIEW (more often than not because for whatever reason they must). Several problems with that are:

 

1. LabVIEW is a much higher level programming language, i.e. it abstracts a lot more, which is nice if you know how those abstractions work, and a nightmare if you don't. It also means that LabVIEW unceremoniously will take a lot of control away from you, even if doing so quite politely.

2. LabVIEW "ticks" in a completely different manner as compared to say, C. First there is the Dataflow Paradigm, which means that stuff executes based on the availability of data, not position on the screen. Then it's completely graphical ("colorful little boxes and funny wires everywhere - is this a programming language at all?"). And then everything is inherently parallel, so parallel in fact that people struggle just make stuff serialized, just the way they are used to in text based programming. There are no classical variables, no pointers, there is funky stuff such as clusters, looping is somewhat different, and passing data around is anything but intuitive at the start.

3. Very little of your existing C knowledge will translate 1:1 over to LabVIEW. Which will be infuriating. Basically you need to start all over again. And this might take time (as in months), some people literally never suceed at making the transition.

 

Buy yourself a good LabVIEW book and read it through to get a "feel" of how LabVIEW ticks. At the time "LabVIEW for Everyone" was my Nr1 book to recommend. I'd bet even if outdated it will still let you understand the basics, i.e. learn to crawl and walk, and then try flying around.

"Good judgment comes from experience; experience comes from bad judgment." Frederick Brooks
0 Kudos
Message 10 of 13
(965 Views)