LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to change elements in a cluster from an event loop?

Hi,

 

I have a cluster wire that is a cluster (my typedef).  I want to change an element of the cluster when the user clicks a button.  How can I do this?  When they open a particular page on a tab control, some values are updated from the cluster which works OK.  When the user clicks save, I need to write these back to the cluster.

 

Is it possible to pass the cluster into the while loop by reference or similar?  I may have missed something obvious as my brain is burnt out right now!!!

 

Capture.PNG

This works as expected.

 

Capture2.PNG

How can I write back to the cluster the new values?  I will add error checking later!

0 Kudos
Message 1 of 11
(1,778 Views)

Hi ashesman,

 

general and VERY BASIC LabVIEW rule: use shift registers to keep values from one iteration of a loop to the next!

After implementing this rule you can use BundleByName…

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 2 of 11
(1,743 Views)

For a single loop, use Shift Registers.  If you need to share the data between loops, you might want to look into an Action Engine or a Data Value Reference.  There are other ways to explore as well, but it really depends on your architecture.  So more information is needed to make a better suggestion.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 11
(1,728 Views)

Perhaps I didn't explain it well.  This data is shared right through the program.  It was originally set at startup and then remained constant throughout the application so was wired to a lot of different places.

 

I now need to be able to change this cluster on the fly.  I am thinking that just using a local variable would be adequate as one already exists for display of it anyway.  It only ever needs to be written in this one VI, it is passed down to others but they should never be able to modify it.

 

Is that a bad idea?

 

0 Kudos
Message 4 of 11
(1,704 Views)

To answer your question: You have the cluster wire entering the Event Structure. Use Bundle by Name on the cluster wire to update the values and then wire the entire cluster to the local cluster variable.

 

But yes, I think this is bad practise...

0 Kudos
Message 5 of 11
(1,699 Views)

Thanks for your feedback.  It is now changed to the picture belo as I need to get on with it.

 

What would be considered the best practice for this situation?  I did actually discover one point where this cluster is passed to a sub VI once at startup that never returns to the main VI so can not ever see the updated settings.  So, I may need a better solution!

 

A reference to the original cluster would be ideal!  In conventional programming  a "const reference" would be passed into a called function so it could always read a structure but not write to it.  Is there anything like that in LV?

 Capture.PNG

0 Kudos
Message 6 of 11
(1,696 Views)

I now have the problem where order of reading/writing from the cluster (plant config) is a problem on other parts of the diagram!  I kind of expected this would happen by taking a wired signal and using local variables instead.  I am not exactly sure how to solve this problem given the current structure of the program I have been given.

 

It has four parallel while loops and a fifth running in a sub VI (apparently so it can run as high priority).  All of these loops need to have their internal value of the plant config read each iteration so they can use up to date settings.  At startup reading from an xml file needs to init these settings before anything uses them.

 

There is no structure in the program to control the order of execution at startup...

0 Kudos
Message 7 of 11
(1,684 Views)

Generally, you shouldn't have problems using local variables if you control the writing/updating of it to a single location.  If you suddenly find yourself needing to update in more than one location, you run into problems with a possible race condition.  The data written at one location is overwritten by the other.

 

You should consider using a functional global variable to store the configuration data.  A subVI that updates the values and returns them when needed.  It would allow you to access the data in multiple locations and even within subVI's.  Of course wiithout wires, you may need to use other wires  or methods to make sure the FGV is written to before the first time it is read.

 

Action Engine Nugget

Message 8 of 11
(1,677 Views)

Could you share more of your code?  I am specifically looking to see how the other loops are structured.  Something I often do is use Queues and/or User Events to send value updates to multiple loops.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 11
(1,665 Views)

@ashesman1 wrote:

I now have the problem where order of reading/writing from the cluster (plant config) is a problem on other parts of the diagram! ...

 

There is no structure in the program to control the order of execution at startup...


Please read teh Nugget linked by Ravens fan about Action Engines.

 

They act like they are protected section with the data stored in a static local which can only be accessed from the code of the Action Engine. They can be written to meeet your needs and provided yo do all of the "read-modify-write" functions INSIDE the Action Engine, they will prevent race conditions.

 

Generally:

I like to emphesize the importance of thinking about;

A) What is your data?

B) Where is your data?

C) What gets done to the data?

 

when coding in LabVIEW. When it comes down to the basics, our LV code is used to touch and influence the data structures we use in LV.  Action Engines can handle the "where is my data" and "What gets done to the data" part of our planning and can offer those operations to whatever codes needs to touch the data.

 

Done trying to sell the AE idea.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 10 of 11
(1,658 Views)