G# and VI-Analyzer

[GabbyG]

Hi

We have a customer, that is somewhere located in the medical supply-chain. For them it means their products should (must?) be certified to  Quality assurance with GMP. For us a minimum will be that VI-Analyzer passes without too many errors.

With some 1500 VIs it won't be easy, for sure.

Unfortunately  also G# base classes give errors. Like missing ERROR cases for the whole VI or re-entrant VIs (like destroy) calling non-reentrant sub-VIs.

This is certainly not a problem in the design itself, it is rather bureaucratic.  Still it is a nuisance.

Has anybody else ran into similar problems.

And Matthias, will the next release maybe have some of the simpler issues resolved ?

The project is realized with LV 2013SP1 and G#  1.6.4 on Win 7

Gabi

[Mattias_Ericsson]

HI Gabi,

This is a tricky one. Actually strange that it gives error for missing ERROR cases, since this is actually designed by purpose in many of the G# VIs, in order to always perform correctly in case of an error. I need to discuss a bit with Thomas and Albert (the two other G# team members).

I let you know soon.

/Mattias

[Yamaeda]

Doesn't the analyzer warn if there's nothing connected to an error in? In that case we can add an error constant as input to avoid some.

/Y

[Mattias_Ericsson]

Hi,

I do believe error in is always connected, but there isn't always an error case structure. Since it should execute regardless of if there is an error or not. E.g. the Destroy method.

Mattias

[GabbyG]

Maybe the analyzer keeps quiet if you just pass on the error.

Gabi

[GabbyG]

Hi

Another issue with analyzer is how you handle empty controls in child classes.

I have several different types where a input of the parent is not needed. I left that simply open.

Now analyzer complains of exactly this. Even if I wire it to a dummy, i'm afraid the compiler (or annalyzer) is clever enough to detect that. How do you handle that ?

Thanks so far.

Gabi

[thols]

Anyway, it doesn't look good if the VI-analyzer complains. If it is a mark of quality to pass all VI-analyzer tests, then G# should pass all tests. We will need to have a look at this.

However, not having an error case in a VI can't be a very high ranked warning. I don't remember what the results look like, but there must be some kind of ranking of warnings, or some kind of points-system for warnings. The question here is how to evaluate "too many" errors from the VI analyzer. It would be easy to justify and comment any findings the VI-analyzer has on G#. I mean, it seems unecessary to rewrite code that works and where you can explain why the code looks like it does, when VI-analyzer complains. I guess you will need to do that anyway for some of the other VIs.

//Thomas

[Mattias_Ericsson]

Hi,

You don't happen to have a small example of the result log file? (I suppose it is), where we can what it complains about? I must admit that it been years since I last run the VI analyzer...

Mattias

[GabbyG]

God morgon

I placed a zipped file of a test result in the documents section.

When I open it I even see the sources, but that may be because there are path references in the file.

When you have downloaded the file, you or I will remove it. It's not terribly secret, but I'd like not to see it in a forum.

Thanks

Gabi

[Mattias_Ericsson]

Hi,

I had a look at the VI Analyzer result file and from what I can see there is typical two test that have a high rank, but I do think that the tests are not doing a good job. The two tests are:

1) Block Diagram->Warnings->Reentrant VI Issues

2) General->Icon and Connector Pane->Error Style

I've tested to disable these test on the more advanced G# examples that contains dependency injection and I didn't get any high rank warnings.

I really do think you need to disable these two tests. It might look like I am trying to avoid to deal with this, but I can assure you that the reeentrant issues of G# has been very carefully evaluated and tested. It is needed to have the reentrancy settings as it is in advanced scenarios and I do think the tests is too simple for analyzing this.The error issue is also very well tested and has to do with dealing with errors and I do think the test has a too simple approach regarding analyzing this in a general way. I don't see any easy way out of this, else by disabling the subtests.

Best regards,

Mattias