LabVIEW
use of FGV
You did not answer the question about who updates it. And when does it get updated? Regardless, you are not going to solve your race condition with a FGV. You need to better define your application and its architecture. You have a problem in the architecture.
- Control and indicator terminals should be outside the structures on the toplevel diagram (details)
- You could eliminate the while loop by using a feedback node instead.
- You should generate an error if a read is attempted before a write ever happened.
- The enum should be a type definition.
- There is no need to create a different output (empty string) in the write case. Just unconditionally return the number string. No need for branching and string diagram constants. Keep it simple!
- The FGV seems a bit simplistic. Are you adding more functionality later?
@Mrtechie wrote:
To avoid a race condition, we are moving for a FGV .
FGV's do NOT magically avoid race conditions. Proper program flow does!
If you blindly place this FGV where you currently have local or globals, nothing will improve. You will still have the same old race conditions, just more complicated code. 😮
Make sure you think this change all the way through! There might be more important things to improve. Do you currently have race conditions? How can you tell?
Just wire the terminal named "output" to the output of the right shift register and delete the wire branch and diagram constant in the write case.
If this is difficult for you please do a few more LabVIEW tutorials.
It is also very confusing that you shorten the modes to "MODEL NO WRITE" and "MODEL NO READ". the word "NO" could be understood as a negation ("no read" or "no write"), i.e. the exact opposite of the actual "read" and "write". Try to be unambiguous and as clear as possible.
You should also stick to standard connector panes. Also align the two string terminals horizontally for cleaner code.
Again, the FGV is NOT going to fix your race condition here. You have a condition where one loop is reading a value before another loop sets it. That is a race condition that cannot be solved by an Action Engine. This makes me question your architecture, which is what I was trying to lead the discussion to.
What are each of your parallel loops doing? Do they really need to be parallel? Why is the test setup running in parallel with everything else that needs that information before they go into a run state?
bhuvanesh1191 wrote:
so shall i add a another shift register in the program and make use of that . ?
The wonderful thing about programming is that there are many different ways to solve something. Another possibility would be to use a cluster of all values and use 3 modes (1) Read all (2) Write A, (3) Write B. Also make (1) the default, so you don't need to wire the mode when reading.
Why don't you try to program it in 3 different ways and pick the one you like best in the end?
Again, as Tim and me keep saying, the way you use all this will NOT cure any race conditions and is thus an exercise in futility. For example, why do you think you need to read the "test name" global twice in parallel? Are you expecting a different result each time? Typically you would read once and branch the wire. No need for pointless duplicate operations. There is nothing inherently wrong with global variables.
I don't understand why you would attach the exact same VI again. This is also a duplicate and pointless operation and just clutters the forum. I assume you accidentally attached the wrong file and have already implemented at least a subset of my earlier suggestions. Is this correct?
