How can i assign the value of a variable to another without updating the copy when the original is changed?

[AndreiV]

I want to save the value of a boolean that enters a flat sequence and gets updated as instructions are executed. The problem is that if i create a control at the entry point in the sequence, later on as the boolean changes, the control changes as well and they seem to always have the same value.

Can i somehow create a new variable that only holds the value at the entry point so i can compare it with the updated values?

Sorry if my explanations are not clear enough.

[GerdW]

Hi Andrei,

---

@AndreiV wrote:

Can i somehow create a new variable that only holds the value at the entry point so i can compare it with the updated values?

---

It seems you (still) need to learn to "THINK DATAFLOW!"…

In LabVIEW a "variable" is represented by a wire! So when you need a "new" variable you just need to use one more wire!

A control is "just" an input, an indicator is an output. And local variables are copies of their control/indicator…

Btw. thanks for your Kudo to my post here, but did you read what I wrote in there?

When you have problems with your code then you should attach your code!

[AndreiV]

---

@GerdW wrote:

When you have problems with your code then you should attach your code!

---

Thanks, i have added the code i need to update as example. `Entry Result` is a control created at the input point and used for comparisons later on. I will try creating a new wire and check the results as soon as the equipment is available. 

[GerdW]

Hi Andrei,

---

@AndreiV wrote:
i have added the code i need to update as example. `Entry Result` is a control created at the input point and used for comparisons later on. I will try creating a new wire and check the results as soon as the equipment is available. 

---

Yes, use one more wire from the beginning of that huge sequence.

(I don't see any "Entry Result" in your VI…)

I guess you already heard in your other thread you should:

• use less local variables!
• use less (aka no) sequence frames!
• try to implement the whole stuff as a statemachine…
• learn to use clusters to bundle related values, learn to use typedef'd clusters to (Un)Bundle by name…
• to summarize: learn to "THINK DATAFLOW!" ("DATAFLOW" has its own chapter in the LabVIEW help!)

There's a lot to do!

Small example:

Why do you needed 3 frames for this tiny code fragment?

[AndreiV]

Thanks for the feedback. Neither me nor my colleague are LabVIEW developers and our experience spans just a few months working on a project like this. We had to start development ASAP and applied our low-level software experience, namely mimicking the sequential order of execution that programs use. We both were strongly against using labview to the detriment of C/C++ or even Python, but had to give in and develop this whole mess that you saw attached. 

[GerdW]

Hi Andrei,

---

@AndreiV wrote:

Neither me nor my colleague are LabVIEW developers and our experience spans just a few months working on a project like this. We had to start development ASAP and applied our low-level software experience, namely mimicking the sequential order of execution that programs use.

---

Then you (and your colleague) should do you a favor and learn about "THINK DATAFLOW!" to correctly "mimick the sequential order of execution"!

At the top of the LabVIEW board you will find "Training resources" offered by NI. Try to stick with them (rather than looking at Youtube videos of more or less quality)!

[Bob_Schor]

This should never happen in a well-written LabVIEW routine, as the Prinicple of Data Flow would, if properly followed and "bad habits" (such as using Global Variables and using Local Variables instead of "Wires") were avoided.  A clue that your code is at fault is the mention of a "flat sequence" -- almost all (I'd guess 99%) LabVIEW routines (Top-level VIs and all sub-VIs) should never need, nor use, a Flat Sequence, but should always use the Error Line (and other wires) as a means to serialize code.

I notice you failed to post your code (actual VIs, no images, please).  Once you do, the problem should be glaringly obvious and will be explained in a Reply.

Bob Schor