Jump to content

Jim Kring

JKI Team
  • Content Count

    1,435
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by Jim Kring

  1. Hi Fabiola. That's fair. I guess I'm trying to figure out the volume of support calls. The solution for users is to upgrade VIPM (assuming they can), so the presumed support impact is low. Of course, that's unknown to you (or do you have information/data about it actually being a support problem)? Hi Chris. We haven't officially abandoned Mac and Linux. We may decide to release a new version for Linux and Mac, if there is enough customer need.
  2. Hey Fab, Users of older versions of LabVIEW are able to easily upgrade to newer versions of VIPM -- right now, the error dialog users see when they try to open a package that's an older format could be more helpful in suggesting an upgrade (via check for updates, right in that workflow). Is upgrading to newer versions of VIPM a problem for your users? Do you have data on how many of your users can't upgrade to the latest version of VIPM (for one reason or another)? Do you know what's preventing your users from upgrading? I'm sure you can appreciate that investing development resources in features that disincentive upgrading, in most cases, probably doesn't make good business sense. It probably makes more sense to invest those resources into features that make it attractive for users to upgrade. Of course, it's all a balance. -Jim
  3. Sorry for the delay in response, James. I think this could (in part) be because VI Tester has not been mass compiled. If you mass compile it, does it launch faster? Or, do you think it's a function of the number of tests in your project? -Jim
  4. JKI REST Client is a HTTP client library for connecting LabVIEW applications with RESTful web services. JKI REST Client provides a client implementation of HTTP protocol that is specifically designed for integrating LabVIEW applications with web services. JKI REST Client augments the LabVIEW native implementation of HTTP by adding several features that make it better fit for connecting with RESTful web services than LabVIEW native HTTP client. HTTP REST Client Homepage Get HTTP REST Client
  5. I just fixed the Knowledge Base link, thanks. Yes, that's the work-around we're proposing. For what it's worth, the bug traced back to a cluster constant on the block diagram that had the wrong cluster order for Client ID and Server ID. It was very hard to track down, since it looked like everything was working -- the swapping of values actually happened right at a dynamic Call by Reference of a VI that has its FP controls hidden (so can't debug) and BD password protected
  6. Hi Steen, David. Big apologies for the long delay in resolving this issue -- I wish I had a good excuse for that, but I don't, other than it was tricky to track down the root cause and it wasn't prioritized. Fortunately, there is a simple work-around for VIPM 2014 - VIPM 2018 (see Knowledge Base: Deactivation Fails for Licensed Add-ons built with VIPM) and a fix coming in VIPM 2018f1.
  7. VI Package Manager (VIPM), JKI's flagship toolkit ships with LabVIEW and allows you to discover, create, and share LabVIEW add-ons. VIPM gives you instant access to the add-ons on the LabVIEW Tools Network. Get VIPM, Learn More Release Notes, Knowledge Base, Idea Exchange
  8. This issue has been resolved in VIPM 2018. Stay tuned and let us know if you need early access.
  9. Caraya is an assertion and unit test framework for LabVIEW that is simple and fast. It takes a whole new approach to unit testing; your VI is your test. Caraya allows you to convert your manual test VIs you use to debug your code into unit test cases with nearly no effort. This significantly lowers the barrier to systematicaly write unit tests for your project leading into improved overall code quality for real-world projects where developers don't always have the luxury to write unit test cases first. Caraya Project Homepage Get Caraya
  10. Update: I've added a little bit of documentation about this, here: https://github.com/JKISoftware/JKI-EasyXML/blob/master/README.md#reading-raw-xml-into-strings-using-the-xml-suffix-in-string-labelname
  11. Update: I've added a little bit of documentation about this, here: https://github.com/JKISoftware/JKI-EasyXML/blob/master/README.md#reading-raw-xml-into-strings-using-the-xml-suffix-in-string-labelname
  12. Hi James, Thanks for posting your observations and concerns. We have made no plans to stop development or fixing bugs -- yes, things have slowed down a bit. For what it's worth, I fixed a couple bugs and made a minor performance improvement last week, that will make it into the next release. Thanks for your patience and feedback. Is there anything critical on your organization's list of needs? -Jim
  13. The RSS Feed URL changed. Try this one: https://lavag.org/rss/forums/1-lava-forums/
  14. That's a great question, Brian! I tend to agree with your observations and thinking. I'll check in with others at JKI to see if I learn more about the history behind this and any corner-cases where this serves a useful purpose.
  15. Hi James, Here's the reasoning behind the current behavior: - If a user installs a package, it gets added to the package cache (regardless of where it came from: double-clicked from the desktop or downloaded from a repository) - The package list gets populated from a combination of the repository and what's found in the cache. Now, it might make sense to tweak this behavior, such that deprecated packages (as defined by a repository) are flushed from the cache. I think that this behavior would meet your needs and wouldn't have any negative side-effects (except that people who choose to actively install a deprecated package would need to download it again, since it wouldn't ever be cached). Additionally, it might be helpful if unpublished packages (when we query the repo and we detect that it was in the repo previously but no longer in the repo) were flushed from the cache. This would be a little trickier, since we would have to catch the event at the time the package is unpublished (we would see the package is published and then it disappears from the repository's package list). I'll pass the ideas along to the JKI team.
  16. Hi James, There's a setting for showing or hiding deprecated packages. Do you have "Show deprecated packages" enabled? If this setting is FALSE, then I think all deprecated packages are not shown in the Install Other Version list.
  17. Hi Jim: Depending on how eager you are to play with this, I could get you an early release to test and provide feedback. Jon: Same goes for you.
  18. Yes, were in the process of making some design decisions -- I'm also in Roma for the CLA Summit and am presenting tomorrow... One thing that we're evaluating is the impact of changing the process VI to be Dynamic Dispatch (with the ability to call or override the parent). This changes slightly the mechanics of process registration and synchronization. Additionally, we're working on a full scripting API to allow programmatic creating, editing, and inspection of JKI SMO classes. This aims to enable creating user interface tools that simplify development. We've been doing this experimental development outside of GitHub to avoid a lot of noise. I'd be happy to loop you into what we're working toward and some of the open design questions.
  19. Hi Jon, Thanks for following up. What's on GitHub right now is partial -- we are working to clean up some more stuff and get it released. It's taken a little bit longer than we thought, because of some other administrative and technical stuff we've had to take care of, but I think we've got that worked out. Now, we're ready to start including a lot more people in the discussion and enable community contribution. I'm prepping for the CLA Summit in Rome, the week after next, and getting this next release pushed out is a big part of that. -Jim
  20. Hi Leif, It sounds like it could be a bug. Please use our contact form to email our support so that we can discuss privately, since the conversation might involve exchanging some test data that could be sensitive. -Jim
  21. BTW, we've just created a new 3.0.0 release on GitHub, here: https://github.com/JKISoftware/JKI-State-Machine/releases/tag/v3.0.0 The package will be released for download in VIPM shortly.
  22. Hi, Brian. This is a timely question. JKI recently announced several open source projects, here: http://jki.net/open-source The JKI State Machine is one of them and will be released under the BSD license. We've actually already put the source code on GitHub. We'll be releasing the package on vipm.jki.net for installation with VIPM, shortly.
  23. Hi David, In order for VIPM to build this package, you'll need to move your driver library outside of instr.lib and re-save all the VIs in your project folder. You are stuck between a rock (VIPM can't have a package source folder located beneath LabVIEW) and a hard place (instr.lib is a Symbolic Path and all the files are linked to each other using paths relative to instr.lib). -Jim
  24. > 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!
×
×
  • Create New...

Important Information

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