LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The missing History property in the waveform chart when using waveformchart control reference made more specific by generic control reference

Hi 

 

 

The question happened to me recently, I found a similar thread, but the solution seems not suitable for me.

https://forums.ni.com/t5/LabVIEW/clear-waveform-chart-using-an-explicit-non-strict-reference/td-p/54...

 

I made a sample to explain my question as clearly as I can.

First I have a simple VI, it has a function only to add an offset to the history values of the waveform chart.

20170518001.png

 

Since the program would grow largely one day, I'd like to make some modules or subVIs to optimize my code.

As a result, I merge all the control references into a cluster and make it to be a FGV, and then I can access any control property in a subVI(say "HistoryOffset2.vi") easily.

20170518002.png

 

However, the program would grow largely one day, the number of controls and indicators would be numerous.

I don't want to merge all the control references one by one by myself, so I try to get "AllControls[]" references, and try to find what reference I want by an action engine.

20170518003.png

 

Finally I got the problem...

I knew I could create a waveformchart(strict) constant by the waveform chart reference and connect the "target class" of the "More Specific to", it will work to get the History property, but I can't do it in the subVI.

Maybe the third method resulted from my stupid idea, however the most I'd like to know is how to access the control references among subVIs.

Is there any suggestion?

0 Kudos
Message 1 of 5
(3,069 Views)

The history property is still there but since it is not a strict reference we do not know the data type.

 

I would stick with the cluster form...

 

 

Spoiler
That GUI had about 600 controls and indicators. Designed by my customer and a novice developer to match a VBA application it replaced.

 

 

instead of the array since you can maintain you strict references and access the reference from the list of items in a type-defined cluster. That will also avoid look-ups to find the reference and issue with typos or name changes on the GUI requiring chasing down into sub-VI to find where it was used and adapt the constant to match the name in the top level VI.

 

Sticking with the array approach you will have to ad a strict reference that matches the chart so that you can cast the reference to the proper type in the sub-VI.

 

So choose your poison;

 

Bundle to maintain the strict type

OR

Keep the strict reference need for the casting in the sub-VI.

 

The former will break and warn you at development time. The latter will only show at run time.

 

So do you want the red pill or the blue pill?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 5
(3,030 Views)

Hi Ben,

 

Very thanks to your suggestion, is there no panacea to include all  the control references? Smiley LOL 

Actually I prefer the cluster form due to its convenience, but it occupies a lot of area in the block diagram and costs some effort to add the new reference in the future.

Is the idea to include all the control references not practical?

Is it better to make sure which controls & indicators should be accessed their property nodes and just to include the necessary control references in the beginning? 

0 Kudos
Message 3 of 5
(3,006 Views)

@William1225 wrote:

Hi Ben,

 

Very thanks to your suggestion, is there no panacea to include all  the control references? Smiley LOL 

Actually I prefer the cluster form due to its convenience, but it occupies a lot of area in the block diagram and costs some effort to add the new reference in the future.

Is the idea to include all the control references not practical?

Is it better to make sure which controls & indicators should be accessed their property nodes and just to include the necessary control references in the beginning? 


Look again closely at the image I included above. That image show one state of a state machine that included about 6 or more states that do nothing more than bundle up the 600 control references. The "Actual Code" resides in the last state of the sequencial state machine. I seldom look at the state that are doing the bundling. The code is no larger that what that image is showing you.

 

One of my co-worked wrote a special X-Control that automatically gather all of the controls and indicators of all visible controls and indicators when the mode changes to run mode. He can access any control reference by name using the services that X-control provides. But that code still needs the "cast to strict" support if accessing anything fancy or specific about a control.

 

It comes don to an aspect of LabVIEW that is almost magic. LabVIEW keeps track of the data types of wires that we string and takes care of the dirty little details needed to use different data types in LV. I Believe I read someone refereeing to it a "strictly typed wires". LV needs to be told what data type is in a wire. It is implied by the either the sink or the source of the wire most of the time.

 

Where that complicates your life...

 

Charts can be of many different types, floats, integers, Waveforms, etc. The type of data in the chart in turn indicates what type of data is in the history of the chart.

 

The generic reference of the chart does not know what type of data is in the chart. The Strict references includes that info.

 

So we are back to my "red pill vs blue pill" question.

 

If you combine the state machine to put the bundling in other seldom seen states, you ge the strictness you desire.

 

If putting together a cluster with all of the right names and reference types that is easily solved.

 

1) Collect the controls you want to reference.

1.png

 

2) select them and pop-up create references.

 

3.png

 

3) wire them all up to a bundle (not a bundle by name!) neatness does not count at this point!

 

8.png

 

 

4) Pop-up on the center terminal of the bundle and select "create constant".

 

9.png

5) pop-up and make the constant a type def. and views as an icon.

 

12.png

 

6) pop-up on the bundle and replace it with a bundle by name.

 

15.png

 

It probably took me longer to explain the process that it will take you to do it. Wire that cluster to any code that has to touch the GUI or to an Action Engine if you prefer.

 

Ben

 

 

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 4 of 5
(2,990 Views)

Don't forget that if you have lots of controls, you can do some hierarchical bundling.  So if you have a dozen controls relatively related, bundle them in a cluster.

 

If another 5 controls that are related, bundle them into a cluster.  Bundle the clusters into a cluster.  This allow you to do a Cluster2.ControlY type of unbundling when you need it.

 

Of course the complication there is with typedef clusters that contain other typedef clusters. a change on one cluster might drive the need to resave clusters higher up the chain.  But rather than having 1 cluster with a 100 controls.  You could have a cluster with 4 clusters of 25 controls.

Message 5 of 5
(2,984 Views)