Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. 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).
  2. 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.
  3. Here's a slightly tweaked version that should work for you: Let me know if you need anything else.
  4. Yes, it does use OpenG VI "Format Variant Into String" for at least flattening some data types, but not all types.
  5. 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
  6. 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.
  7. 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
  8. 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
  9. 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).
  10. 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
  11. 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:
  12. Have you tried changing your preferred mirror to not be Japan?
  13. It looks like a problem with SourceForge's mirroring system. I see both files, here: http://sourceforge.net/projects/opengtoolkit/files/lib_error/4.x/ Note that this was just released over the weekend (I think on Saturday), so maybe the Japanese mirror will get updated soon.
  14. Would just putting "VIPM 2011" (including version) in the User-Agent header field be sufficient?
  15. Hey Jason, Here is a manual work-around, that will should fix the toolbar issue in 2011. VITester.ini.zip Place the attached VITester.ini file in the following location: \resource\Framework\Providers\GProviders\VITester.ini Hopefully, that'll do the trick. Let us know. -Jim
  16. Hi Brad, I'm glad you got this working. We'll be working on a fix for a future version of VIPM. Sorry for the trouble. -Jim
  17. Hi Brad, Sorry for the trouble. I think there is a bug that is causing VIPM to think that the 4.x versions of the OpenG libraries can be installed onto LabVIEW 8.6. However, the 4.x versions of the OpenG libraries require LabVIEW 2009 or greater. To resolve these issues, you should try to manually install the 3.x versions. To do this, open the Main VIPM Package List and type "OpenG" into the searchbox. Make sure that you have LabVIEW 8.6 selected in the LabVIEW version selector drop-down. Then find the packages you want from the list -- select all the "OpenG" ones and then click the Install toolbar button. Please let me know if that works -- on our side, we'll look into a fix for this issue.
  18. Winner, winner, chicken dinner!
  19. Hey Dan, What are the requirements (in terms of XML data structure) of an Excel XML Table? Also, there are a few ways to represent ordered arrays of data. Here's one way to do it (using an attribute to store the station number): 1 2 3 If you really want to use the exact XML schema you showed, then you'll need to use a Variant representation of your cluster and construct its elements and their names dynamically (e.g. using the OpenG LabVIEW Data Tools library for variant manipulation). -Jim
  20. Hi Kim, There is a bug in the dependency declaration of the LabPython package. It should declare a dependency on ogrsc_dynamicpalette ">= 0.2" instead of ">= 2.0". Go ahead and install version 0.19 of ogrsc_dynamicpalette and everything should be fine Thanks, -Jim
  21. Hi bananacluster, 1) I can send you a copy of the demo version that works with Windows 64-bit. Please contact us and we'll email you a link. 2) You need to install TortoiseSVN first. 3) The JKI TortoiseSVN Tool is not a LabVIEW Source Code Control Provider plugin -- it adds items to the Tools>> menu. You can watch a short video to see how it works, here: http://jki.net/tortoisesvn-tool Thanks, -Jim
  22. Jim Kring

    Loading Tests

    Hey Dan, My suspicion is that tests inside of auto-populating folders are not being found by VI Tester. Can you try adding them to a "regular" project folder? Thanks, -Jim
  23. Hi, Are you married to the schema designed by your colleague in Pearl? IMO, it's pretty difficult to deal with, in the case where you want scalability of the number of bits. For example, it would be hard to validate it using a XSD or DTD.One solution might be to use attributes, like this: <REGPGMS> <name>R0</name> <bit i="0">0</bit> <bit i="1">1</bit> <bit i="2">1</bit> <bit i="3">1</bit> <bit i="4">0</bit> <bit i="5">1</bit> <bit i="6">0</bit> <bit i="7">1</bit> </REGPGMS> Thanks, -Jim
  • Create New...

Important Information

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