Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi Bob, I'm still using 1.7 myself and am not sure about the problems you're describing. Can you post a link to your post in the NI forums, so we can follow along there? Thanks, -Jim
  2. Hi Jeff, I think that build 1893 (pre)released in the VIPM Labs addresses this issue: Case 14456 - "Remove Dependency" button doesn't work. In the VI Package Builder window, clicking the "Remove Dependency" button does nothing. It should remove the selected external dependency (and make it internal). - This has now been fixed. http://support.jki.net/entries/24071293-VIPM-Labs -Jim
  3. That's a good idea. You're right that this new template is really just an example associated with a presentation that's designed to help inspire and get you started in creating your own template. I agree that it would be nice if there were an official template :-)
  4. No, but that's a fantastic idea! We use and love this framework (obviously) and have a lot more we could talk about. When did you evolve the template at all for your application? Did you hit any limitations? There are (hopefully) some cool features coming in LabVIEW 2013 that will make this design pattern even better, so stay tuned.
  5. Thanks for the response. I'm glad this looks like a good solution. Let us know how it goes!
  6. Hi Martijn, Yes, I think you could add a post-install custom action VI that compiles your shared lib via the command line at install time. But, would configuring the Call Library Function node with a .* (instead of ".DLL") file extension maybe solve your issue? What I mean is that, if you have the platform-independent shared libraries in the same folder and use the ".*" convention in the CLF node, then LabVIEW will load the right one for the target platform? For example, you could put "mylib.dll" (Windows) and "mylib.so" (Linus) side-by-side. See this doc for more info: http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcodeconcepts/configuring_the_clf_node/ I hope this helps, -Jim
  7. Hi Peter, I think that our support team can provide you with a fix for the period/comma issue. Can you please contact them, here: http://jki.net/contact Thanks, -Jim
  8. You can use VIPM Pro to create a VI Package Configuration file -- it does exactly what I think you're trying to do. Here's some good information about how to use this VIPM feature: http://support.jki.net/entries/20646062-how-to-use-vi-package-configurations-vipc -Jim
  9. Hey Jason, Take a look at the VIPM API. It should have everything you need to programmatically check which packages and versions are installed on your system. -Jim
  10. I don't think that this is supported in VIPM or in LabVIEW (a quick test of the palette editor shows that you can't add an LVClass). However, if you create a "dummy" VI that has the LVClass control on the front panel, you can add it to your palette and configure it to Place VI Contents (so that the contents of the VI [the LVClass control] are dropped rather than the VI itself). Set the "dummy" VI's icon to look like your LVClass control and you're all set. Does what I've described make sense?
  11. You can use the OpenG VI called "Set Data Name" (it's inside the "LabVIEW Data Tools" / "lvdata" library) to set the name of the cluster.
  12. Can you post an example VI that shows the data you're trying to convert to/from XML, along with the error message? I suspect that it's not related to which EasyXML version you're using, since downgrading didn't resolve the issue.
  13. On trick you can use, is to use a string data type in LabVIEW for an XML element (I think you also need to name the string with an " #xml" suffix). The result is that the raw XML data will be read into/from the string and then can be processed in a separate step. This is especially helpful if elements (having the same name) come in a few different flavors (sub-element types and structure).
  14. I'm not totally sure why you're example was failing, but I suspect it's a bug or a corner case (by bundling the variants into a cluster, it effectively creates a cluster with two identically named elements, which is sort of a no-no since cluster elements should really have different names -- easyxml uses the cluster element names when mapping into the xml data). I've forwarded your example VI off to our product support team, to look into.
  15. Here's a slightly tweaked version that should work for you: Let me know if you need anything else.
  16. Yes, it does use OpenG VI "Format Variant Into String" for at least flattening some data types, but not all types.
  17. You're very welcome, and I'm pleased to hear that EasyXML has saved you time and effort on your project work. Thanks for sharing that feedback
  18. Jim Kring

    Idea for VITester

    I'm not a unit testing expert, but I'm pretty sure that unit tests should not depend on other unit tests. You can certainly reuse test support code, but there should be no external statefullness that an individual test relies upon. I'll ping some others at JKI, to see if there are any more detailed answers that could be helpful to your testing scenario.
  19. Hey crelf, Yes, I believe that the current implementation of EasyXML does always preserve ordering when converting between LabVIEW and XML data. I don't see any reason why this would ever change, but we can't guarantee it, since (as you've mentioned) the XML specification does not support ordering of elements. -Jim
  20. Hi crelf, What I meant is that if the XML isn't well-formed, then EasyXML will output an error. You're right that if the XML contains extra data that's not in the LabVIEW data, when it will continue without error. -Jim
  21. I think that this might be the type of solution you're looking for: It outputs the following XML. <Variables> <Var_1>true</Var_1> <Var_2>0</Var_2> </Variables> Note that this uses some OpenG VIs that are probably already installed on your system (since EasyXML depends on them).
  22. JKI engineer Jack Dunaway wrote a great blog article called "Don't Throw Away Your "Throw-Away" Code" that talks about how to leverage the test code you write as your construct your VIs. Check it out and see if it answers any of your questions. To answer your last question, "Why would I want to retest a working VI later?", because often times VIs don't always work later, as improvements are made to the code or various other conditions change (like upgrading the source code to a newer version of LabVIEW). Having unit tests that you run frequently (especially before building your exe) lets you know about these "bugs" in your code before you ship it to your customer. -Jim
  23. One thing I'd add (for consideration) is a link to, and quote from, a related Q&A posted on Stack Overflow: Question: How do you unit test private methods? Answer worth considering:
  • Create New...

Important Information

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