Support Forum: Neosoft DQMH TestStandifier

[CyGa]

Hi Micheal,

Yes enum are not so trivial in TS, we'll see if we find an easy solution.

But I definitely added it into our 'next features' board.

For the bug related to the lvlib vs lvclass name, do you have a print screen of that ?

Behind the scene we use the app builder, so anything that would let the app builder produce an error will happen in the TSifgier as well.

And there are numerous corner cases where it could heppen. That is why you can try different settings for the source distribution and ppl builds.

If you have a screen copy of the error (and maybe a module to send me), we can take a look and see if we need to build a patch / add more settings regarding SD/PPL building.

[MichaelAivaliotis]

When you modify the start module to allow a custom module ID, this allows the system to get in a conflicting situation. If you set "run as singleton" false and set a custom ID of 0, then this is an invalid state. If the intention was to run as a cloneable, then setting zero makes it singleton.

I don't know how to resolve this, but it makes for a confusing user experience. Perhaps if setting the "run as singleton" flag as false and then specifying a custom module ID as 0 should generate a runtime error with an explanation.

[MichaelAivaliotis]

If I wanted to automate this as part of my build process, how can I run the tool? Can I run some of the low level code, or is there an API? Also, is there a way to change the build output folder location?

[CyGa]

---

@MichaelAivaliotis wrote:

If I wanted to automate this as part of my build process, how can I run the tool? Can I run some of the low level code, or is there an API? Also, is there a way to change the build output folder location?

---

Hi Michael,

For the moment no API ! And no, for the moment it is not possible to change the destination directory.

Lets see what we can do for v2 ! ^^

[CyGa]

---

@MichaelAivaliotis wrote:

When you modify the start module to allow a custom module ID, this allows the system to get in a conflicting situation. If you set "run as singleton" false and set a custom ID of 0, then this is an invalid state. If the intention was to run as a cloneable, then setting zero makes it singleton.

I don't know how to resolve this, but it makes for a confusing user experience. Perhaps if setting the "run as singleton" flag as false and then specifying a custom module ID as 0 should generate a runtime error with an explanation.

---

The TSifier doesn't remove your responsabilty when using your DQMH module.

It gives you capability, and like any hero, big super power means big responsablities !

You should set your module ID correctly based on the inputs you give to the Start Module VI.

If you run your module as a singleton, use default DQMH numbering or set the module ID to 0 in TS.

If you run  your module as a cloneable, ensure that a module ID deosn't get used twice in TS.

When using cloneables in TS my advice is to usually set the moduleID MySocketIndex+1.

[MichaelAivaliotis]

I ran into an issue, and I was able to reproduce it in a sample project. Find attached the code to reproduce the issue. Basically, if your module calls any dependent class method VI that has a name identical to a DQMH request VI name. Then the source distribution step fails. In the example I have a class with a VI method called "Sample Request.vi". I also have a DQMH request with the same name.

Here's the error for the attached project:

Error 1357 occurred at Error copying files.
Source: C:\_Projects\SampleProject\Instrument Module\Sample Request.vi
Destination: C:\Users\michael.aivaliotis\AppData\Local\Temp\Instrument Module\Instrument Module\Sample Request.vi

Invoke Node in AB_Source_VI.lvclass:Set_VI_Path.vi->AB_Source_VI.lvclass:Copy_SourceItem.vi->AB_Build.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_API Do Two Step Build.vi:4020001->AB_API Build.vi:4700001->NI_AB_API_Build.lvclass:Build.vi->NI_AB_API_SDIST.lvclass:Build.vi->DQMH_TestStandifier.lvlib:Create Source Dist.vi->DQMH_TestStandifier.lvlib:TestStandify State Machine.vi->DQMH_TestStandifier.lvlib:Main.vi

Possible reason(s):

LabVIEW: (Hex 0x54D) A LabVIEW file from that path already exists in memory, or exists within a project library already in memory.

Method Name: Set Path
<Call Chain>Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_API Do Two Step Build.vi:4020001 -> AB_API Build.vi:4700001 -> NI_AB_API_Build.lvclass:Build.vi -> NI_AB_API_SDIST.lvclass:Build.vi -> DQMH_TestStandifier.lvlib:Create Source Dist.vi -> DQMH_TestStandifier.lvlib:TestStandify State Machine.vi -> DQMH_TestStandifier.lvlib:Main.vi

Possible reason(s):

LabVIEW: (Hex 0x54D) A LabVIEW file from that path already exists in memory, or exists within a project library already in memory.

Also, here are my Testandifier build settings:

[CyGa]

Hi Michael,

Thanks for reporting this issue, we will look at it !

When I rapidly think about this issue, I think that the source distribution will fail because 2 VIs with the same name will collide in the destination folder.

The only solution I see is that we set the source distribution to rename non-DQMH VIs, which can be tricky somehow.

The workaround would to rename yourself the dependency VIs to avoid any collision with DQMH VIs (Public API and DQMH core).

Meanwhile we will try to find an elegant solution.

[MichaelAivaliotis]

---

@CyGa wrote:

---

@MichaelAivaliotis wrote:

If I wanted to automate this as part of my build process, how can I run the tool? Can I run some of the low level code, or is there an API? Also, is there a way to change the build output folder location?

---

Hi Michael,

For the moment no API ! And no, for the moment it is not possible to change the destination directory.

Lets see what we can do for v2 ! ^^

---

Changing the destination directory is a big issue for me since the built PPL is a dependency for another PPL. So, I would like to have all PPLs built to a common shared location to make it easier for relinking. The temp path is user dependent. If you can suggest another solution or perhaps, I'm not understanding PPL linking. 🙂

[MichaelAivaliotis]

---

@CyGa wrote:

The workaround would to rename yourself the dependency VIs to avoid any collision with DQMH VIs (Public API and DQMH core).

Meanwhile we will try to find an elegant solution.

---

Actually, the solution is to rename the containing libraries or classes, not necessarily the files themselves.

[MichaelAivaliotis]

I ran into another issue. I have a DQMH module that I want to run Testandifier on. However, this module launches another dependent DQMH module. In typical DQMH fashion, it calls the Start Module.vi, which is common practice in the DQMH world. However, Testandifier doesn't like it and throws an error. Is there any suggested workaround? I assume one solution would be to make the dependency a PPL or something. But this is unnecessary work, I think. It should just be pulled in:

Error -17208 occurred at Could not find item 'Start Module.vi' in LabVIEW Packed Project Library 'C:\Users\michael.aivaliotis\AppData\Local\Temp\Output\Module 1.lvlibp'. in DQMH_TestStandifier_Resources.lvlib:Add Steps in Sequences.vi->DQMH_TestStandifier_Resources.lvlib:Create TS Sequence.vi->DQMH_TestStandifier.lvlib:TestStandify State Machine.vi->DQMH_TestStandifier.lvlib:Main.vi

I've also attached a sample project that reproduces the issue. Testandify Module 1 which calls Module 2.