LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VIPM failing to build package due to "missing files"

Solved!
Go to solution

Unfortunately, I've needed to start using LabVIEW again for a project. After working around the intermittent crashes in the latest version of LabVIEW when trying to align items, I'm ready to publish the first release of the application.

 

The trouble I'm currently having is with VIPM, which is failing to package my application so I can hand it to a colleague. When trying to build the package, the build will abort with the message that "source VIs or libraries are missing", referencing a number of VIs with GUID names, apparently located under my actual VIs (i.e. it seems to be treating my actual VIs as folders). See below:

VI Package Manager_2017-08-21_08-20-23.png

 

All the files listed are either test or example VIs - this means they share the common property of being "top-level" VIs. That's the only thing I notice about them that they have in common.

 

If I click "OK", it brings up the dialog shown below. Here, it lists all of my actual VIs as callers of these missing GUID-based VIs:

 

VI Package Manager_2017-08-21_08-30-20.png


For what it's worth, my project is structured as shown below:

$ tree -d
.
├── build
│   └── test
├── examples
├── src
│   ├── CAN Database Builder
│   ├── CAN Database Types
│   │   ├── CAN Database
│   │   ├── Checksum Message Field
│   │   ├── Message Definition
│   │   ├── Message Field
│   │   ├── Receive Message Definition
│   │   ├── Rolling Message Field
│   │   ├── Transmit Message Definition
│   │   └── Virtual Message Field
│   ├── TestCAN Controller
│   │   ├── TestCAN Controller
│   │   └── TestCAN Controller Messages
│   │       ├── Add Checksum Message Field Msg
│   │       ├── Add Receive Message Definition Msg
│   │       ├── Add Rolling Message Field Msg
│   │       ├── Add Transmit Message Definition Msg
│   │       ├── Add Virtual Message Field Msg
│   │       ├── Load Database Msg
│   │       ├── Reset Database Msg
│   │       ├── Set Message Definition Activation Msg
│   │       └── Set Message Field Value Msg
│   ├── TestCAN Controller Mediator
│   │   ├── TestCAN Controller Mediator
│   │   └── TestCAN Controller Mediator Messages
│   │       ├── Add Checksum Message Field Msg
│   │       ├── Add Receive Message Definition Msg
│   │       ├── Add Rolling Message Field Msg
│   │       ├── Add Transmit Message Definition Msg
│   │       ├── Add Virtual Message Field Msg
│   │       ├── Load Database Msg
│   │       ├── Reset Database Msg
│   │       ├── Set Message Definition Activation Msg
│   │       └── Set Message Field Value Msg
│   ├── TestCAN HTTP Client
│   ├── TestCAN Utility API
│   └── TestCAN Web Communications
│       ├── TestCAN Web Communications
│       └── TestCAN Web Communications Messages
│           └── Transmit Message Msg
└── test
    ├── API Tests
    ├── CAN Database Builder Tests
    └── Mock Web Communications

 

0 Kudos
Message 1 of 7
(3,455 Views)

@DavidFCannock wrote:

Unfortunately, I've needed to start using LabVIEW again for a project. After working around the intermittent crashes in the latest version of LabVIEW when trying to align items, I'm ready to publish the first release of the application.

 


I feel your pain.  Sounds like you need a Consultant who (a) is currently using and familiar with LabVIEW, (b) doesn't feel "unfortunate" to be using it, and (c) has experience building VIPM  packages.  Maybe JKI would be a place to start ...

 

0 Kudos
Message 2 of 7
(3,404 Views)

@Bob_Schor wrote:

@DavidFCannock wrote:

Unfortunately, I've needed to start using LabVIEW again for a project. After working around the intermittent crashes in the latest version of LabVIEW when trying to align items, I'm ready to publish the first release of the application.

 


I feel your pain.  Sounds like you need a Consultant who (a) is currently using and familiar with LabVIEW, (b) doesn't feel "unfortunate" to be using it, and (c) has experience building VIPM  packages.  Maybe JKI would be a place to start ...

 


Hi Bob,

 

I'm familiar with LabVIEW - I've used it for years. I don't think this is an issue with LabVIEW itself exactly - I'm posting the question on this forum because it's (much) more active than the JKI ones and I've seen other VIPM-related questions get posted here. If I can't find a solution here, I'll try that approach.

 

I've developed other projects similarly to how I've developed the current one, and I was able to package them successfully using almost identical VIPB's to the one I'm using for my current project. However, this is my first attempt building a package with VIPM 2017, and it seems to be the general pattern that a few dozen things break in LabVIEW (and I guess VIPM) with each major update until the corresponding service pack gets released.

0 Kudos
Message 3 of 7
(3,381 Views)

Ah, yes, 2017.  A number of people (including Yours Truly) have had variable success with this latest version (I currently have it on none of my working machines, and have still not gotten one of them on which I tried to install it repaired sufficiently to reinstall any version of LabVIEW ...).

 

I can tell you from personal experience that LabVIEW 2016 is extremely stable, works like a charm, and is my "go-to" version for now ...

 

Bob Schor

0 Kudos
Message 4 of 7
(3,376 Views)
Solution
Accepted by topic author DavidFCannock

See this link.  It’s a VIPM bug (JKI Case 17570) with the new “malleable VIs” or VIMs.  VIs that call VIMs cause this error in VIPM.

Message 5 of 7
(3,369 Views)

@Bob_Schor wrote:

Ah, yes, 2017.  A number of people (including Yours Truly) have had variable success with this latest version (I currently have it on none of my working machines, and have still not gotten one of them on which I tried to install it repaired sufficiently to reinstall any version of LabVIEW ...).

 

I can tell you from personal experience that LabVIEW 2016 is extremely stable, works like a charm, and is my "go-to" version for now ...

 

Bob Schor


Yeah, in-line with my experience too. 2016 is very stable, but my other colleagues have updated to 2017 so I've been forced to as well.

0 Kudos
Message 6 of 7
(3,353 Views)

@drjdpowell wrote:

See this link.  It’s a VIPM bug (JKI Case 17570) with the new “malleable VIs” or VIMs.  VIs that call VIMs cause this error in VIPM.


Ah, that explains it. Another thing all these failing VIs have in common is that I call "Stall Data Flow.vim" in them. Thank you, marking this is the solution.

 

From the linked thread:

 


So...is anyone from JKI monitoring these forums?  I have a show stopping bug that I posted two weeks ago, in the latest version of VIPM, can anyone give any advice?  Thanks.

That's pretty typical. One time I tried in vain to set up a continuous integration pipeline using JKI's software. Turns out their API prohibited building packages with version 0.x.y (i.e. with a major version of 0) even though this is a ubiquitously-adopted standard for designating versions of software before initial public release. I saw someone on the forums mention this bug, and the JKI team responded saying it would be fixed within weeks. That forum post was almost 2 years old at the time I encountered the same issue.

0 Kudos
Message 7 of 7
(3,349 Views)