Need help completing this VI

[concacid]

Hi,

I'm a newcomer in programming. Can someone please help me complete the code I have attached? I am trying to make sure they run sequentially with the instruction displayed in each sequence.

I have a few problems:

I need the user to be able to press continue after after carrying out any instruction

I want to be able to average a value after a certain time

I want to be the values to for mv4 and mv7 to always remain as the last detected value even when tif VI is restarted. e.g if I calibrate and mv4=9, i want this value to be set as the default stay until I recalibrate again, even if I restart the VI...then the new values become the default. 

Could anyone please help? This code is almost complete and all I need is just to complete it. Been working on it all day and time is running out.

KINDLY HELPPP!

Thanks

[altenbach]

---

@concacid wrote:

This code is almost complete and all I need is just to complete it. Been working on it all day and time is running out.

---

Who would give a LabVIEW beginner such a project to complete in a single day? It will take you longer just to learn LabVIEW!

I think the existing code is nowhere near completion and would need a lot of work. It might be better to start over from scratch. I think you should step away from it and learn about state machine architecture. Look at the included design templates and example programs. The code will suddenly fit on a normal screen! 😄

• Your front panel is not even recognizable as a user interface. All controls are scattered randomly without description. Nobody would be able to operate that thing. Arrange controls and indicators logically and in a natural order.
• Why is there no outer loop? Are you using continuous run?
• Your block diagram is full of race conditions and weird constructs. You have several "single iteration" while loops that delay the entire code by 10 seconds. Makes no sense.
• Converting a scalar to an array with a single element, then taking the mean of that will most likely not give you anything interesting that you don't know already.
• You have a race condition in frame #3, for example. The two local variables of a and b will most likely be read way before their terminals higher up are updated with the new value. This means that the lower part of the frame will operate on stale values.
• Why are most of your terminals not even connected to the code? It is typically a bad idea to do everything via local variables.
• Your use of numeric representations seems to be completely random.

I think you are a text programmer and basically tried to do a literal translation into LabVIEW, using local variables a variables and disregarding all dataflow considerations. You should really do a few tutorials before continuing. Good luck!

[Zwired1]

Please look into taking the LV Core 1 and 2 classes -- they may be available to you online through the license you already have (search for "Self Paced Online Training").  There are many, many issues with the way this code is written.  I can list them if you like, but you're better off getting the whole Kool-aid from an NI instructor than trying to address it piecemeal through a forum post.  

That being said, I can tell you've put a lot of effort into this and it sounds like your'e in a time crunch so I'll try to help.  

The issue with the continue button -- I think what's going on is that the first time you use the "Continue" local variable it gets set to "True" and stops the first While loop.  The second While loop starts immediately after, while "Continue" is still True and the second While loop only runs once.  Does this agree with your symptoms?  To combat this, and this is not a preferred method, I put an additional state in between the while loops and set "Continue" to "False" before the second While starts.  

The issue with saving defaults -- I added a couple states to the end of your flat sequence and used property nodes to set the default values of the controls to whatever the values are at the end of the sequence.  I then caused the VI to be programmatically saved (using an invoke node) so the default values would "stick" without the user having to remember to save.  This is the way to do it, thought I'm not sure if I exactly implemented the actions you wanted. 

The issue averaging after a certain time -- could you please be more specific?  

I hit <ctrl>+U (block diagram cleanup tool) on your code.  The content should be the same, though the arrangement has changed.  Sorry, I know it's a pain seomtimes when you're used to looking at it a certain way and it changes. 

[altenbach]

---

@Zwired1 wrote:

The issue with saving defaults -- ... I then caused the VI to be programmatically saved (using an invoke node) so the default values would "stick" without the user having to remember to save.  This is the way to do it, thought I'm not sure if I exactly implemented the actions you wanted. 

---

No, this will not work. The "DefVal" property can only be written when the VI is is edit mode. (needs to be used from a separate VI, scripting!).

---

Zwired1 wrote:

The issue with the continue button ...

---

The right way is to make it latch action. Once you have a state machine, only the terminal is needed, no local varaibles.

You seem to only want to keep values between runs, and not between saves. The easiest way is to keep the values in a shift register. If you want to keep values between new  program loads from disk, you need to implement a configuration file, for example.

Averaging over time requires reading values repeatedly and accumulating them in a shift register or autoindexing output terminal.

[concacid]

Thank you Zwired.

I know my code is really bad and yes I actually put in a lot of work into it. Thank you for trying to help. I'm very far from being the expert that you aare and like I said I have just started learning labview. 

Regarding your question on the average, I wanted to take an average after 10s because the values will flunctuate for initially. When the user clicks continue, I hope it will then calculate the average and display the vlaue, and continue.

I am able to read the Ctrl+U. Thank you

[concacid]

Thank you.

I am still taking labview tutorials 🙂 I didnt feel it was such a complex thing to do. I used local variables because I didnt want to cluster the page...I know my code is probably 10% and thats why I needed help. I was going to clean up the front panel. I wanted to be sure of what I was doing before doing that.

I will look into your suggestions. Thank you for the review.

Regards

---

@altenbach wrote:

---

@concacid wrote:

This code is almost complete and all I need is just to complete it. Been working on it all day and time is running out.

---

Who would give a LabVIEW beginner such a project to complete in a single day? It will take you longer just to learn LabVIEW!

I think the existing code is nowhere near completion and would need a lot of work. It might be better to start over from scratch. I think you should step away from it and learn about state machine architecture. Look at the included design templates and example programs. The code will suddenly fit on a normal screen! 😄

• Your front panel is not even recognizable as a user interface. All controls are scattered randomly without description. Nobody would be able to operate that thing. Arrange controls and indicators logically and in a natural order.
• Why is there no outer loop? Are you using continuous run?
• Your block diagram is full of race conditions and weird constructs. You have several "single iteration" while loops that delay the entire code by 10 seconds. Makes no sense.
• Converting a scalar to an array with a single element, then taking the mean of that will most likely not give you anything interesting that you don't know already.
• You have a race condition in frame #3, for example. The two local variables of a and b will most likely be read way before their terminals higher up are updated with the new value. This means that the lower part of the frame will operate on stale values.
• Why are most of your terminals not even connected to the code? It is typically a bad idea to do everything via local variables.
• Your use of numeric representations seems to be completely random.

I think you are a text programmer and basically tried to do a literal translation into LabVIEW, using local variables a variables and disregarding all dataflow considerations. You should really do a few tutorials before continuing. Good luck!

---

[altenbach]

---

@concacid wrote:

I used local variables because I didnt want to cluster the page...

---

I have no idea what that means: "Cluster a page"??? 😄

What do local variables have to do with clusters? What "page"?

[concacid]

---

@altenbach wrote:

---

I have no idea what that means: "Cluster a page"??? 😄

What do local variables have to do with clusters? What "page"?

---

😄 You could be more sarcastic you know? I meant the block diagram...having wires everywhere. 

You can pass for an instructor too..:) Only if you would show a more concrete example in a VI. We all have different ways of learning...

I'm sure I'll improve, then you can stop laughing at me..lol

Regards

[altenbach]

A cluster has a very special meaning in LabVIEW, thus my confusion. There was no intention for comedy. 😉

Again, if you use a reasonable state machine architecture, the wires won't be very long and help clarify the flow of data. Using local variables make the code much less clear, because execution order is not predictable and it is very difficult to tell where data is coming from and where it is going, leading to race conditions as we have already seen.

Also, a pile of local variables uses much more ink than a few wires. 😉

[concacid]

Thanks!

---

@altenbach wrote:

A cluster has a very special meaning in LabVIEW, thus my confusion. There was no intention for comedy. 😉

Again, if you use a reasonable state machine architecture, the wires won't be very long and help clarify the flow of data. Using local variables make the code much less clear, because execution order is not predictable and it is very difficult to tell where data is coming from and where it is going, leading to race conditions as we have already seen.

Also, a pile of local variables uses much more ink than a few wires. 😉

---