Issue 1055

[CyGa]

The good news is we can reproduce the error :

We are working on fixing it !

[CyGa]

The bug is fixed and a new version (1.2.1.33) is available on VIPM : https://www.vipm.io/package/neosoft_technologies_inc_lib_testandifier/

[python007]

---

@CyGa wrote:

The bug is fixed and a new version (1.2.1.33) is available on VIPM : https://www.vipm.io/package/neosoft_technologies_inc_lib_testandifier/

---

Thanks for the fix now i'm "Ready to rock" 😉

[MichaelAivaliotis]

LabVIEW21 64bit (v1.2.1.33). I tried to use the tool on one cloneable module but always get the same error. I can send you the module privately if needed.

Error 56003 occurred at Invoke Node in DQMH_TestStandifier_Resources.lvlib:Insert VI into LVLIB.vi->DQMH_TestStandifier.lvlib:TestStandify State Machine.vi->DQMH_TestStandifier.lvlib:Main.vi

Possible reason(s):

LabVIEW: (Hex 0xDAC3) Adding this item would cause a conflict with another item.

Also, when an error occurs. The whole UI is disabled except for the "Open Manual" button. The only option is to restart the tool.

//Edit//

After posting this message I found the solution.

I have a habit of placing the API tester VI inside the module lvlib (right next to the main.vi). This causes the error above. Once I moved the tester outside the library, the tool worked without the error. I think the tool should detect this and not fail.

//Edit//

[CyGa]

Hi Michael,

Thanks for trying the tool !

All good feedback here ! We'll put that on the list of improvement !

And the behavior when an error is raised is clearly a bug, we'll fix that !

Just to clarify, the TSifier works on 'plain' DQMH modules. There are so many things a user can do with their modules (we've seen few astonsihing things) taht we bearly dropped trying to support all use cases !

That's why we added a validation step before TSifying the module. But adding the tester to the lib doesn't raise any issue in the validation process, so I guess we should catch this one and handle it properly !

PS: any plan making new episodes of VIShots ? 😉

[MichaelAivaliotis]

I tried following your instructions in the manual on how to add Teststandifier to the TestStand Tools menu, however the tool could not be launched. I got an error. I'm also attaching the TestStand error log (main.txt). It looks like many VIs are broken.

[CyGa]

The TS tool is actually just a sequence on top the TSifier LV Main.vi

I'm a bit surprised of the path that TS lists... 

Main VI was built using a LV 32-bit. Also it is set to have the compiled code outside of the source VI.

Is your TS set to use only the RTE and not the dev env ? If so, I guess the VI can't be recompiled and therefore the RTE says it cannot run it.

[MichaelAivaliotis]

I have an issue with the sequence wrappers created for the DQMH request VIs. If one of the inputs is an enum, then this does not get mapped correctly. It seems to be a bug. I've seen this on two different requests in my module. Both have enums as inputs. For example, see the image below. The enum value is placed in the error in location instead of the Enumeration input where it belongs. Further investigation indicates the enum parameter is not being created either. Does the Testandifier support enums in general?

[CyGa]

Hi Michael,

The TSifier only supports 'basic' datatypes.

Enum is not officially supported. But I definitely see the value of supporting, we'll actively work to add the support of enums.

Nevertheless, in the pic you sent the fact that the enum is listed in the error field seems a TS bug. TS looks at the parameter type, and then allows the user to enter an expression or displays a menu for enumeration value choice.
The fact the error is well seen as a container but lists the enum values of the above field seems more related to TS than to the TS-ifer itself.

NOTE: previous problems you discovered are now patched, we'll release a fix soon.

We also made tests with DQMH 7.0 and we fixed an issue related to it. So we can say that our next release will be DQMH 7.0 compliant.

[MichaelAivaliotis]

Thanks for the follow-up. I manually edited the output and fixed the issues. I also had to create a custom type to support this. I can see that the Testandifier needs to do a bit of work to support enums.🙂

I found another bug. If you have a module called (for example) Device.lvlib and it depends on a class called, Device.lvclass. Then the Testandifier build process fails with an error message. I think the other condition that needs to happen is that the request VI names match method names of the class. I fixed the issue by renaming my module. But it seems like the build process should fix this somehow or detect and warn the user. My guess is that it's a source distribution issue.