LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Case Statements or While Loop

Hi guys,

 

I need some advice on what is the best approach.

 

I am modifying a current Labview program (the same VI just renamed) to take advantage of two readings from a Force Gauge. My requirements are:

 

  1. Take the first dip in the force gauge. This will be the first reading and it's distance.
  2. Find the next rise in force
  3. Take the next dip and place this as the second reading along where the distance occurs.

I have four fields: 1st Peak Force, 1st Distance, 2nd Peak Force, 2nd Distance.

 

Do I use multiple case statements, a while loop, or something else?

 

I've enclosed my VI. I know, there are a lot of local references in here Smiley Sad, but I've got a short time frame and I'll have to rewrite this later.

0 Kudos
Message 1 of 13
(3,940 Views)

By the way, it's #23 in the case structure.

0 Kudos
Message 2 of 13
(3,938 Views)

Could you reduce the problem to a simple VI with an array of typical test data?

 

 

(btw, all these "read local variable-modify-write to the same local variable" constructs should be done with shift registers instead of locals of hidden controls/indicators. If you keep the data in a shift register, you don't need to involve the front panel. This is not text based programming 😉 Overall, the code is very hard to read. There is also something wrong with your state enum, because it gets coerced to a simple number. Most likely you are mixing different enums. You should have made it a type def. )

Message 3 of 13
(3,920 Views)

Sounds like you might want to look into the peak finding vi's.  Search the examples for "peak"

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 4 of 13
(3,911 Views)

 


@altenbach wrote:

Most likely you are mixing different enums. You should have made it a type def. )


In case "10", the two enums with selection "User Input (Start Button)" have an extra item "Read Gauge (R.T.C.)", replace those with the more common enum and things will look much better. Make it a type def to keep things manageable.

 

Message 5 of 13
(3,905 Views)

Thank you so much! That would have taken me hours to find out.

0 Kudos
Message 6 of 13
(3,897 Views)

You can reduce the complexity of your timestamp code:

 

23972iA2990533C6E225E6

- tbob

Inventor of the WORM Global
0 Kudos
Message 7 of 13
(3,885 Views)

tbob, won't I still need the date/time vi wired into the format date/time string?

0 Kudos
Message 8 of 13
(3,865 Views)

 


@BadAzzS10 wrote:

tbob, won't I still need the date/time vi wired into the format date/time string?


 

No, that's an implicit input, it per default uses the current timestamp, you can always use another moment in time.

 

If you are looking for information of a typedef, see this video.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 9 of 13
(3,853 Views)

I don't think the Peak Reading VI will work. I need to read the force of the gauge and at what distance it was taken at. I don't think that the Peak Finding VI will do that (although my knowledge level is very low with labview).

0 Kudos
Message 10 of 13
(3,842 Views)