My subVI executes independently but not when called by a parent VI.

[BrownBrown]

Greetings,

I have a subVI which is called by a parent VI.  The subVI executes fine independently,  but when called by it's parent returns 0.00000.  I would appreciate it if someone with a little more experience could take a peek and tell me why I am having issues.  I have included 4 files:

(1) DARwire-Targets.VI               (This is the parent VI)

(2) DARwire-Range Target.VI      (This subVI that executes properly when called)

(3) DARwire-U to dP.VI               (This is the offending subVI.)

(4) range.dat                             (This is a text file that is read by DARwire-Range Target.VI to calculate velocity targets for a calibration.)

Some general notes:

1. You will want to change the path string in DARwire-Range Target.VI to match whatever directory you save these files in.

2. Typical inputs for DARwire-Targets are as follows:

      Step #:  30 thru 37 or 40 thru 73  (at any other Step # it should return all 0's.)

      Min Velocity: 30 kts

      Max Velocity: 150 kts

      Yaw Velocity:  120 kts  (this input is not used at the moment.)

      Atm Pressure: 30 inHg

      Atm Temp:  74 deg F

Thanks in advance!

-BrownBrown

[User002]

---

@BrownBrown wrote:

Greetings,

I have a subVI which is called by a parent VI.  The subVI executes fine independently,  but when called by it's parent returns 0.00000.  I would appreciate it if someone with a little more experience could take a peek and tell me why I am having issues.  I have included 4 files:

(1) DARwire-Targets.VI               (This is the parent VI)

(2) DARwire-Range Target.VI      (This subVI that executes properly when called)

(3) DARwire-U to dP.VI               (This is the offending subVI.)

(4) range.dat                             (This is a text file that is read by DARwire-Range Target.VI to calculate velocity targets for a calibration.)

Some general notes:

1. You will want to change the path string in DARwire-Range Target.VI to match whatever directory you save these files in.

2. Typical inputs for DARwire-Targets are as follows:

      Step #:  30 thru 37 or 40 thru 73  (at any other Step # it should return all 0's.)

      Min Velocity: 30 kts

      Max Velocity: 150 kts

      Yaw Velocity:  120 kts  (this input is not used at the moment.)

      Atm Pressure: 30 inHg

      Atm Temp:  74 deg F

Thanks in advance!

-BrownBrown

---

You have a lot of case structures that does not call the VI.

Use the "Execution Highlight" button to see how the dataflow goes in your top-level VI.

http://www.youtube.com/watch?v=oT6PLvpfpxE

Br,

/Roger

[Yamaeda]

If i interpret correctly you can combine all the cases to 1 case structure, just add cases and place the number limits in the requirements and it'll be alot easier to read and error check.

As Roger said, Highlight execution and Retain Values will show what's wrong.

/Y

[crossrulz]

This could be a classic problem of comparing equals with floating point numbers.  Floating points are not that exact.  Every language has this issue.  Check out the In Range and Coerce function in the comparison palette.

Are you only dealing with integer numbers?  If so, change the doubles into I32.

You can likely combine a most of your case structures into a single case structure using the range capability.  You can wire the number directly into the selection terminal and have, for example, "31..35" to for a case for all numbers between 31 and 35 (the ".." is the range specifier).

[crossrulz]

I took the liberty of updating your main VI using a single case structure.  I also changed the step number to an integer.  See if this helps.

[BrownBrown · Accepted solution]

I was not aware that you could add additional cases to a case structure, for some reason I thought the were only T/F.  That is useful and will certainly help me clean up my code but did not solve my problem.  Even crossrulz rewrite still returned 0's from the U to dP subVI.

The highlight execution did help me to deduce what was going on.  When I ran the code using this option I noticed that the values getting passed from the Atm. Press. and Atm. Temp. controls into U to dP were both 0.  Apparently I had accidentally defined these as Text Rings not Numeric Controls.  After making the switch things work as expected.

Thanks to all who offered input.  Kudos all around.