Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by jb1592

  1. I've seen similar happening on two different PCs as well. Restarting fixed it on one; had to reinstall on another.

    Currently on this one it opens, but will automatically close itself after a maybe 20 or 30 seconds.

    I'm not sure what's causing all of this, but this is all I have in C:\ProgramData\JKI\VIPM\error.


    =========== START of VIPM 2020.0.0 (build 2302) Error Message ===========
    An internal VIPM 2020.0.0 (build 2302) Error has occured on: Sunday June 28, 2020 at 05:22:19 PM

    = Automated Message Start = 
    Error 42 occurred at (http response "404". URL Requested: 
    tin_consultants_lib_finance_ohlc_plot- 85294761631CBC58471969C9E99FB95F:2980001 in 
    ->OGPM Class.lvlib:0A647C51DBC1AD7225F71A08D470BB08->OGPM 
    Class.lvlib:4CD02F4728B5353B72E37139092E0B05->E1F6385E95370507176402E569A529D7->VIPM Main Window.vi
    . URL: 
    Possible reason(s):
    LabVIEW: (Hex 0x2A) Generic error.
    = Automated Message End =

    = User Defined Message Start = 
        Error downloading package info
    = User Defined Message End =

    = Error Handler Call Chain Start =
        VIPM Main Window.vi->
        OGPM Class.lvlib:4CD02F4728B5353B72E37139092E0B05->
        OGPM Class.lvlib:0A647C51DBC1AD7225F71A08D470BB08
    = Error Handler Call Chain End =
    =========== END of VIPM 2020.0.0 (build 2302) Error Message ===========

  2. Yes, I use the in-line execution mode on all the "constant" VIs that I generate as well.

    I tried out a quick POC performance test... There doesn't seem to be any real difference when using constants. I also tried the same LUT VI with the in-line execution switched off... that does make a HUGE difference. The in-line version is ~11x faster than the same VI with it turned off, and the VI that only contains a constant gets hit just as hard. Call overhead on such a tiny operation = ouch.

    I'm thinking the improved maintainability makes the LUT concept a winner. Thanks so much for the suggestion... now to rework my code conversion scripts and delete a lot of VIs I don't need anymore. 😅

    • Like 1

  3. On 2/11/2020 at 1:49 PM, Jim Kring said:

    I'm not sure, but Chrome can use a LOT of memory with lots of tabs open. It could also be related to disk usage. I'm not sure. 🤷‍♂️

    Maybe... weird that nothing else seemed to be affected at all though. Not a major concern, just thought it was curious.


    On 2/11/2020 at 1:49 PM, Jim Kring said:


    Maybe you could create your own non-sparse enum that you pass into your VIs and then use a conversion VI with a look-up table to convert these non-sparse enum values to the sparse integer values used by your low-level library.  This is discussed a little bit here on lava.

    That's a pretty good idea... Certainly easier to maintain, although I wonder how well Labview optimizes code like that. I'm thinking it would be less efficient since there would be the external VI call to index the look-up table, but in most cases it would be a constant enum indexing an constant array... I wonder if the compiler is smart enough to just evaluate that to constant value when I build the application for deployment.

    One again, mostly just a point of curiosity. It's not like that anything I'm doing is that performance sensitive anyway. Thanks for the suggestion. I may do that. 😄

    Edit: I read the link after commenting on the suggestion; I assumed pushing every value into an array constant and indexing, but that example is using a case structure. I wonder if there's any significant difference/benefit to one way over the other. I guess the array based LUT could have a share of space allocated to undefined values, but it shouldn't really be that much.

  4. I have a few libraries that contain a number of typedefs that I would like to insert on the function palette so they can be used to create constants on the block diagram, and I typically keep them all in a single typedefs folder while building my library. It would be great for quickly building the palette if the Add Folder of Controls option was available in the right-click menu for the Functions Palette.

  5. Thanks, I'll do that. Option 2 would be nice, but I've wished a few times that the Add Control or VI option allowed multiple selections as well. That seems like the more versatile option if only implementing one of the two is feasible.

    Side question: Any idea why Chrome freezes will VIPM is processing a (very) large package?

    Background: This package I'm working on is actually a message dictionary for one of my company's products that has 27 different communication nodes and over 1200 defined messages. Since LabVIEW does not support sparse enums, the best strategy I've found to convert this into a LabVIEW library so far is using VI scripting to convert all the #DEFINES into individual VIs that are simply numeric constants wired to an indicator. Essentially, these are "constant" VIs. The end result is the library ends up having ~1450 files in it by the time all is said and done.

    LabVIEW has generally handled this library fine as a local library I've copied into my projects, but I wanted to package it to make it more easily distributed and easier to keep up to date when our R&D engineers release new product software. Understandably, it takes a while for VIPM to process all these files and build a package, and after installing it takes a while to update the package list. I suppose all of that is to be expected, but what's interesting is that Chrome freezes while a few of these steps are occurring. Every other application on my computer is responsive.

    • Like 1

  6. I am trying to figure out if there is a way to easily add a folder full of typedefs to the function palette more easily than adding them one at a time.

    I've taken to the habit of organizing my library into folders that mirror the palette structure I want. This makes palette building using the Insert>Folder of VIs... function very easy. Unfortunately, that function doesn't seem to include CTL files.

    Any tips?

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.