ThomasGutzler

Good find!

@Jim Kring happy to assist in any way I can when you're looking into this bug.

I made a new .zip with the current versions of all files.

Would be cool if someone else with a VIPM pro would try to build this just to check if it's my problem.

Cheers

bits.zip

Minor update, I've gotten rid of the different type cases by doing this

While that makes the code prettier, it also prevents it from building into a vipc due to the same issue: nested vims

Hi,

I'm having problems building a vipc from a vipb with files containing nested vims. Getting the following error from VIPM:

ERROR: 7: VIPM API_vipm_api.lvlib:Parse Build Return Message_vipm_api.vi<ERR>
Code:: 7
Source:: 0053C289D635723F5DC0A4F08297566A<ERR>
The following source VIs or Libraries are missing.
Please correct this problem before rebuilding.

b39afad9-8321-4719-86a9-dddab325fc87.vi

The following source VIs or Libraries are the callers of missing files

BitsSetter.vim

I created a zip with the vims and the vipb file. Any suggestions how to fix this?
Opening the files shows no errors. Replacing the nested vim with its actual implementation fixes the problem but I don't want to give in just yet.

I'm on LV 18.0.1f4 64bit with VIPM 2018.0.0f1

Cheers

bits.zip

Using my company's template which is basically a JKI statemachine with OpenGDS active objects sprinkled on top which communicate via queues and/or events

Turns out that deleting the VIPM cache (C:\ProgramData\JKI\VIPM\cache) fixes the problem.

With the cache folder gone I restarted VIPM and it created it again with fixed permissions and running happily for myself and the system user which is used for CI builds.

You're right, running VIPM as admin works but I'd still like to know how to fix the problem rather than work around it.

No, the account is fine.

The CI build (system account) still works. The problem is when I log in manually to debug a problem. I just don't know where to look for those files it's trying to access or which files those are.

Hi,

Over night something changed on my windows 10 build server and I can now no longer open VIPM. It just shows the splash screen and then closes again.

Here's the log file:

=========== START of VIPM 2018.0.0 (build 2025) Error Message ===========
An internal VIPM 2018.0.0 (build 2025) Error has occured on: Tuesday August 20, 2019 at 03:19:48 PM

= Automated Message Start = 
Error 8 occurred at Open/Create/Replace File in NI_LVConfig.lvlib:Parse Config to 
Queue.vi->NI_LVConfig.lvlib:Load.vi->NI_LVConfig.lvlib:Open Config Data 
(compatibility).vi->DDEFA056211BA4DA4D215C322E067D90->621BFCD461979D3C7127139A69154E03->762BBE85A007
171D5A65B48289D23361->46803A2448FAC5F85BFF8F5C199E9C6F->OGPM 
Class.lvlib:7D7C5CD8C5D361C01081DF5613237E15->OGPM 
Class.lvlib:D69AB3997B80ACD75689430E3922612C->OGPM Class.lvlib:OGPM Init.vi->VIPM Splash.vi
Possible reason(s):
LabVIEW:  File permission error. You do not have the correct permissions for the file.
=========================
DMA hardware error detected.
C:\ProgramData\JKI\VIPM\cache\ngene_lib_deepltk_fpga_addon-1.0.0.45.spec
= Automated Message End =

= User Defined Message Start = 
    Error(s) Generated in Splash Window
= User Defined Message End =

= Error Handler Call Chain Start =
    VIPM Splash.vi
= Error Handler Call Chain End =
=========== END of VIPM 2018.0.0 (build 2025) Error Message ===========

Any idea where the files are that it doesn't have the right permissions for?

Or Get Volume Info if you're only interested in the "C:\" part of it

Thanks for throwing ideas around. Let's debunk some of them.

I don't think it's a hardware problem, because a power cycle of the DAQ wouldn't fix that reliably and a reboot of the PC wouldn't break it reliably. The DAQ is connected to an Intel NUC directly to the onboard USB port. I tried different ones with no luck.

There is no funny software running that interferes with the USB ports

PC is set to never sleep. Power management was enabled for USB hubs, so I turned that off and rebooted the PC. Same problem

Status Code: -88705
The specified device is not present or is not active in the system. The device may not be installed on this system, may have been unplugged, or may not be installed correctly.

Next, I unplugged the USB cable and plugged it into a different port and the DAQ showed up in MAX. Rebooted the PC and it was still there.
Turns out not all USB ports are the same. Previously I only tried the ports at the front of the NUC. This time I tried one at the back. That fixed it on both PCs.

Fix: Don't plug your USB DAQ into a "charging USB port"

Hi,

I'm having a problem with two of my PCs that have a USB-6356 DAQ connected. Every time the PC reboots the DAQ isn't recognised in NI MAX or LabVIEW or NI Device Monitor.

The DAQ reappears after I power cycle it. Any thoughts what the problem might be?

PC is running windows 10 Pro and LabView 16

Cheers

On 11/30/2018 at 8:07 AM, MikaelH said:

FYI, version 1.2.38 has an issues when creating Override methods.

Does that bug exist in .37 too?

3 hours ago, Michael Aivaliotis said:

C:\ProgramData\JKI\VI Package Manager 20xx\updates\VIPM\vipm-update.aiu is a text file that includes a URL to the installer.

Great, that helped. There's no installer but I've never been brave enough to look inside that file. Got what I need now.

Cheers

5 hours ago, Michael Aivaliotis said:

Don't use the NI LabVIEW installer. Use the installer distributed from JKI. Uninstall VIPM then install it form JKI. Never use the NI installer for VIPM.

Hey Michael,

Thanks for the insight. Could you release the installers for the older versions of VIPM so we can fix VIPM installations that got updated/broken by accidentally installing a new version of VIPM with an update of LabVIEW over the top?

That would be awesome

I'm on your side, I often do the same if I can be bothered. In rare cases I even edit the GetAttributes to entirely remove the cluster out; not sure if that actually helps but it does break the "GOOP/Add Method" a little. You should update the template and create a pull request.

Interesting choice on ignoring the incoming error when you get the attributes.

Hooovahh, as is so often the case, the best solution is the difficult one. Sending the entire content once and then keeping track of changes in a clever way transparent to the "user".

Sending only 4 is definitely going to cause pain in user experience.

Flavio, no idea why IE works and Edge doesn't, sorry  Maybe just stick with Chrome if you can

How about the OpenGDS way of things?
Just put a property node on the BD that references a front-panel element. Like this:

On 6/12/2018 at 5:16 AM, hooovahh said:

I have an update, but am unsure how to handle this in Github.

I've updated the repo on github with what was in your .zip

Unfortunately, I'm still stuck on 2016 so I couldn't even open it   ... one day

On 6/12/2018 at 5:16 AM, hooovahh said:

I have an update, but am unsure how to handle this in Github.  I have an account but I don't know how to batch upload replacing all files, removing the ones not used, and doing so in a way that doesn't look like a bunch of small commits.  So until I learn that here is the update and change log.

You should check out master, make your changes locally in a new branch, push and create a pull request.

Alternatively, I can add you as a contributor. Then you can go the nasty way of just merging your changes in without creating a pull-request.

Or, if you give me some time, I can make those changes.

On 5/21/2018 at 9:36 AM, JKSH said:

From a quick poke through the property nodes, I could only find a way to script label fonts (of FP controls, BD nodes, etc.). I couldn't find a way to set fonts at the VI level.

No me neither.

Looking at the BD example, it seems the in-place structure was blown up by the Bundle by Name node. Is it even possible to change the font used in those?

Quote

Expansion behaviour that depends on screen settings is something that I'd consider a bug. It will only become more prevalent as the screens become more varied in DPIs. Would you be willing to report this to NI? I doubt we'll see a change in current-gen LabVIEW, but hopefully NXG will be protected from this.

Yeah, I'll report it.

9 hours ago, hooovahh said:

But do those machines have the same scaling settings in Windows?

All build machines have scaling set to 100%.

It's only my laptop screen that is set to 200% and I can't take that out of the equation. All our developers have high DPI (200%) laptops and regular (100%) 2nd monitors.

I can't edit the scaling on the build machine because it's headless and the setting is grayed out when remoting in.

On 5/17/2018 at 10:35 PM, hooovahh said:

In Windows do you have any weird scaling settings on your display?

I do. Code is developed on a surface tab with high DPI (200%) screen plus a 1080p 2nd monitor. I wonder if it matters which screen the BD was on last... Unfortunately, my eyes are too old to run the tab at 100%

On 5/17/2018 at 10:35 PM, hooovahh said:

You can also try to build on another machine, or a VM and see if it works there.  And lastly JKI has revamped their forums and appear more committed to customer support on them.  If you can easily reproduce it you might want to post it there.

I'm already building on a different machine - in fact, I've tried two different ones. Same mess for both.

The only time I don't get a problem is when I build locally, but that's not an option since all our builds go through Jenkins.

On 5/18/2018 at 1:05 AM, Zou said:

Don't use application font, or dialog font, choose a specific font, for example: Segoe UI

I do use application font but I was hoping not having to go through thousands of VIs to change their font setting. But it seems that's the only way

Has anyone scripted that?

Thanks guys

Hi,

I'm using VIPM to build my device drivers and project templates into vi packages which are then used by other developers. During the build process some of the front panel elements get blown up as if the text size was changed and then reduced again but the size of the control doesn't return to its original size. A similar thing happens on the block diagram. Some structures (set to auto-grow) end up wider in the package than in their original source as if a BD element inside the structure was increased in size and then decreased again. While that's not a terrible thing to happen in the drivers, it really kills the templates because the first hour is spent to fix up cosmetics...

I've attached some screenshots.

Anyone know how to fix that?

OpenGDS does a good job with updating VI icons. It lets you design your class icon and then automatically updates all VIs in that class.

Uses the file names to generate text in the lower part

This might help: