Jump to content

soupy

Members
  • Content Count

    49
  • Joined

  • Last visited

Everything posted by soupy

  1. Short answer is no. you can't easily modify dependency locations. Longer answer is yes. you can modify environment search paths to point to the new target and delete the old target files to force re-linking, but this is really the hard way and it's going to get you into re-linking trouble/hell. Correct answer is that you're not using vi packages correctly. The code that goes into a VI package should be able to stand on its own. You should be able to debug/test/validate all VI package source code before you build it into a package. Think of a VI package as formally released reusable sou
  2. agreed. this is sort of a hack. i wouldn't be surprised if this functionality broke in future labview versions. I'd suggest not ignoring all errors coming out of this so you'll know if something changed. instead, ignore only error 1 coming out of the close VI
  3. yeah, close functions should always execute. you wouldn't want to have a shutdown error and leave thing allocated. you should keep this in mind when making your own tools. my teams has formalized our style to always call this VI "destroy.vi". it should have an 'X' on the icon and should always execute even if errors are passed in and should pass through incoming errors. This follows the NI paradigm. We believe that the more our code resembles NI code style & interface, the more likely it will get reused by ourselves and others (less learning curve).
  4. here ya go. this only works if your cluster only contains user events but it'll close all data types. if your cluster needs to hold more than user events, you could probably get around things by storing user events in a sub-cluster.
  5. one of my guys just got his recently. it took a month the get the test results back. I hope you have enough time to take the exam and make the summit.
  6. cross posted here https://decibel.ni.com/content/message/64013
  7. i'm doing something, but i don't know what to call it. is this an accepted design pattern? background: i have a configuration class for my application the configuration class contains paths to external (excel) files you must parse out the external files and put their information back into the configuration class. i refer to this step as "parsing" i'm passing the parsed configuration class over the network to an RT system, so my configuration class can't have any dependencies to non-RT stuff (e.g. Excel (ActiveX)) everything is dynamic dispatch so i can get some reuse out of this desig
  8. i don't think that we currently use more than one ES per BD, If we do, the secondary ES is in a subVI. Will things be broken if the subVI is inlined? (I assume it would) I'm quite concerned that this breaks existing code. The LV upgrade eval process is typically riddled with surprises and this just adds another pothole. Especially since the only way to fix this is to overhaul your application architecture which isn't exactly an easy change.
  9. spacex is donating an "occupy mars" t-shirt and a model rocket
  10. ah, that's the term i was looking for. yup. makes total sense now. better to have obscure names than hard to find bugs. thanks!
  11. so everyone knows that a parent and child class cannot have VIs of the same name unless they are dynamic dispatch. The compile will fail if you violate this. so, my question is, why is this restricted? Is there a technical reason that this can't be done? I ask this because i am working on a set of configuration file classes that are written directly to file. To deal with non-trivial permutations, i'm following the recommendations here (http://thinkinging.com/2007/04/14/supporting-multiple-versions-of-a-file-format/) and including a revision number in every class, subclass and child class.
  12. I sent your articles to my colleagues in an email titled "egoless programming" and they thought it was a joke. I've got a lot of work to do here...
  13. this is great! i'll be testing this immediately! I'm guessing that this will eventually be released publicly once your release cycle comes around?
  14. i'm working on moving my large library of reuse code (2300+ VIs) into VI packages. because of the scale of my code base, i'm forced to migrate over a span of time (measured in months). This is leaving me open to configuration issues (as a consequence of using configuration management ). does anyone have any advice in this area? my issue is described in much more detail here http://forums.jki.net/topic/2103-rename-vi-dependencies i think that most of my issues can be solved by implementing this http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/ Th
  15. putting in a blank password make the "password type" switch back to "none" it may work if they add "locked (no password)" to the "Password type" dropdown
  16. I've got pro. I don't think it's the same as you're doing. It requires the NI licensing and activation toolkit. Not going to be buying that for something that is easily accessible via property nodes.
  17. it would be nice if the "locked" setting was available as a standard VIPM package setting so you don't have to keep track of it in postbuild scripts. have you suggested this to them on their idea exchange?
  18. I second this recommendation. I read it while flying on a business trip and my OOP style has never been the same.
  19. oohhh...we gotta get one of those....PO is in work...
  20. great article! I love how it logically lays everything out. If you wanna see more cool hardware pics, here is an article on our test site. http://www.wired.com/autopia/2012/10/spacex-texas-rocket-test
  21. yeah, those were super annoying. i think at some point i did something to make this stop happening. i don't see the setting in the "my ni" section. next time they call you, try asking them nicely to stop doing it. it never hurts to ask (nicely).
  22. the big benefit to the classes is the ability to interact with NI personnel. you get a chance to ask those misc questions that aren't openly addressed in the forums. priceless! I personally squeeze every minute out of those guys that i can. I personally don't think that the class manuals teach much that can't be found in other existing documentation. of course, if you're looking to learn a particular skill, you'll learn it much faster in the class. If you don't need to lean it quickly, just casually research it and integrate it into your current projects. I don't think that taking classes ar
  23. What we want: Seeking LabVIEW Programmer with 1+ years experience and/or CLD certification. NI hardware experience is a huge plus. Position open immediately What you'll do: Design and maintain National Instruments SCXI/PXI data acquisition systems Identify hardware requirements and compatibility Assemble, setup, and validate DAQ hardware configurations Troubleshoot DAQ hardware related problems Benchmark system performance and performance margins [*]Design and maintain LabVIEW-based applications and utilities to support propulsion testing operations Software testing, quali
  24. There really isn't a correct way to do this as long as you steer clear of the following 'gotchas!' if you have a class in a library, renaming the library will reset the class mutation history. this is only a problem if you are flattening class data and saving it to a file or passing it over the network. this isn't a reason to avoid packaging classes in libraries, just a warning not to change the library name [*]if the case that you are passing data between different top level applications, put the type definition for that data inside a library and not a class! placing the typedef in a cl
  25. What we want: Seeking LabVIEW Programmer with CLD or 3-5 years experience What you'll do: Design and maintain National Instruments SCXI/PXI data acquisition systems Identify hardware requirements and compatibility Assemble, setup, and validate DAQ hardware configurations Troubleshoot DAQ hardware related problems Benchmark system performance and performance margins [*]Design and maintain LabVIEW-based applications and utilities to support propulsion testing operations Software testing, quality assurance and benchmarking Performance tuning, improvement, usability, and aut
×
×
  • Create New...

Important Information

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