NI Package Builder 2022 Q3 patch 1 Warning 16049

[MaximeR]

Hello,

4im using last version of NI Package Builder 2022 q3 Patch 1 32 bits version. When trying to build packages for the first time I have an error :

Spoiler

[11:23:10.82 ] Using LabVIEW deployment support library in: 'C:\Program Files (x86)\National Instruments\TestStand 2022\Components\Tools\Deployment Utility\NIPBSupport2018.lvlibp'
[11:23:11.74 ] Warning 16049: The Package Builder support for TestStand failed to load and has been disabled in this instance of Package Builder.
L'argument de retour a un type non valide. >> 'bad argument in return ???'
[11:23:11.75 ] Error -16048: Error occurred during staging in the Package Builder support for TestStand.
L'argument de retour a un type non valide.>> 'bad argument in return ???'

When using the application, the first time I try to build I have the same error. Second and following builds are working well.

With Command Line interface, it's not possible to build always have the error.

It's seems to be an error due to load time of the NIPBSupport2018.lvlibp in the process. When using the app, it first try to load it and fail on timetout but after it's well initialized. In CLI, the process is killed between each call.

Because I can't update my feed from NI Pacakge Builder, I need a tool to automate it but I'm facing an infinite Loop of bug or missing functionnalities...

Please fix it as soon as possible.

My Configuration :

- Win10 or Win 11x64 up to date

- LabVIEW 2022 Q3 32 bits up to date

- TestStand 2022 Q4 32 bits up to date

- NI Package Builder 2022 Q3 patch 1 32 bits

best regards

[Scott_Richardson]

Maxime,

1. Can you share the log file created in %localappdata%\National Instruments\NI Package Builder\Logs\ directory that is associated with the launched invocation of NIPB that reports failing to load lvlibp?
2. I assume that NIPB is launching LabVIEW when you perform the first build, if yes, how long does it take to launch?
3. If yes to (2), does LabVIEW stay launched after the error and is it still loaded when you successfully build the second try?
4. If you prelaunch LabVIEW before attempting to launch NIB and perform your first build, does the error still occur?

[MaximeR]

Hi Scott,

Thanks for your quick reply.

First Test (Log Build Failed + Success.txt) :

• Launch NIPB
• Build
• error
• LabVIEW appears in the taskbar as launched
• Rebuild
• Build Succes with LabVIEW Closed at the end

Second Test (Log labVIEW Already launched.txt) :

• Launch LabVIEW
• Launch NIPB
• Build
• Error
• LabVIEW Stay Opened

Cold start of LabVIEW alone takes ~6s to show Getting started Window after clicking on Icon

When I get the error in NIPB, LabVIEW takes certainly the same time but difficult to measure the time between the request and the state of LabVIEW, but in the log it's less than 3 seconds between the call of C:\Program Files (x86)\National Instruments\TestStand 2022\Components\Tools\Deployment Utility\NIPBSupport2018.lvlibp and the error.

With your suggest and the behavior that i have on my computer, I really think it's a timeout error when trying to launch LabVIEW from NIPB. 

For information, trying to open the NIPBSupport2018.lvlibp with labVIEW already opened takes ~4s on my computer to open.

Hope this help and the fix will be only a timeout value.

[SteenSchmidt]

---

@MaximeR wrote:

Hope this help and the fix will be only a timeout value.

---

Timeouts are the lazy programmers option. What on slower or suddenly very busy computers, are we happy with funny errors there? What if the timeout was fixed at 6 seconds instead of 4 seconds, and the operation would have finished succesfully in 6.02 seconds but was aborted with everybody now wasting minutes or hours of their time finding out what went wrong?

This is a user operation - it all goes in human time. Keep the user informed of what goes on, and let the user press a Cancel button when they give up waiting. When such an operation runs without a human operator (automated through CLI or other API), then keep the commanding application informed of what goes on, and let it send a Cancel command when it gives up waiting. See the symmetry and clear areas of responsibilities? That's good practice in software engineering.

[MaximeR]

is your message to my attention or to NI ?

I'm just hoping that the issue is a timeout that is set to short than a bigger issue. I'm not in charge of the NIPB development.

I don't like timeout too, especially when they are set without huge margin.

But when you have a process with ability to cancel it by outside, if the user send the cancel command it's just because the user have reach his own timeout than can vary lot depending of the human 🙂

[SteenSchmidt]

---

@MaximeR wrote:

is your message to my attention or to NI ?

I'm just hoping that the issue is a timeout that is set to short than a bigger issue. I'm not in charge of the NIPB development.

I don't like timeout too, especially when they are set without huge margin.

But when you have a process with ability to cancel it by outside, if the user send the cancel command it's just because the user have reach his own timeout than can vary lot depending of the human 🙂

---

My message is mainly to NI, since, as you point out, you are not in charge of NIPB development 🙂

Huge timeout margins don't help, they are just postponing the problem and creating even longer delays when the proper action is to quit fast. A human "timeout" is the way to go: Let the one in need of the service decide how long they want to wait, instead of putting that decision in the hands of a random programmer at NI.

[Scott_Richardson]

Maxime, I doubt that this is a typical timeout issue because the times you are sharing are small. The log does show an InvalidCastException which I am looking into.

For the version of LabVIEW, are you using the English version or French?

[MaximeR]

My LabVIEW is english. My Windows is in French.

[Scott_Richardson]

Maxime, we are not sure why this failure would occur on first try as there is no different code called the first time versus the second time other than loading LabVIEW. We are going to try to reproduce. We have not heard of other customers having this issue though.

Questions:

1. Have you tried this type of build operation on a different system than the one that hits this issue, and if yes, what were the results?
2. Has you always hit this issue with different versions of software, or were there changes where this clearly started to occur?

[MaximeR]

Hi Scott, 

I have the issue. We faced the issue in another computer but now it' seems to work on Windows 10.

On my Computer, I migrate from Win 10 to Win 11 with Windows Update and keep my software installed. I'm unable to say if it was working on my Win 10 version. I repaired the installation of NIPB because I got an error to access TestStand option because I add the TS runtime 2020 installed even if not activated and NIPB doesn't want to launch TS option if you don't have the support for all run-time isntalled even if you don't activate it. After repairing NIPB, I've got the same issue but removing the TS runtime for 2020 fix the issue.

Here is the NI Software installed on my Computer:

I have attached a very simple Project that reproduce the problem.

Just a LabVIEW VI inside an lvlib build in packed Library.

Trying to push the lvlipb in a package. First build is failing.

I also tryed with only a vi. it failed on first time. Trying to build package with only a text file for example it works on first time, adding a labview VI in package and rebuild it fails.

In a logical way it fails only when a LabVIEW code is inside the package and we build for the first time.

in fact it's much more complicated than just timeout, you're right. By doing some test, I have seen that. I have the error, only if LabVIEW Code is specify inside the package to distribute. At start, after opening my Solution, I can access TestStand confiugration. After First build, I have the error and I can't access the TestStand Option anymore with the following error :

But even if I have this error, I can build. The TestStand option are the default options.

So it seems to be more an error between LabVIEW and TestStand from NIPB. I can keep my setup as it for some days to do more test if you need it. Newxt week, I will try to remove and reisntall NIPB and TS Support for NIPB next week.

Best regards.