Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi Norm, Sorry about the trouble. Is it possible for you to send us (via email, if you prefer) a VI Package source folder that causes the problem? This would be a big help for us to debug the issue. Thanks, -Jim
  2. Hi Toby, Thanks for reporting this. I can reproduce the issue and have filed a bug (Case 7175). Thanks, -Jim
  3. Hi Arne, That's great news! I think I know what the problem/bug is. I'll file a bug for it and report back here with a known issue link. Thanks, -Jim
  4. Hi Arne, Can you please try something? In your destinations: change.. \Categories to... \menus\Categories Also, change... \Controls to... \menus\Controls Then rebuild your packages. I think that this should fix the installation issues. Please let me know. Thanks, -Jim
  5. Hi Arne, First, I apologize since this might be hard for us to debug without a Swedish Windows XP for us to test. And, thanks for the kind words -- we're happy that you like VIPM Can you please create a new VI Package with just a few dummy/test VIs and post it here for us to examine? I'd like to know if the problem is in the VI Package (specifying where to install the package) or in VIPM (in interpreting where to install the package). Also, in addition to posting the VI Package, can you also zip up and post the entire VI Package Source folder (including the .vipb file)? Thanks, -Jim
  6. Hi Mads, It's on our radar and we're working on it. Thanks, -Jim
  7. Hello. If you are an EasyXML customer and this is affecting you, please contact us and we'll send you a version of the software with a fix. Thanks,
  8. You're welcome, Matt. Let us know if you find any other limitations or if you think of ways that we can make EasyXML better (or easier). Cheers, -Jim
  9. Hi Matt, We've fixed this issue. I'll send you an email with details. Thanks, -Jim
  10. Yes, "" and "" are equivalent. DOM parsers and EasyXML should have no trouble with either format.
  11. Hi Matt, Are you concerned about the difference between the empty elements "" and "" or the difference in the numeric precision of the "VALUE" attributes? Thanks, -Jim
  12. Hi Matt, I'm not sure what you are seeing that makes you think that the result is not correct. When I run the example you sent me, with data populated in the arrays, I get: MeasurementExample_Reversed_JK01.vi In order for me to be able help better, can you tell me what are you seeing vs. what you expected to see? Thanks, -Jim
  13. Hi Toby, Thanks for the feedback. I've created cases for these: Case 7056 - Mass compile window resizes incorrectly Case 7057 Mass compile path should be larger for Vista Also, I'm happy to hear that you're using VI Tester. We look forward to hearing about your experiences using it for unit testing Thanks, -Jim
  14. Hi Ted, I'm sorry to hear that you're having issues. It's possible that this might help: After upgrading to LabVIEW 8.6.1, why can't VIPM connect to LabVIEW? Regarding labpython, make sure that you have the ogrsc_dynamicpalette package installed. This is a dependency of the labpython package, but it is not declared correctly by labpython, so it doesn't get installed automatically by VIPM. Please let me know if this helps. Thanks, -Jim
  15. Hi Matt, Here's the solution, below. Note that your XML was not valid, as there must be only one root-level element. To fix this, I wrapped "MeasurementX" and "MeasurementY" in an element named "Root" (). MeasurementExample.vi Please let me know if you have any more questions. I'm happy to help. Also, there's some detailed documentation located, here, although sometimes it's a little tricky to see how every XML structure maps into EasyXML's LabVIEW structures. -Jim
  16. Hi Kennon, Thanks for the info about this. That's a big help and it's nice to know that (1) it's not an issue with VIPM, (2) it's not affecting all LabVIEW users who upgrade, and (3) it's been fixed (in a future release). Thanks, -Jim
  17. Hi Mikael and Jim C, This is a very interesting discussion. I like exploring new ideas for ways to use and improve the JKI State Machine. It seems, Mikael, that you are using the JKI State Machine as a hybrid between a finite state machine (where each state determines the next state) and a queued state machine (where states are queued up and then executed). For example, each of the work steps (Test A, Test B, Test C, Test D) is driving the subsequent work step, but only when there is nothing left on the queue. What I would usually do in type of situation (as Jim C suggests) is define some macros that invoke all the needed functionality. For example, for a full test, I would create the following macro: Macro: Full Test ---------------- Test A Test B Test C Test D UpdateGUI And, if a half-test is required, I would create the following macro: Macro: Half Test ---------------- Test A Test B UpdateGUI The reason I prefer macros, and defining as much of the sequence up front, is that it is very readable. I don't have to scroll through every frame to try to reverse engineer the order in which my state machine will execute. Now, I see that you are using the Endevo GDS UML tool to reverse engineer a state diagram Still, I think that making work steps define other work steps, when it's not absolutely necessary, obfuscates the code by "hiding" pre-determinable sequences (macros). BTW, the explicit call to "Idle" that you make is not required, if it's the last thing you want to do. The JKI State Machine will always go to an "Idle" state when there is nothing left on the state queue. Thanks, -Jim
  18. Great! I'm happy to hear that it was a simple fix.
  19. Hi Eric, Yesterday, another VIPM user had trouble after upgrading from 8.6 to 8.6.1. For some reason this adjusted the Exported VI list. Please see here (the last step of the instructions) for more info: Why do I get Error Code 1032 when I try to install some packages? Please let me know if this works or if you still need more troubleshooting help. Thanks, -Jim
  20. Another possibility is that VI Package Builder could ask you to Apply your VI Package Configuration when you open a VI Package Source folder and it could ask you to Scan for Dependencies before you close your VI Package Source folder.
  21. Hi cbL, I figured that I would expand on Justin's response a little... We're currently working on (and JKI engineers are internally using) new features that will give VIPM visibility into your LabVIEW projects (*.lvproj). For example, VIPM will be able to automatically apply your VI Package Configuration before you start working on a project and it will be able to scan your project to see if there are any changes to your VI Package Configuration when you close your project. You'll also be able to take advantage of these features when working on your VI Packages by creating a LabVIEW Project for each of your VI Package source files. (Note that the VI Package Builder in VIPM currently only asks you to apply your VI Package Configuration before you build your package.) I guess that we could go one more step and prompt you when new dependencies are found and let you configure them as either an internal or an external dependencies. How does this sounds? Thanks, -Jim
  22. Hi Ben, Creating packages from reusable base classes is a great way to distribute them to your team and other projects. Regarding inheriting from a base class, in order to set a class as a parent, the new parent must be in memory within the project -- that's just a limitation of LabVIEW. Typically, I'll just add base classes into a virtual folder, right from the get go. This provides easy access to the base class methods. Thanks, -Jim
  23. That's a great idea -- I'd love to be able to see a dependency graph, too. Displaying the graph in a diagram would be nice, but I'm imagining that it would take a bit of work to do (e.g., in a Picture Control). Maybe a simple solution, for starters, would be a "dependency browser" that lists all the dependencies of a package. Then, if you double-click on any package in the list, it would "navigate into" that package and list its dependencies. This solution would let you crawl the dependency graph, but wouldn't really allow you to visualize all the dependencies (e.g., in ways that make things like circular dependencies obvious or see all packages that depend on a given package). Can you identify some of the questions that you'd like to be able to answer and what the answer will enable you to do? For example, one question that I'd like to know is: "Which packages (or projects) depend on a given package?" This would be useful for knowing how changes to a package would impact other packages (or projects). Note that we're actively working on tools that will help you answer such questions, so it's a great time to send us your ideas Thanks,
  24. Ya, I agree with these thoughts. I would try to standardize on a short organization/company prefix for your packages (maybe "viewpoint" or "vs"). Otherwise, it just pushes the problem to a later stage.
  25. Hi Ben, Sorry for the trouble -- this is quite a pesky Windows bug/limitation. I think that you might be able to set the temp directory, as follows: In VIPM's configuration file: C:\Program Files\JKI\VI Package Manager\VI Package Manager.ini find the "VI Package Manager" section: [VI Package Manager] and add the following key: tmpdir=C:\Temp Note that this might fix the problem of building the package, but won't solve any problems associated with installing the package's files, if the install location path names are too long. Thanks, -Jim
  • Create New...

Important Information

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