Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/04/2020 in all areas

  1. I've seen this behaviour many times. We use OOP and lvlibs heavily in our projects and unfortunately often run into those builder quirks. The fun fact is that sometimes the same project built on different machines produces different outcomes (on one it always breaks, while on other it always succeed, while on third it's 50-50 chance). I never really bothered to investigate and report this to NI as those problems are very non-reproducible. Going to your specific question aboutt VIs which end up outside exe (in no particular order) : 1. Check the dependencies between libraries. The builder hates circular dependencies between them (i.e. something in lib A depends on something in lib B and vice versa). Avoid them - usually the solution is to move the offending VIs between those libraries. You'll also end up with better code design, so double the profit. 2. Enable builder log generation (I think it's in Advanced settings) and see if you can make any sense of what it puts out regarding those "outside" VIs. 3. Try building on different machine. 4. Set "Enable debugging" for the build (also in Advanced settings I think). 5. Try to recreate the problematic VIs under new names - create the blank VI, copy the contents (block diagram) of the current VI, replace the calls. Do not simply rename the current VI and do not Save as..., both of those might retain some hidden problems inside the VI. Also,try to change reentrancy settings and try to make them inline. 6. Try to recreate callers of those problematic VIs in the same manner as above. 7. Separate compiled code from the VIs. 8. On the contrary, do not separate the compiled code. Try to do both and see if there is any difference. 9. Last resort - put the contents of the VI inside the caller.
    1 point
  2. Now that you mention it I have not either.
    1 point
  3. I do actually receive emails from LAVA.
    1 point
  4. Thanks for the quick response @LogMAN No problem @LogMAN. I enjoy a good rant, as much as anyone 😛 I try not to take it personally when it's about VIPM (even though it's been a labor of love for ~20 years), and honor everyone's good intentions to make their development tools better, contribute to the community, and get their work done as effectively as possible. Those are really good points about how to make the VIPM system tray service more configurable in terms of opt-in/-out. Honestly, we were/are trying to take a lean (MVP) approach and listen to people's feedback. That's also hard for developer tools, where people do want access to the whole Swiss Army knife of settings. So, we did our best to at expose those to users via config file settings. This discussion has been helpful, and I've gone ahead and posted an official KnowledgeBase entry to make sure people can find this easily, in case the high-level features don't provide enough granularity. VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up Thanks again and keep the feedback coming! I'm glad to hear you're going to give VIPM 2020.1 a try.
    1 point
  5. Hi Everyone, I was just alerted to this discussion (thanks @drjdpowell), so I wanted to be sure I heard all the feedback, to make sure we're staying on top it. Before I dive in, I'll mention there is a version 2020.1 in beta right now (if you can't access this, please be sure you sign up for the beta and/or send me a PM). This addresses many of the points raised here, so please check it out. Also, it's important to mention that VIPM 2020 had a LOT of work (and love) put into it, and the beta+launch was in the middle of COVID-19, so things didn't get as many eyes (i.e. beta testers) as usual. That's unfortunate and we're working hard on the new 2020.1 build. Any feedback/issues you have are important, so please do post them and know we're listening. It's hard to keep tabs on conversations that happen in various LAVA threads, so if you'd like to see something improved/resolved, please do post it in the VIPM forum or PM me. I'll try hard to respond to the good points everyone raised. First, I'll mention that VIPM 2020.1 no longer requires a sign in when installing packages from the VIPM Community Repository. In 2020.0, this was causing issues for some users due to their Enterprise IT/Networking configuration. And, as you've all mentioned, some users really didn't like it, which is fair. There are still some features that use sign-in, like starring packages, and there will be a prompt when those features are invoked. @LogMAN Actually, nothing changed with how VIPM installs itself 2020, as compared to 2019 (and older versions). The issue was that the the VIPM 2020.0 (and older) installer framework (e.g. Advanced Installer) needed to be updated for newer versions of Windows. In VIPM 2020.1 (now in beta -- see link above) we've addressed this issue and it should install without issues. That said, there were some bugs in NI's LabVIEW 2020 installer that causes it to fail to correctly install VIPM 2020, in some cases -- e.g. the issue where it sometimes would fail to start. NI has been working with JKI to fix this. @Neil Pate That's fair We added this feature to make VIPM much more responsive when users are opening packages -- VIPM sometimes runs as a background task, so that it doesn't have to reload itself for each of these operations. This can be disabled in the VIPM settings file, here: "C:\ProgramData\JKI\VIPM\Settings.ini" [General] Start VIPM when computer starts?="FALSE" Start VIPM when LabVIEW starts?="FALSE" @Michael Aivaliotis Thanks for helping everyone out. Older versions of VIPM are available to users -- we have a link on the vipm.io/download page for users. However, since older versions of VIPM use outdated LV runtime engines that are longer be supported by NI and don't work well on newer OS'es, we don't encourage users to use them -- it often creates more problems for them, and a support burden for JKI and NI. As such, we ask that people do not post older downloads and instead direct people to get them from either NI or the VIPM websites. Again, thanks for helping people out. Also, I appreciate everyone's feedback -- I know when things don't work well, it's super frustrating. VIPM 2020 had some bugs and left room for improvement, because of all the new features that had to get out the door in time for the LabVIEW 2020 launch date, and we didn't have the typical level of beta testing. I hope 2020.1 resolves those, and if it's still missing things or not working right, let me know and I'll take responsibility for those issues. Kind Regards, -Jim
    1 point
×
×
  • Create New...

Important Information

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