Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About Autodefenestrator

  • Rank

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since

Recent Profile Visitors

961 profile views
  1. So I wanted to make a VIM that was essentially "Convert input into 1D string array". If you passed it a 1D array of anything it would convert each element to strings (similar to the debug VIM that ships), but passing in any scalar would do assorted things depending on the scalar (single item array for things like numerics, but a Path would split into each component, and different methods for other types). I thought it would be a good idea to have an option that if an enum is passed it, the array passed out would be the list of all of the options converted to strings. They way to get thi
  2. I'm currently doing some driver creation in advance of getting actual hardware hooked up. One of the things I have to do is use a TEC temperature controller. This will be used on multiple stations with identical functionality, but we sort of "scrounged" for instruments, so we couldn't get the same model of TEC controller everywhere. We have 3 different ones (Newport 3700, Keithley 2510, ILX LDT-5980 if it matters). What I'm trying to figure out is if the PID constants that can be set on these devices are universal or not. They'll all be using the same sensor (10K thermistor) and t
  3. For reasons of which I am not 100% aware, the decision was made before I was brought on that direct data write access to the local database would be disallowed, and instead it would only allow stored procedures to be run that targets the local file. I think it's done because of a combination of reasons (encapsulation of the table structure, a security level flag we have to attach to each piece of data in the DB for reasons I won't go into, etc). I admit it would simplify things to have direct DB writing as the data storage. I am at this very moment only attempting to design a universal d
  4. I work in an environment where we really don't ever want to lose test data once we've taken it. Many of the tests we do are either destructive (i.e. one time only, then the DUT is dead) or require very long test times that we don't have the production bandwidth to spare on a retest if we can avoid it. We already have a 3-step system to ensure test data isn't dropped due to network or database problems. Instead of just issuing a command to write to the database when the test completes, we first write the data to a local file on the hard disk. Then have a compact database running on the l
  5. I work with a small-ish (5-6) team of developers at my company. We're trying to update and improve a lot of our old test station software and we've decided to try using TestStand for sequencing instead of writing a custom sequence for each test station and product, or trying to write a generic but highly complicated sequencer ourselves that could work for every test station we have. In order to keep things as modular as possible we'd like to come up with a set of rules/guidelines that we all agree to follow in some manner, so we can assign one person to develop for tests using one type of
  6. I actually didn't see that table before, I was looking at a different page. I think that the reason "mainstream support is ending" would probably be a good enough reason to push through getting some new versions in. They may see that it's August 2015 that it ends officially and try to push it out a quarter or two but that could work. The non-IT guys can understand that a lot better than developers wanting the newest version of something because it's "shiny".
  7. Ah, I didn't know that. That's actually an argument that has the advantage of being both true and being understandable by someone who isn't a developer but has to approve our purchase reqs... Given that preinstalled Windows 7 installs for all of the Home versions already have a set stop date by Microsoft, I think that could be a good argument to make. The strategy of building executables is one we'd like to move to everywhere, but currently it only seems feasible with software revisions that haven't been changed in a year or so, as many of our processes need slight tweaks month-to-mon
  8. Hmm... I wonder if the NI rep can tell me how many licenses my company owns and at what revisions. I've been having trouble tracking down exactly what versions and how many we own and what exact versions/privileges we have.
  9. Hi, I work for a medium sized company with a small dev group (I'm one of 4 LV people at the moment, with maybe one new hire soon). We're currently using LabVIEW 2011 for all of our development and deployment on new stations, mostly because we bought a bunch of licenses in 2011 and didn't upgrade them after that. We have a few 2009 or older full licenses on older stations, 2 LV2012 licenses that I could find (one full, one developer), and one 2013 developer, and then for 2011 we have something like 3 developer licenses and probably 10 or more full licenses. In the future we're g
  10. Right now I'm thinking that we have a big directory tree that we put all of the instrument classes in, and put that in the instr.lib directory. Devs would update it regularly; working stations would only upgrade it if something is changed and the version they had no longer works. The root class plus each of the child classes would each have a .mnu file in their directories, so all of the VIs would be accessible using either deep-browsing the default palette, adding only the relevant .mnu files to a customized palette, or using whichever form of quick drop they prefer. We already kind of
  11. I don't think we want to overlay this on top of the Actor framework. I've looked into that in the past and there are a number of reasons why it probably isn't something we would benefit from, both because of the initial overhead in setting everything up plus the fact that my co-developers are just wrapping their heads around OOP to begin with. Queued message handlers may be used on a case-by-case basis. I've used some hardware before that the only way to interact with it was with a .NET object dropped onto a front panel somewhere with a long series of setup commands before it is ready
  12. We do in fact use many different models of Tektronix scopes. I know of at least 5 models in use at the moment. The programming manuals for each are very similar and in many cases they share the same manual with the occasional caveat on some of the functions such as "(Model XXX only)". Our code is also probably not going to go public either, I understand. However, are there any generic things you can share that you discovered in your case? Pitfalls, things you didn't think of at first but found that you needed later?
  13. I work for a medium-sized company with 4 full-time plus a few occasional developers who use LabVIEW, me being one of the full-time developers. The company isn't that old, and apart from me none of the developers have formal Computer Science training (i.e. they are engineers who transitioned to it gradually). Right now we're getting to the point where we need to start being a lot more efficient in our re-use of code, as currently we pretty much assign one developer to one station, and then most of what they write isn't applicable to any other station. So what I have proposed to them (b
  • Create New...

Important Information

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