12-05-2016 10:25 PM
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!!!
This works as expected.
How can I write back to the cluster the new values? I will add error checking later!
12-06-2016 02:50 AM - edited 12-06-2016 02:50 AM
12-06-2016 06:29 AM
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.
12-06-2016 04:21 PM
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?
12-06-2016 04:50 PM
12-06-2016 04:57 PM - edited 12-06-2016 04:58 PM
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?
12-06-2016 05:44 PM
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...
12-06-2016 06:48 PM
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.
12-07-2016 06:34 AM
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.
12-07-2016 07:47 AM
@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