Jump to content

Jim Kring

JKI Team
  • Content Count

    1,688
  • Joined

  • Last visited

  • Days Won

    40

Everything posted by Jim Kring

  1. I've posted this bug to LAVA (here) and NI (here)., so hopefully we'll get a CAR # soon.
  2. I've added this to the known issues: Known Issue (Case 6611): Front panel objects get repositioned when dropping merge VIs from the palettes
  3. Hi crelf, This is a known issue and a LabVIEW bug. You should be able to affect the relative drop locations by changing the positions of the front panel items in the merge VI (relative to the FP origin and offset). I don't have this problem fully characterized. It did affect us (JKI) when we were laying out the FP items for the JKI State Machine. I think that we "fixed" it through some trial and error. I'm not sure if an official LabVIEW bug has been reported, but we do have a JKI issue tracking number for it: Known Issue (Case 6611): Front panel objects get repositioned when dropping merge VIs from the palettes I'll file it with NI and post back info (and hopefully a CAR # from NI). Thanks, -Jim
  4. I've just updated my previous post with a link to the pages for these known issues (Case 6524 & Case 6525).
  5. Thanks for your efforts to uncover these issues. I've filed bugs on them: Case 6524 - VIPM should delete package script VIs in temp folder even if read-only Case 6525 - VIPM does not uninstall files that are read-only
  6. Thanks for your time spent debugging this. I'll take a look at the other thread.
  7. One thing that might be causing the is LabVIEW's VI Server Settings -- these settings need to be set up right, for proper use with VIPM. Here is the documentation on this: http://www.jkisoft.com/vipm/docs/2.0/labview8x.htm Specifically, make sure that you're able to call VIs (the "VI calls" setting). Also, (and not to rub salt in the wounds) we can provide much more in-depth support on these types of issues for customers with a support subscription.
  8. BTW, I just added this to the list of known issues: Known Issue (Case 5074): Double-click on VIPC file in windows explorer should "Apply" VIPC (in Community Edition) rather than show error message Thanks, -Jim
  9. We at JKI are excited to announce the upcoming release of VIPM 2.0.3 on the Mac, Linux, and Windows operating systems. We have been working hard on various issues impacting VIPM on Mac and Linux and are proud of this significant achievement. Additionally, this release will include fixes for several minor issues as well as minor usability improvements. For more information about VIPM, visit jkisoft.com/vipm
  10. I'm sorry to hear about the trouble. I haven't ever seen anything like this, before. Yes, please let us know if reinstalling LabVIEW or VIPM fixes the problem. I suspect that one of your install scripts might have tweaked your system somehow.
  11. Hello Heiko, Are you sure that the Value string's label is "Value"? Is it possible that we're seeing the string's caption is "Value" and the hidden label is "TEXT"? Also, if you're still having issues can you please post your example VI that demonstrates the problem? Thanks, -Jim
  12. Jim, That's a doosey of a question for 7pm on a Friday We'll take a look at your VI and post some comments... Thanks -Jim K
  13. OK. I'm glad that the post-build hook is a viable solution for you. Ya, this issue isn't at the top of everyone's list -- it's most important for VIPM users who are interested in system validation (FDA, etc.).
  14. Hi Richard, I'll try to get you up and running another way. I'll send you an email, off-line. Thanks, -Jim
  15. Hi Richard, I think you can ignore this missing VI error. This is a result of you opening the VI in the LabVIEW 8.5.1 development environment. This is not possible, since some of the VIs in that LLB are saved in 8.0.1 without block diagrams. This is intentional and is part of how the installer is built -- it's not meant to be opened in LabVIEW 8.5.1, it's meant to be opened by the VIPM installer that is running in the 8.0.1 RTE. So, the problem remains that the installer executable is unable to open this VI: LabVIEW: The VI is not executable. VI Path: /tmp/lvzlib.llb/ZLIB Extract All Files To Dir__ogtk__SFE.vi Now, is this error coming from the LabVIEW 8.5 development environment or from the installer running in 8.0.1 RTE? The only reason I can think of that this VI would seem to be "not executable" by the installer running in 8.0.1 would be that it's having trouble loading the lvzlib.so file. Thanks, -Jim
  16. When you open "/tmp/lvzlib.llb/ZLIB Extract All Files To Dir__ogtk__SFE.vi" does the LabVIEW error list say anything about missing lvzlib.so?
  17. Hi Brian, Yes, I recall this discussion coming up before, too, and it's something that we've been thinking about, a lot. Below, are some structured points on the issue: There are a two different perspectives you can take when thinking about (and trying to address) this issue. Note that these perspectives are somewhat at odds with each other. 1) Make the VI Package's LV compatibility more tightly constrained. On one hand, a package should know (to the best of its ability, at the time it's built), which LabVIEW version's it's compatible with (and which packages it depends upon). Pros: A user can never accidentally install a VI Package onto a LabVIEW version that isn't known to be compatible. Cons: A VI Package has to be rebuilt, in order for it to reflect new information about compatibility. This means that the package will need to be rebuilt every time a new LabVIEW version is released or a new dependency package is released. Work-around: Create a post-build hook VI that changes " Exclusive_LabVIEW_Version=>=8.2 " to " Exclusive_LabVIEW_Version=8.2 " Ideal solution: VIPM's package builder would allow you to specify explicit LabVIEW version compatibility. 2) Add additional information about "validation/certification" into the system. One the other hand, when new LabVIEW versions are released (and new dependency packages are released), it would be useful to be able to update the compatibility/dependency information. Pros: A package does not need to be rebuilt, in order for additional information about compatibility to be added into the system. Cons The additional information doesn't travel around with the package, which means that everyone will need access to this shared information. Work-around: Use "certified" (by you or your organization) VI Package Configurations (VIPC files). A VIPC contains LabVIEW version information (which determines which LabVIEW version to "Apply" the configuration to) in addition to a set of packages. So, you can create one certified VIPC file for each LabVIEW version that contains the packages you know to work for that LabVIEW version. Ideal solution: There would be some central repository (for your organization) that contains information about validated configurations. I'd be curious to hear your feedback about this and what type of solutions you'd find most useful. Thanks, -Jim
  18. Hi Richard, It's good to hear that we're making progress. You can ignore these files as they are created by the LabVIEW run-time engine: vipm-1.0-linux_8.0.1_physrin_cur.txt vipm-1.0-linux_8.0.1_physrin_log.txt Regarding the missing VIs, I'm not sure if this is the real problem. This installer works fine and there are no missing VIs on other platforms. My guess is that the problem has something to do with the unzipping shared library. Is there also a file located here: /tmp/lvzlib.so ? When you try to open /tmp/lvzlib.llb is it correctly linked to lvzlib.so ? Thanks, -Jim
  19. Hi Neil, I'm sorry to hear about the blue screens -- that's no fun Did you try turning off your McAfee VirusScan Enterprise 8.0 software? I suspect that this is the culprit. Thanks, -Jim
  20. Richard, Randy Hoskin from the LabVIEW R&D team has responded (here) to your post on the NI forums. He has some troubleshooting steps that he'd like you to take. Thanks, -Jim
  21. Hi Ashish, EasyXML is licensed on a per-developer basis. So, you can have it installed on as many computers as you need, to do your work. If you're done using EasyXML on the old computer, you can right-click on the package an choose Remove from Library... (or select the package and then select the Package>>Remove from Library... menu item). This will remove it from VIPM's package list. Thanks, -Jim
  22. Hi Richard, > I haven't had any luck on the NI forums so far I've sent a message to some "higher-ups" at NI to see if they can escalate the issue. We'll see if that helps. > I was wondering if it is possible to install OpenG tools without the vipm? (The dictionary tools would be extremely useful for me right now..). I figure since these tools are open source it must be possible to install them separately, but I don't see how. Yes, it's possible, but it's neither easy nor recommended... You can download the individual OpenG package files from SourceForge here. They are zip formatted archives and you should be able to extract the VIs. > Also I was wondering if there are any plans for an updated vipm for linux any time soon? Yes, we're actively working on this and hope to have something available, soon. There are no official announcements, yet, though. Thanks, -Jim
  23. Hi Chris, I've added this to the known issues: Known Issue (Case 6273): Palette icon transparency not shown in package builder Thanks, -Jim
  24. JKI doesn't have access to the LabVIEW Software Engineering Tools beta, in order to test this issue. Is there a way to have this "evaluation software" dialog go away (such as a "don't show me again" checkbox) until after the beta expires? Otherwise, your manual work-around is probably the best approach.
  25. Neil, > Firstly, congratulations on what looks like a great VI utility. Thanks! Regarding your issue: That's strange. Does your Windows user account have admin rights? (Make sure you do.) Are you running anti-virus or anti-spyware software? (Try turning this off.) I'll check with the rest of the VIPM developer team to see if they have any other ideas. Thanks, -Jim
×
×
  • Create New...

Important Information

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