DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1003 when running from packed library

Solved!
Go to solution

I am working on converting a program I use to a DQMH module.  The goal is to build it as a packed library for use in a larger application.  I am encountering an issue where I have code that runs fine from my project library.  I am able to use the test api sniffer and everything works as expected.  However, when I build it into a packed library and try to run the Start Module.vi either from the packed library itself or from within another project, I get error 1003.

 

After playing around, it seems to be related to using the Module Data--cluster.ctl as an input/output control for a subvi that contains the function to be performed in the message handling loop as shown in the attached pictures: 

 

Error 1003Error 1003

 

WorksWorks

 I have also attached two simple projects with a single request event each with a packed library that demonstrates the above issue.  Does anyone know why using the module data cluster like above would cause an issue?  Is it bad practice to try use the module data cluster in that manner?  This module is intended to take the provided parameters and run them through a control loop algorithm to generate coefficients for use in a microcontroller project.  I thought it would be convenient to be able to use the module data cluster as a means of providing all the needed data to my subvis so I didn't have to unbundle and rebundle a bunch of datapoints as I progress towards adding more sophisticated calculations.

 

Thanks in advance.

 

 

Download All
0 Kudos
Message 1 of 8
(4,669 Views)

Jeff,

 

Have you tried on a different computer? I just downloaded both of your zip files and both of them work for me. 

I ran the API Tester, started the module from there, clicked on show block diagram and put probes on the parameters wires and I saw the parameters values change on the block diagram of the DQMH Module Main.vi and have the same values as the values I was changing on the tester.

 

No errors reported here.

 

If you are able to reproduce it on another computer, please list out the steps to follow to reproduce it and I will try again.

 

Regards,

Fab

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 2 of 8
(4,642 Views)

Thank you for taking a look.  I think I was unclear in my original post.  The error does not occur with the module itself, only when I build it as a packed library and try to use it in another project.  It also shows an error if you open the packed library itself and just try to run the start module.vi from the file browser.  I made another simple project that demonstrates the error.  It fails on multiple workstations with labview 2017 and DQMH 4.0 installed.

 

New project using public api of libraryNew project using public api of libraryFrom packed library directlyFrom packed library directly The steps to reproduce would be as follows:  From a new project, add the packed library from the build folder of the source project and add the Start Module.vi and try running.  Or, from the packed library itself in the build folder, try running the Start Module.vi.

 

Thank you again for looking at this.  I appreciate your time.

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

Hi Jeff,

 

I was able to reproduce the error and have not figured out yet what is causing the error. The error does not show if the PPL is built with debugging enabled.

 

I built a default singleton module into a PPL and that one works with no problem. 

 

Seems like the culprit is inside Case UpdateParameters.vi, probably the Controls [] Property node. If I disable calling this VI from the MHL case, the PPL builds and runs. I will continue to try a couple of things on that VI and will let you know if I get it to build into a PPL.

 

 

I will keep you posted,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 4 of 8
(4,603 Views)

Hi Jeff,

 

I was able to make it work. I tried lots of things, including disabling the entire contents of the Case UpdateParameters.vi (except for the controls and indicators) and it would still fail. So I decided to not feed the entire Data Cluster into this VI. 

 

This did the trick and the attached code no longer fails.

 

--- parenthesis ---

At Delacor, we avoid feeding the entire local data cluster into VIs in the MHL cases. The reason is that local data clusters tend to grow with time and you end up with VIs that are taking in a large cluster and only using a handful of parameters. Another reason is that we favor Unit Testing and unit testing with large clusters is hard to maintain. It is better to just have the inputs that the VI needs. 

--- ---

I don't know why the code failed before, that would be a question for National Instruments. I think you have enough information if you want to open a Service Request and find out more.

 

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 5 of 8
(4,596 Views)

I thank you for taking the time to help me out.  I will follow that guideline and only feed in necessary parameters.  My next step will be to start incorporating the unit testing as well.

 

Best regards,

Jeff

Message 6 of 8
(4,585 Views)
Solution
Accepted by topic author Jeff@VMI

Hi,

 

I am also working with DQMH and have similar problem. I found on NI web page :

If an exported VI has a connector pane with inputs or outputs of type definitions or classes, include the type definitions or classes in the top-level project library. When you right-click a project library and select Replace with a packed library from the shortcut menu, LabVIEW does not replace type definitions and classes, only exported items of the packed library. As a result, VIs in the packed library might break when you replace the project library with the packed library.

 

This mean that once compile, the sub VI input "Module Data - cluster.ctrl" is looked from outside of the PPL, and that's what causes the error. 

 

In that specific case this can be solved by setting parameter "Disconnect type definition" of the build Packed librairies to true.

 

Because Classes have the same behavior, I think that classes should be placed outside of PPL (which might be problematic in some case)

 

disconnect from type def.png

 

I hope that it could help.

 

Regards.

 

Benoît

Message 7 of 8
(4,336 Views)

Benoit, 

I tried what you said and checked the disconnect type def box and it did seem to fix the problem.  Previously I had made it work by unselecting "Remove front panel" and "Remove block diagram" from the source file settings option.  Thank you.

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