Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi Chris. I don't think there's a way to do either of these, currently, via the API. They are both great ideas and I support them Would you be willing to post these ideas to the VIPM Idea Exchange?
  2. Here are some links: https://blog.jki.net/jki/introduction-to-jki-json https://github.com/JKISoftware/JKI-JSON-Serialization There's not much documentation, since it's a very simple serializer.
  3. Hi Albert, Thanks for reporting this. Yes, you should certainly contact CPE regarding this issue. It would be great if VIPM could detect this, yet I think that it might be tricky to try to guess the developer's intentions. Maybe VIPM could warn the package developer of potential problems. -Jim
  4. Hi @maristu. We have a fix for this issue in the VIPM 2020 Beta. Thanks again for reporting it. If you'd like to help test, please sign up for the beta.
  5. That's great that this LUT approach with in-line execution mode will work for you. Yes, it should be a lot less maintenance in the future. I'm glad it's looking like a good path forward. Thanks for letting us know how it goes. I've learned a bit from this discussion, too.
  6. Yes, I’m pretty sure that if you use an array constant for your sparse values and you use a constant enum to index into that array, then labVIEW will constant fold the array indexing and look up. if you do this in a subVI, to use that look up in several locations, then you’ll probably need to set this up VI execution mode to in-line into the caller, in order for the constant folding to work I’m the calling VI. That being said, if the enum integer values are used as the indices into your look up array, then the operation should be lightning fast.
  7. @Voklaif We dug into it and it turns out to be a LabVIEW bug. The solution is for the user (you) put a To Variant function before the call to Flatten to JSON String, since the bug seems to be inside the coercion dot (and the To Variant function doesn't seem to have that problem). Note: here's the bug (and fix) reduced to a very simple example (example VI also attached for anyone who wants to play with it)... Coerce to Variant Fail (LV2019).vi
  8. This looks like a bug. (Note: I've filed a bug report in our issue tracker here: https://github.com/JKISoftware/JKI-JSON-Serialization/issues/34) I see the same thing as you. The "bridge_data" is missing, here, when it's the only element in the cluster. However, if I add another element next to the variant (so it's not the only element in the cluster) then I see "bridge_data" in the JSON string. JSON Test ignoring single variant in a cluster.vi.zip
  9. I've seen similar problems when VIPM gets an error checking the network for the package repository feed. If we solve the first issue, the second problem will go away.
  10. A.) Is it a "System" package that you're looking at? B.) Or, did you set the Target to System and then are you looking at a LabVIEW package?
  11. One more idea... Is the clock (date/time) set correctly on that computer? If not, that can cause HTTPS connections to fail, since the certificates can't be verified correctly.
  12. The hover effect does not show when the VI is in Edit Mode. It should work OK when the VI is running or when it's in Run Mode (tip: use <Ctrl+M> to toggle between Edit and Run mode).
  13. Shoot. That setting was my secret weapon. Now, I'm not sure what it could be... If you're interested, you might try VIPM 2020 Beta and see if that fixes things. It's pretty stable at this point and we're actively fixing issues.
  14. Thanks for posting to the idea exchange and letting me know more about your packaging use case. > Side question: Any idea why Chrome freezes will VIPM is processing a (very) large package? 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. 🤷‍♂️ > over 1200 defined messages. Since LabVIEW does not support sparse enums Hmmm... 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.
  15. One thought I have is that you might try the Options >> Network >> Configure Proxy to Access the Internet setting. Try testing VIPM with either "Use System Proxy Settings (Windows Only)" or "No Proxy (Direct Connection)" -- that can sometimes make a difference. PS - Your options page might look a little different, since I'm using VIPM 2020 beta. 😉
  16. That looks like a networking issue. I'm able to download that file on my computer. http://ftp.ni.com/evaluation/labview/lvtn/vipm/index.vipr Are you able to click the link above and read the file? Would you mind rebooting and trying again? 🙂
  17. Can you check the error logs? C:\ProgramData\JKI\VIPM\error It'll probably be the last entry (bottom of the log file) in a file with today's date.
  18. I see what you're saying. Ya, this isn't an extremely common operation -- typically, controls are added to the Controls Palette and VI's are added to the Functions Palette. So, there is an Add Folder of Controls menu option on the Controls Palette editor and an Add Folder of VIs on the Functions palette editor. I'm trying to think of a simple solution to make this easier for you, and I can't think of one. A couple possibilities: - The Add Control or VI option could show a file dialog that allows selecting multiple files. - We show both the Add Folder of Controls and Add Folder of VIs right-click options on both the Controls and Functions palette. Maybe you could put in a feature request, here on the VIPM Idea Exchange.
  19. Hi @jb1592. One thing you can do is to give the 32-bit and 64-bit DLLs different names (or keep the same names but put them into different subfolders) and then pass the path to the Call Library Function so that the DLL is loaded at run-time.
  20. Hi Guys, That's a bit tricky and depends... The point of adding a name suffix is because LabVIEW has historically done a poor job of preventing cross-linking of files -- there was a global namespace for all VI's in memory. Since then (and recall that VIPM has been around for over a decade) LabVIEW added lvlib (and lvclass) files to help with namespacing. I'd say that the #1 use-case for adding the suffix/renaming is that when you're the developer of a tool, the installed version of that tool can mess up the development version of the tool. Of course, with the suffix/renaming you can get into situations where the source version of the tool accidentally links to the installed version, if you're not careful (since the installed versions will be in the palettes). As @HB65093 mentioned, when you're creating a Quick Drop, Project Provider or other LabVIEW plug-in, sometimes the renaming gets in the way of things working properly. And, as @hooovahh mentioned, the renaming messes up dynamic dispatch calls, since the VI name is critical for LabVIEW to identify the override methods. For me personally, there are many cases I do not add a suffix/prefix during the build process, but I usually leave this setting ON by default unless I want it OFF. @hooovahh - have you had any problems *not* adding the suffixes? If not, then it's probably not a problem. I'm really enjoying hearing from you all about what works well (or not) and why!
  21. Glad you got this working and sorry for the delay in response.
  • Create New...

Important Information

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