Jump to content

Jim Kring

JKI Team
  • Content Count

    1,589
  • Joined

  • Last visited

  • Days Won

    33

Everything posted by Jim Kring

  1. 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)?
  2. 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?
  3. 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!
  4. 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
  5. 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.
  6. 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.
  7. Looks like your IT department is probably blocking the download URL.
  8. 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.
  9. 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.
  10. I can't point you to a known issue, but there's a good chance we've fixed the issue you're mentioning.
  11. 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.
  12. Hi Tianbin, The VIPM package URL handler only works on Windows, currently. Jim
  13. Hi Steen, Thanks for the well thought out question/proposal. We've considered this at several points, yet there have always been very many considerations that make supporting LVLIBPs problematic. Unfortunately, NI did not have LabVIEW developers in mind when they designed LVLIBPs -- they were focused mostly on addressing internal use cases such as streamlining deployment to embedded targets.
  14. Hi There. Yes, it looks like you may have found a bug. I think that "[]" characters are allowed in JSON data names. Perhaps they were removed because they are also special characters.
  15. Hi Kev, Can you try setting VIPM to use "No Proxy" and see if that helps.
  16. I don't know if there's any way to do this programmatically, at this time.
  17. Hi, Paul. Yes, VI Package Configuration is the way to go!
  18. Hi There. Please email support@jki.net and we'll point you in the right direction.
  19. Not totally sure what the issue is. Have you tried running both VIPM and LabVIEW as the root user? Also, might be because LabVIEW is running in Evaluation mode. Linux is a bit tricky, since it's so configurable and quirky...
  20. Thanks for the update @wyzromek. Yes, there's still a lot to do -- NXG 2.1 still isn't totally ready for upgrading existing projects and there is still a little work to do on the JKI SM side of things, too. We're hoping that NXG 3.0 will provide a bit more features and improvements to the process ?
  21. Hi @Jim C I split this discussion into a separate discussion thread. I like you're idea about the JKI State Machine Follower. I've been collecting some ideas about possible run-time and debugging tools: https://github.com/JKISoftware/JKI-State-Machine-Editor/wiki/Roadmap#run-time-tools Here are a few ideas: State logging - Show which states executed in which order Data logging - Show what data was changed between execution of frames Single stepping - Execute one frame at a time and pause between execution Breakpoints on individual states - Pause when a state is executed, so that highlight execution can then be enabled (and maybe we could turn execution highlighting ON, but I'm not sure how to do that programmatically) These tools would probably require temporarily swapping the Parse State Queue function in the user's instance of a JKI State Machine with a special one that has debugging features under the hood (there could be a debugging and non-debugging version of Parse State Queue that we could script in/out of the VI to enable/disable the debugging features). Anyhow, I wanted to let you know that this is a direction we're looking into, in case you have any ideas you've already been thinking about or working on :-) Thanks,
  22. Thanks for the feedback @Jim C. I'm glad you like this new feature. I also like the idea of allowing the JKI SM Editor to help with debugging and have it highlight the actively executing frame. I've been toying with some similar thoughts :-)
  23. We've made another great round of improvements to the JKI State Machine Editor that we're excited to tell you about. This release adds a pretty cool new little feature that we've heard several people ask for... Now, you can right-click on a state string wire and select Insert "Add State(s) to Queue" to automatically insert this VI.
  24. Hi again @wyzromek. Have you tried clicking 'Next' and continuing with the conversion? The resulting project should be relatively unbroken: the missing methods/property nodes are replaced with placeholder nodes and the NXG 2.0 library calls to both JKI & OpenG are mapped correctly (see below).
×
×
  • Create New...

Important Information

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