Serious Bug in NI Motion VI

[PJM_labview]

I discovered another serious bug in NI Motion (previously Flex Motion) driver.

This bug is present in NI Motion 6.x and 7.x (I was not able to check earlier version of NI Motion to see if they are affected by this, but they most likely all are)

The vi named "Find Reference.vi" located in the "Find Reference.llb" swap the wire between "board Id" and "axis or vector space" as seen below when an error is passed in.

The only suitable workaround is to not, use the pass-through values, or to modify the "Find Reference.vi" as seen below.

DOWNLOAD

If you are interested in obtaining this fix, I have created a patch which is packaged as an OpenG Package File. This can be downloaded using the OpenG Commander. Download the "ogpatch_ni_motion6x_bugfix-1.0-1." package for NI Motion 6.x or "ogpatch_ni_motion7x_bugfix-1.0-1." package for NI Motion 7.x. When installed this package will apply the patch, and when it is uninstalled it will restore the original (buggy) VI.

Please note that the "ogpatch_ni_motion6x_bugfix-1.0-1." package also include a bug fix for the 5 VIs mentioned in this post " FlexMotion Board and Axis Handles lost on Error".

DISCUSSION

If you would like to discuss this package or the OpenG Commander, please use the OpenG Discussion and Support Forums.

Regards,

PJM

[m3nth]

Nice. Someone was really paying attention on that one! Can't say I've never made that mistake before either--nice catch PJM.

[Michael Aivaliotis]

I discovered another serious bug in NI Motion (previously Flex Motion) driver.

Regards,

PJM

So, the moral of the story is... Provide a test harness to test all VI's before release.

A much simpler preventative measure would be to position the inputs and outputs at the same alignment. This way you don't have to think too much about wiring mistakes. Having them swapped like that is asking for problems.

Another thing in this example is the coercion dots. Correct connection removes coercion. The coercion in this case would raise a flag to the programmer. This is why I change the colour of my coercion dots to bright red instead of the dull grey.

[Jim Kring]

So, the moral of the story is... Provide a test harness to test all VI's before release.

Actually, I doubt that many of the FlexMotion VIs would pass inspection by VI Analyzer. Good style is so important. It isn't just to help people understand your code. It actually helps you write better code with fewer bugs.

[jpdrolet]

So, the moral of the story is... Provide a test harness to test all VI's before release.

A much simpler preventative measure would be to position the inputs and outputs at the same alignment. This way you don't have to think too much about wiring mistakes. Having them swapped like that is asking for problems.

Another thing in this example is the coercion dots. Correct connection removes coercion. The coercion in this case would raise a flag to the programmer. This is why I change the colour of my coercion dots to bright red instead of the dull grey.

Strict Typedef is also a good idea even if the data is simple integer. The coercion then does appear when different typedef are connected. For identifiers, uncoercible types are even better, like the datalog refnum used in GOOP implementations.