From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

VI Analyzer Enthusiasts Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Path constant usage test

Solved!
Go to solution

Dear all,

 

let me, please, ask you for the feedback for my first VI Analyzer test.

The test checks usage of path constants on block diagram (I believe that sometimes it can cause issues because of hard-coded paths), and if path constant is not empty, then it drops a failure.

It's quite trivial and simple, but anyway, does it make sense to extend it (for example, search also not valid path values, etc.), or it will not be useful anyway?

 

Thanks a lot in advance,

 

Sincerely, kosist90.

0 Kudos
Message 1 of 8
(4,783 Views)
Solution
Accepted by topic author kosist90

Here is my feedback on the test:

 

  • Expand the array constant in the RD VI to show one empty element, so it is obvious that there are no elements in the array beyond the first one. Also delete the free label on the panel of the RD VI.
  • Delete the decoration and the free label on the panel of the Config VI. 
  • I would rename the test to 'Path Constant Usage'...no need for the words to be pushed together with CamelCasing. You can use this tool to rename your test.
  • There are a few wires under objects and unnecessary wire bends in your test VI diagram.
  • Hide the unused subdiagram label on the For Loop.
  • Remove the Diagram Disable Structure...there's no need for it since the code already properly handles using the debug controls.
  • Replace the empty Path Constant wired to the Variant to Data function with an 'Empty Path Constant' to improve readability.
  • I think the code should check the path value to see if it is relative...a relative path in a path constant should not cause a failure for this test. You can use the Path to Array of Strings function to check a path to see if it is relative.
  • I also think the test shouldn't return a failure if the path is 'Not A Path'.
  • Remove the Clear Errors VI call...if the test returns an error, you need to report it. If there is a known error condition that the test can generate, you should clear that known error condition.
  • The test should probably check the value of an array of Path Constants as well.
Message 2 of 8
(4,761 Views)

Thanks a lot, Darren, for reviewing the test!

 

Such a little of code, and so many points to fix Smiley Happy

0 Kudos
Message 3 of 8
(4,758 Views)

Dear Darren,

 

I've updated code according to your comments. Also checked by VI Analyzer for wire bends, etc. on the block diagram; seems that it passed.

Now it checks also array of path constants. Also, as you've suggested, if path is empty, not a path or relative path - test does not fail.

 

Could it be like that now, please?

 

Thanks a lot in advance,

 

sincerely, kosist90.

0 Kudos
Message 4 of 8
(4,750 Views)

The improvements look good. I have some additional feedback:

  • You need to update the test description (the VI description of the Config VI) to mention the new functionality (empty path, not a path, and relative path are 'pass' conditions).
  • The error handling in the main VI had a few issues, and there was a bug in the logic for the For Loop that was parsing the path constant values. Here's how I would implement the test VI to fix those issues:
    1.png
  • Note that the For Loop has an error shift register instead of tunnels. You almost always want a shift register for errors on a For Loop. This allows your code to handle the zero-iteration case correctly, and it also allows you to report the first error that occurred, as opposed to just the error from the last iteration (which is what happens when you use error tunnels).
  • Notice that I also switched to a single failure message for both cases, here's the wording I used:
    "This constant contains an absolute path. Consider generating paths dynamically in your application. Path value: "%s""
Message 5 of 8
(4,738 Views)

Dear Darren,

 

thanks a lot!

 

I've updated it according to your corrections.

 

Thank you,

 

sincerely, kosist90.

0 Kudos
Message 6 of 8
(4,726 Views)

@Darren wrote:
  • Note that the For Loop has an error shift register instead of tunnels. You almost always want a shift register for errors on a For Loop. This allows your code to handle the zero-iteration case correctly, and it also allows you to report the first error that occurred, as opposed to just the error from the last iteration (which is what happens when you use error tunnels).

I've just realized - could it be also some VI Analyzer test, which would check, whether error wire goes by shift register inside the loops? Or there exists already such a test, please?

0 Kudos
Message 7 of 8
(4,705 Views)

@kosist90 wrote:

I've just realized - could it be also some VI Analyzer test, which would check, whether error wire goes by shift register inside the loops? Or there exists already such a test, please?


There will be a For Loop Error Handling test in VI Analyzer 2018 that checks for this situation.

0 Kudos
Message 8 of 8
(4,703 Views)