CaseyM

I think yes. If you're architecting code and not aware of OOP principles and LVOOP itself, you're probably hindering your efforts. This is an advanced certification so I think it's fair to require people to know about these ideas. I'd certainly expect someone with a CLA to at least be familiar with LVOOP if I were hiring. The key difference between this and other "advanced" topics is that I see OOP as pretty fundamental to good architectures. Obviously there are places where LVOOP might not be appropriate or even possible, but for a general CLA certification, I think this makes sense. LVOOP is ~15 years old by now so it's not like people haven't had time to learn it like was the case when the CLA certification and LVOOP were both fairly new.

This 100%. I guess we have to all wait and see, but I'm not feeling very good about this for my long-term career aspirations at the moment.

I recently ran into the exact same thing except my offending VIs weren't password protected so this thread definitely helped. Does anyone know what mechanism causes VIs to lose their linking to their lvlib files? I only noticed that it was happening when I came across this error.

You may want to check out this topic as well - some good stuff there.

Cross-posted here: http://forums.ni.com...hread.id=438196 I have an installer for an application I wrote in LabVIEW 8.5.1 that includes nothing but the application itself and theLabVIEW RTE. It used to weigh in at ~75 MB, but since I installedLabVIEW 2009 the installer now takes up ~115 MB. I poked around someand it appears as though some of the extra space is being used toinclude 64-bit compatibility, but is there anything else going onhere? Can I set any options to reduce the size to something closer tothe original or is this something I'm stuck with? Also, in case it wasn't clear, I'm still building the installer using 8.5.1.

Suppose I have two signals - A and B. I want to output signal A followed by some user defined delay and then output signal B on two separate AO channels. This process can be automated to repeat N number of times. Now also suppose that I'm reading an AI channel continuously, but I only want to log data from that analog input when B is being output. How can I trigger logging when B starts? (This needs to be hardware timed so no data is skipped so occurrences and other such software features are out.)

QUOTE (Yair @ Mar 5 2009, 09:02 AM) Good point - I hadn't thought of multiple event structures. I'd be fine with a connector pane style interface as well as pretty much anything would be better than what currently exists.

I'd like to be able to right-click on a terminal, browse over to the "Create" option and have there be an "Event" menu option along with the "Constant", "Control", etc. Bonus points if you could browse to a sub-menu beneath (like with "Property Node") that that had the relevant events associated with that control. Thoughts?

QUOTE (Aristos Queue @ Feb 1 2009, 03:17 PM) I think this needs some modification in order to be correct. Example: Array size = 4 Quotient (after dividing by 2) = 2 Remainder = 0 Median = 2 The indexes of the array would be 0, 1, 2 and 3 and the median index should be 1.5. Using the method above with an array with an odd number of elements produces a median index that is one higher than it should be. The correct algorithm for finding the median index of an array should be subtracting 1 from the array length and then dividing by 2. Example revisited: Array size = 4 Array size - 1 = 3 Quotient (after dividing by 2) = 1.5

I did a quick search and didn't see this before so my apologies if this is a duplicate, but I'd really like it if LabVIEW had the option to have tabbed VIs. I try not to keep too many VIs open at once, but sometimes it happens and it's a pain to Alt+Tab trying to get to the VI you want and don't even get me started about trying to Alt+Tab to another application. Now, I realize that not all FPs and BDs are the same size but I'm picuring something like Excel where all the VIs could be contained in one master window for FPs and one master window for BDs. You could Ctrl+Tab between the different VIs and then you could Alt+Tab between different applications. Or maybe something like PowerPoint where you can preview the FP/BD on the side and when you click on the preview, it'd bring up the FP/BD in the main display area to work on. Again, I think this would be best as an option so that those that work with lower screen resolutions wouldn't be hindered by this feature. What do you guys think?

NO SLuG BacK (following a "Slug Bug!")

Thanks for the replies. I was pretty certain that it wouldn't work. We decided to just to transfer the raw data off the cRIO and to the Matlab processing then. -Casey

Hi all, Is it at all possible to call a Matlab DLL (i.e. MCR) in LabVIEW RT? From what I've seen it doesn't appear so. If, indeed, it is not possible, does anyone have any insights as to how else one might call Matlab code in LabVIEW RT? -Casey

QUOTE (iowa @ Jul 31 2008, 04:19 PM) If you're familiar with TestStand there's a toolkit available on justTESTtoolkits.com: http://www.justtesttoolkits.com/toolkit-details.php?id=167 You can always try requesting a toolkit there as well.

Use the "Set Menu Item Info" VI. It's under Dialog & User Interface --> Menu --> ...

Continuing on this topic... is there a property that tells which type of numeric the control is (i.e. whether it's an I32, DBL, etc.)?

QUOTE (rolfk @ Apr 25 2008, 02:08 AM) You make a good point about UI tabbing order vs the logic order of data within a cluster, but I find that changing the order of cluster elements in an (un)bundle by name on the block diagram to be much easier than dealing with tons of controls on the front panel. Also, it sounds like a lot of the UI issues you brought up (e.g. classic vs system,) would be a result of using strict type defs so wouldn't a lot them be moot if you used their non-strict brethren?

QUOTE (rolfk @ Apr 24 2008, 10:12 PM) Why would this have to be the case? Instead of tabbing to the cluster container, LabVIEW could automatically tab to the first element inside the cluster. The overall tabbing order could still be preserved as follows: 0. Numeric Control 1. String Control 2. Cluster Control Container (ignored) 2a. Path Control 2b. Numeric Control 3. Boolean Control Where "a" and "b" are the 0th and 1st elements in the cluster. QUOTE (rolfk @ Apr 24 2008, 10:12 PM) I'm sure there are quite a few other not so trivial questions and problems in that respect. And in my experience clusters are not really great UI controls anyhow. They restrict the design of an UI to much in several ways so that I have long ago stopped to use them on the visible UIs. How do they restrict the UI design? I think in general they help clean things up rather than having individual controls on the block diagram for potentially similar and repeated sets of controls.

QUOTE (Mads @ Apr 24 2008, 01:24 AM) I completely agree. Is there ever a reason you'd only want to tab to a cluster container? Anyone?

I know that if a VI is running you can use Ctrl+Down/Up to enter/exit a cluster while tabbing through the controls, but from a user's point of view this is extrememly obscure and unituitive. Is there any way to change the tabbing behavior so that it automatically tabs into (and out of) custers? -Casey

It seems that Traditional NI-DAQ isn't supported on Vista but I need some of the VIs for a current project. Does anyone know of a workaround? Alternatively, does anyone know if my computer will explode if I just copy the necessary NI-DAQ files from an XP laptop over to the new Vista one?

Well, after all that it turns out there was a VI running in the "background" that was hogging CPU cycles - totally our fault. Thanks for the help anyway.

QUOTE(crelf @ Feb 19 2008, 12:56 PM) The code is proprietary and I don't think I can recreate the problem very easily. I know that's not very helpful, but maybe I can share some more information that might be of use. -The experiment GUI calls the "Run Script" case in the Script Application module by enqueing that particular state. -Script files are written to disk and are read in the "Run Script" case. -2 commands in the script file in particular seem to carry most of the delay from the eGUI: load_configuration and write_file_to_disk

Couldn't you just make a VI that only contains the type def and wire that to the output? Then you only have the VI icon on your block diagram instead of the huge type def constant.

This may fall into another sub-category, but at the moment I'm at a loss as to which one it would be. So here's the deal... A co-worker and I have developed software for a client that takes and parses a custom script that is used to load and read settings and measurements from custom hardware. There are two main modules in this application: 1) The script application module which actually parses the custom script and communicates with the custom hardware 2) An experiment GUI with which the user can define parameters and automatically create the custom scripts. The experiment GUI also calls the script application module to run these custom scripts. When running a script through the experiment GUI the script application module gets called and the script takes ~2.5s to run. When running the script directly through the script applicatoin it only takes ~1-1.5s to run. What gives? LabVIEW is calling the exact same code in each case but there are wildly different execution times in running the script. It doesn't matter whether the experiment GUI calls the script application module statically or dynamically. Changing the priority of the script application module doesn't make a difference either. This is running WinXP SP2 on an Intel Core Duo @1.83 GHz with 512MB of RAM. Has anyone experienced something similar or does anyone have any insight as to why this difference might occur? -Casey