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.

21 hours ago, Maciej Kolosko said:

In reality my biggest concern is that the G language and the IDE of LabVIEW are joined at the hip and that is I think the crux of the issue. In order for G to survive as a viable option for the future it would need to be de-coupled from the old IDE of LabVIEW. But it seems to me like now they will be entangled together till the bitter end... until the user base of LabVIEW retires, and no new cutting edge projects will be created in G, not because G sucks but because LabVIEW IDE is holding it back.

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.

Here is the important line:

 

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

 

This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project )

As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP.

 

I hope this prevents anybody else to run into the same problem.

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)

The main problem I can think of is selecting which event structure it would be part of. Many people probably only have one, but that's not necessarily the case.

I think that the problem is simply that the event configuration dialog isn't that great (yes, I'm understated, what can I say?). Perhaps an alternative implementation would be to select the control from the from panel (similar to how you associate a control in the connector pane) instead of the listbox.

One shortcut you can use today is that you can type to jump to entries in the listbox. This applies to both the control selection and the event selection.

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)

But the *index* of the median is always (size of array / 2) rounded up. So all you need are the Array Size function, the Quotient&Remainder function and the Add -- all of which can be found by searching the palettes. Just get the size of the array, use quotient and remainder to divide by two and then add the resulting remainder to the quotient. (If the remainder was zero, then you had an even array and you have the lower index; if the remainder was 1 then you have the index of the middle element of the array).

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)

Yes there is a reason..

The LabView project I work with executes millions of the software / hardware tests and adding Windows API interfacing ability to "hook" into another 3rd party (C++) application will let me enhance already existing test coverage by reusing another application's functionality... Using AutoIt will not be as elegant or as fast because of the big number of buttons I will have to interact with ... expect on average to click 1-3 million of buttons every 24 hours.. Direct interfacing from LabView by the use of Windows API will let me do it directly and faster without the need for huge library of AutoIt executables.

BTW -- found some working Windows API examples on NI.com (library of VIs for opening applications, resizing, moving, clicking etc..)

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)

Because the element order in a cluster is not always the desired tabbing order on a front panel at all anyhow. The cluster order is and should be dictated by the logical data it represents and is more often than not determined by the functionality (VIs) that operate on it. But this is more often than not, not the same that I would want a user to be presented with. For one there can be controls inside the cluster that a user should not be bothered with. For another one I prefer to have all my subVI front panels use classic controls and my UIs to use system controls. That precludes typedefs anyhow beside of the fact that typedefs do have some particular behaviour that is not making them very great to represent both the programming interface of a cluster as well as the UI interface.

Using individual controls on the UI is a bit more work initially but gives you every freedom to keep the UI completely independant of the underlying data structures, giving you the freedom to change them without having to revisit every UI to readjust just about every control on them to the new layout.

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)

For starters: If you give up the current behaviour, which btw has been there since LabVIEW has clusters and allows keyboard navigation, you will likely not always just want to tab into the cluster and then go through all controls inside that cluster before going to the next outside control. That would mean a completely separate tabbing configuration independant of the cluster element order.

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)

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)

There is no reason whatsoever for the user interface to care about cluster containers. Tabbing should ignore the fact that the controls or indicators are part of a cluster, that is only relevant for the program code, not the GUI.

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)

Can you post an example of the problem? If your code's proprietary, then can you recreate the issue with a simple example?

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