Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Somehow the VIP file didn't get uploaded/attached to that github release. I fixed it -- you'll find the VIP file located here: https://github.com/JKISoftware/JKI-State-Machine/releases/tag/2018.0.5.41
  2. Great! Thanks @wyzromek for reporting the issue (especially the steps to reproduce). It was very helpful in finding and fixing the issue. I'm sure lots of people are happy about this fix, too
  3. We figured it out -- it was getting an error during Macro Exit (shutdown), that was causing it to go into the error handler, which was going into Macro Exit (an infinite loop). You can work around this issue by tweaking the code inside the JKI SM Explorer window to look like the following. (You can open the JKI SM Explorer then press Ctrl+Space to stop the VI, then Ctrl+M to go into Edit mode). Update: This has been fixed in version 2018.0.1.36 of the JKI State Machine package, which has been published and is available for download and installation using VIPM.
  4. We figured it out -- it was getting an error during Macro Exit (shutdown), that was causing it to go into the error handler, which was going into Macro Exit (an infinite loop). You can work around this issue by tweaking the code inside the JKI SM Explorer window to look like the following. (You can open the JKI SM Explorer then press Ctrl+Space to stop the VI, then Ctrl+M to go into Edit mode).
  5. OK, we're looking into it. I see what you're seeing -- I'm also using LabVIEW 2018. I'll check on older versions of LabVIEW, too, to see if this is a new problem.
  6. Hello @wyzromek. Do you notice that the CPU usage goes down after a minute? Do you have Mass Compile (in VIPM options dialog) enabled or disabled? I did a little testing and see that if I do not have JKI State Machine Editor mass compiled during installation, then I have this increased CPU issue (but that it goes away after a minute). However, if I I let VIPM Mass Compile the JKI State Machine Editor on installation, then I do not see the CPU increase after closing the VI that was using it. I'm curious if you see a similar behavior to what I'm observing.
  7. Hello @Bhaghyaraj. Thanks for letting us know and I'm glad you were able to figure it out. It's probably a good idea not to rename the frame that contains the Event Structure, since the JKI SM and it's under the hood APIs depend on some of those conventions.
  8. Hi @kevin.j.r.ross, @Sam Taggart, We can reproduce the issue and it's a bit tricky, due to limitations in the scripting APIs associated with project libraries and the fact that these project items are not LabVIEW file types. There's no scripting API function to move a project item on disk that is a non-labview file type (and the build process used by VIPM loads the lvlibs and VIs into memory and moves them on disk, causing the links to those lvlib/project items to change). The work-around to this would be to do a lot of fancy, custom relinking on disk, which involves parsing and modifying the raw XML files for the lvlibs. This could work for unlocked lvlibs, but won't work for a password-protected lvlib. Now, it's possible to do these changes in memory, but I think it would involve removing items from the lvlib and then re-adding them to the lvlib after they are moved on disk. I looked to see if anyone has solved this problem and there's a discussion on LAVA about it -- I checked out these resources (GOOP Developer and Darren's Hidden Gems) and these don't deal with non-labview file types, from what I can tell. Now, you could work-around this LabVIEW limitation with a post-build custom action (requires VIPM Pro) that temporarily unpacks (unzips) the package, modifies the lvlib's (and lvproj's) xml files to link to the correct paths, and then re-packs (zips) the package. I've created a sample project that shows this technique and it works for the Simple Example that Sam posted earlier. Here is that work-around in action: >>> Simple Example - Post Build Fix.zip <<< Some notes about this example work-around: Requires VIPM Pro Uses OpenG Zip Tools to unpack/repack (I've included a VIPC file you can apply to quickly install this) Has a very brittle XML parser/fixer (you can see the code, below) -- you'll want to put some of your own love into this (e.g. depending on the actual relative paths to the items inside the lvlib) 🙂 Hope that offers some possibilities for you...
  9. Hi Sam, Thanks for posting this example. I'll pass it along to our team to reproduce and review. As always, we can't commit to a fix timeline, but we'll certainly look into it.
  10. Thanks for posting this information. Since this is an issue with installing LabVIEW, maybe you could try contacting NI support? One idea that I have is for you to try (first) installing the latest version of VIPM by itself (vipm.jki.net/get) and then (second) installing LabVIEW 2018.
  11. It looks like you need to install the LabVIEW 2015 run-time engine for Linux. http://www.ni.com/download/labview-run-time-engine-2015-sp1/5838/en/
  12. Hi Tim. This is one of those odd Windows/IT issues -- sorry it's such a pain. Perhaps installing 2017 on a new system and then seeing if you can find the uninstaller files and copy them over to the old computer might work? I don't necessarily recommend that, but if you're trying to figure out a solution, perhaps that could work.
  13. Hi Kev. Can you zip up a simple project that demonstrates the problem. This will make it easier for our team to reproduce and possibly fix this issue. Note that this might not be an easy fix. And, it's also worth noting that VIPM should be able to build packages that include PNG files. Is there a reason why they have to be part of the LVLIB (considering that these are not LabVIEW file types)?
  14. Thanks for reporting this. Would you be able to create a test VI that demonstrates the problem and save your test values as Front Panel defaults (or change the FP Control to a BD Constant), so that we can test using the exact same inputs that you have?
  15. Hey Brian, This is a great idea. You're right that VIPM doesn't scan the Custom Action VIs for dependencies, currently. I can see how that could be a big help. We can't commit to a date on this, but I'll add it to our tracker, for the R&D team to consider. Thanks!
  16. Hi Everyone. I've just posted an idea that I'd like people's feedback about. It's to create a polymorphic VI for Assert and show the Polymorphic Selector Ring, by default. You can see more details about the reasoning behind this proposal, here: https://github.com/JKISoftware/Caraya/issues/26 Thank you for your comments and ideas. -JIm
  17. Hi There. This is more of a MS Windows issue than a VIPM issue, from what I can tell. Sometimes if Windows is bogged down (CPU) this can occur.
  18. Hi Thomas. Thanks for reporting this. Can you explain a little bit about how this missing .rtm file is impacting your work? Does it cause any specific problems, or is it just an observation that it's missing? Thanks.
  19. Looks like your IT department is probably blocking the download URL.
  20. Thank you. We'll take a look at reproducing this and if there's a future fix for the issue. We can't commit to a timeline, but we certainly would love to see this issue addressed in a future release, if there's a solution to be found.
  21. Hi. Thanks for reporting this. Would you be willing to spend a small amount of time to create a super simple VI Package project that demonstrates this issue and share that with us (as a zip file)? We'd love to be able to reproduce this issue and see if there's a work-around or fix.
  22. I can't point you to a known issue, but there's a good chance we've fixed the issue you're mentioning.
  23. Which version of VIPM are you using? I think we made some improvements to VIPM 2018 (and the f1 release) that improve support for PPLs.
  • Create New...

Important Information

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