Dataflow Conflict appearing on the front panel

[Bombbooo]

Hello,

my vi is almost done but I still have a problem with the front panel. I think it's about data flow conflicts in my vi.

When you run my vi, you will see the pop-up window to ask you about putting a file path, adjusting the units, selecting data to save and plot. Then you might want to change the units, turn on-off all light and ok buttons to choose which data you want to save. Then click RUN.

The problem is; supposedly all buttons are on as default, if you turn off some saving or plotting buttons for not choosing to save, then click RUN, after that all buttons are on again even though you turned them off before running. They should stay off if you didn't select to save them. The condition of the main data stream always goes back to be the same before running (only light and ok buttons).

Do you have any ideas how to solve this problem?

Thank you in advance

[SteveChandler]

I'm not too sure but might get a better idea of what you are talking about if I could see the code. You attached your project file but not the files that make up the project. Put the whole thing in a zipfile and attach that.

[Bombbooo]

ok

[Bombbooo]

Sorry I don't have winzip at this moment

[SteveChandler]

What version of Windows? You should be able to right click a folder and select Send to/Compressed file. In any case I like 7-Zip

[Bombbooo]

Anyway you can easily download all files i have posted here. Probably next time i'll try to zip it

[Ben]

---

Bombbooo wrote:
Anyway you can easily download all files i have posted here. Probably next time i'll try to zip it

---

Plese keep in mind the people that are helping you are volunteers. It is a good idea to make their life as easy as possible.

Just trying to help,

Ben

[SimonH · Accepted solution]

You have what's called a race condition which commonly creeps into programs that use local variables.  If you look at your first while loop you read in the current "Main Data Steam" value from the control and store it in a shift register.  After the event structure exits you write the value from this shift register back into the control and in the process overwrite any changes the user may have made.

One quick and dirty solution would be to handle the Value Changed event for "Main Data Stream" in your event structure to update the shift register whenever the user changes values in the control.

A better solution would be to get rid of the shift registers and move the local variables into the event structure.  As long as the "lock front panel until event completes" option (I'm not sure of the exact wording and I'm working in LabVIEW Base at the moment so I can't check it) is selected it will ensure that you don't run into a race condition (you know the value can't change inbetween you reading in the value and you updating the control).

Better yet would be to avoid local variables wherever possible.  This is just general advice and not something I can make much more tangible without knowing the details of how you want your application to behave.

Hope this helps,

Simon

[Dennis_Knutson]

The use of locals has caused a race condition. The local going into the first while loop has everything enabled and when it exits the loop, it resets the control to be the same. Think DATAFLOW.

[Bombbooo]

@ Simon

Thank you very much. I tried to move the local inside the event structure. It worked. However I have to create too many data main stream's locals to wire in each event case. It looks a bit weird but it worked.

Thanks