Jump to content

Jim Kring

JKI Team
  • Content Count

    1,513
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by Jim Kring

  1. > the state machine could used some Linked Input Tunnels for the cluster of data, string states, and error data, through the case structure and event structure We considered that and it might still is probably a good idea to add this. The reason we never added this (besides it not existing in earlier versions of LabVIEW) is because we generally use the Duplicated frame feature instead of Adding a new frame; so that the nodes, comments, and coloration are automatically copied. For example, when a new category is created, you can copy the "New Category" frame and get the comment, coloration, and Add States node for free. That said, there's no reason that these are mutually exclusive (the tunnels can be linked and we can promote the best practice of copying frames rather than adding them). I've also been thinking that it'd be good to have a JKISM helper tool for adding new frames, so this issue would become moot. > Also I'm a fan of having cluster initialization happening outside the while loop. This is the stuff normally found in the Data: Initialize. I tend to have lots of data and it doesn't always fit in that case. Adding it on the outside also makes it easier to add new data. This also cuts down on the number of uninitialized shift registers which can lead to problems if you aren't careful. I'm assuming you're referring to having a typedef'ed cluster like this: And, then possibly creating a subVI for the data initialization code (setting the default values etc.)? This is another good idea. The reason we didn't do that in the template, is because we wanted the template to be merge-able (and not have any subVIs that required modification), so that it could be dropped onto the block diagram. We do have templates that have the data initialization outside the loop in a subVI. It's relatively trivial to create a constant, convert it to typedef, and wrap in a subVI. > Which brings me to another possible improvement. The error shift register could have an Error In on the input instead of being uninitialized. Oh and if you do add an error in, it would be nice to have an Error Out, and to wrap the while loop in a case structure that does nothing if there is an error coming in. Another great idea! We didn't do this in the template that gets dropped from the palette, but we have other templates that do have this, such as the Process.vi template in the JKI State Machine Objects: We didn't add it to the template in the palettes, since it's so easy to add. But, I'd be curious to see in practice how often people would want to add this error handling "harness" vs. people who would want it removed. Great discussion!
  2. These are all great ideas, Brian. I was sitting next to another JKI engineer on the plane-ride home from the America's CLA Summit and we were discussing similar things. In particular, we discussed the importance of being able to log states and turn this on/off dynamically. I've got some ideas for how this might be accomplished. Also, I think that the JKI State Machine Objects design pattern can possibly address some of the other needs for sharing data and communicating across multiple processes. I've got some more work to do to get the examples/templates out and get some videos posted. Stay tuned and thanks for being part of this conversation and development.
  3. Hey Brian! Thanks for taking the time to comment on this. The JKI State Machine was just open sourced and we *are* currently looking at possible new features and updates. Are there some things you're especially wanting? -Jim
  4. Hi Sara, Yes, there's an undocumented and unsupported way to do this: "C:\Program Files\JKI\VI Package Manager\support\VIPM File Handler.exe" -- "/command:build" "/source:" "/QUIET:T" The official supported way to do this would be to create your own VI that calls the VIPM API VIs and build your VI into an EXE. I hope this helps, -Jim
  5. Yes, 2014 SP1 will be pushed to automatic updates soon.
  6. Are you able to attach your test (dummy) packages to see if we can reproduce the issue? Thanks! Also, can you check to see if this problem is resolved in VIPM 2014 SP1 (2014.0.1). Release notes are here: http://support.jki.net/entries/60428015-VIPM-2014-0-1-Release-Notes
  7. Hey Chris, If you're looking to create your own root-level menu, we support this with the Custom Category feature. The "RSC" thing is just part of the package name. And, I would not recommend trying to replicate what the rsc_palette packages do, since it involves a lot of arcane and complex stuff that I can't remember all the details about right now and I'm one of a small handful of people in the world who understand the details -- I don't recommend joining that club
  8. Hi David: I've emailed you off-line about some possibilities for work-arounds to see if any might help your use case.
  9. Hi Sara: Hyphens (aren't allowed in the package name and) are converted to underscores. There is some history around why this is done, related to naming conventions and the hyphen being used in the package version/revision number.
  10. Hi Peter: Please use the contact us page and include your purchase receipt number we'll send you an updated version of EasyXML.
  11. Hey James, Thanks for your question: it inspired me to write up a short blog post on pinning packages Have a great weekend! -Jim
  12. Also, I should mention that there is another helpful tip: "Pin" packages that are manually added. “Pinning” prevents VIPM from removing the package after a Scan Project, if the package is not found as a dependency.
  13. Hi James, I've just updated the How to use VI Package Configurations (VIPC) help document to include some info about how to manually add new packages to a VI Package Configuration file. Basically, there's two ways: You can manually add packages to a VIPC file by dragging & dropping them from the VIPM Main package list into the VI Package Configuration window, as shown below: Or, you can right-click on the package from the VIPM Main package list and choose Send to Configuration, as shown below: I hope that helps!
  14. Have you tried turning off your firewall? Also, you might take a look at this document: Resolving issues with VIPM connecting to LabVIEW (and the section on "Configure the Windows Firewall")
  15. Hi Jonas, I'm sorry for all the troubles. Regarding the password-protected source libraries, thanks for the description and ideas for ways we could implement support. You're right that the build occurs in a difference context than the pre-build. I'll think a little more on this issue and ways we might be able to work around it. Regarding the path separator issues, which version of VIPM was used to create your older .vipb files? I'll see if we can reproduce it. -Jim
  16. Hi Carmine, No, EasyXML requires that a data structure be passed in. However, there are some ways to make EasyXML and your data structures more flexible. If you change one of your clusters (or other any other LabVIEW types) to a string data type and add the "#xml" hashtag to the end (e.g. "TestResult #xml"), then EasyXML will return the data as a string. This is sometimes helpful if your structures have types that can vary. -Jim
  17. My guess is that you are installing the VI files under instr.lib and they are being found there and automatically LabVIEW is creating a default palette set for them. When you specify the installation location for the VIs, try adding an underscore in front of the main folder name, which will cause LabVIEW to ignore that folder (and LabVIEW will only look at the MNU files created by VIPM and not try to automatically add the default palettes for all the subfolders, too).
  18. Hello Carmine, I'm glad you figured out the solution -- yes, this is the approach. You're right that it would be nice to provide a more direct way to extract the data of interest, in some cases. Thanks!
  19. Can you send a screenshot of the contents of this folder: C:\ProgramData\JKI\VIPM\databases\LV 14.0\ni_lib_keyed_array\ Also, can you try exiting VIPM, deleting this file (below), and then restarting VIPM: C:\ProgramData\JKI\VIPM\databases\LV 14.0\package database info.pdi2 Note: Please replace "LV 14.0" above with the LabVIEW version your trying to install into. For example, maybe you're installing into "LV 13.0" (2013).
  20. Hi Scott, I can't seem to reproduce the issue. I'm running 1955 on Mac and click refresh mirrors and it tells me the list is up to date. I press "OK" and everything seems to work just fine. -Jim
  21. Great, I'm glad it's working for you now, Tim. Yes, VIPM does make this distinction (accessing vs managing a repository) a little tricky to grasp. Have a great weekend!
  22. With the release of VIPM 2014, package build specs are now named, e.g. "MyPackage.vipb" instead of simply a ".vipb" file in the package source folder. This introduced an issue (ID# 16100) with the VIPM API for programmatic package builds and build spec reading/writing. This issue was resolved in the new release of the VIPM API version 2014.0.0.38. You can install the new version using VIPM here: http://vipm.jki.net/...ki_lib_vipm_api
  23. There's a new build of the VIPM API (that includes a fix for this issue) available for download, here: http://vipm.jki.net/#!/package/jki_lib_vipm_api Please let us know how it works for you: -Jim
  24. Hi Tim, > There seems to be no way to edit this "Location" from this dialog; nor can I find ANY place to edit this value. SUGGESTIONS? You're right. You can't edit the location once it's been added to VIPM list of repositories under management. You'll need to go into the options to remove it and then re-add it: Go into the Tools>>Options (menu) >> Repository Manager (tab), select the repository, click the red X to remove it, then click the plus to add the new one.
  25. This is a package on the LabVIEW Tools Network. I would contact NI's support, here: www.ni.com/labview-tools-network/support/
×
×
  • Create New...

Important Information

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