george seifert

I'm assuming the color history is kept in the INI file. Maybe you don't have write permissions to the LV folder? It should be fairly easy to check by changing a setting which is written to the INI file.

I've always had permissions in the past on older versions of LV. Plus I'm an administrator on this PC so I can't see why I wouldn't have permission.

George

In LV2010 the color history isn't kept when LV is exited - at least on my PC. Is there a new setting that I'm missing that allows the history to be kept?

George

False alarm. Turns out the problem was that I had set the range on the DMM to 100 uA (it used to be set higher). Apparently at this setting the internal drop across the DMM is enough to interfere with my circuit in such a way that I thought it was disconnected.

George

I think something changed in the niDMM code in LV2010 SP1. My code worked fine before the SP1 upgrade.

The problem is I need the DMM to allow current to flow through it (in current measurement mode) even when I'm not making a measurement. Before the upgrade I used a niDMM Initiate VI to do that. Even after a waveform measurement my circuit, current was still allowed to go through the DMM. Now after the upgrade, the DMM opens up after the measurement. I have to reinit the DMM before current will flow again. What's the correct way to setup a DMM so that it can be left in the circuit at all times?

George

The private property 'TypeClass' gives me the correct class : 'IviDmm' or 'IviDCPwr' ... (tried with LV 8.6)

Interesting. I'll look into it further. I hope LV2010 doesn't have a bug.

George

There's a couple of property nodes TypeClass and SubTypeClass which will give you the class names. Is that what you are after?

Thanks, but all the TypeClass property tells me is that it's IVI. Doesn't really help much.

I was looking for what type of IVI instrument it is - like DMM or DC power.

George

Is it possible to programatically get the IVI class of an IVI control? It's easy enough to determine if the reference type of a control is IVI (Getrefnuminfo.vi), but I can't figure out how to get the class. I'm using LV2010.

George

Hello,

I am a mechanical engineer and Newbie in Labview. I need to design a vi that will act as a threshold detector. I have 10 ramp signals and I want to get , for each signal, an LED turning on (in the front panel) when the the ramp signal rises and it passes a threshold. I also want to be able to log the time it takes for each of these LED's to turn on. I have tried the threshold vi that exists in Labview but I cannot get it to read that the threshold is reached and give a signal to the LED.

Any ideas?

It'd be helpful to see what you have so far so we can make suggestions.

George

Yes, that's exactly what I'm seeing. For me though it happens regardless of VI complexity, though they always reside in a very complex project. It's becoming very frustrating.

That's what I'm seeing too except the delay can be more like 5 to 10 seconds.

I don't see it all the time - even in the same VI / Project. I don't know what' s different when it works. It doesn't seem to be related to how loaded down the system is. It may have something to do with how long I've been editing in a given project, but I can't be sure yet.

George

Are you using the integrated SCC-interface?

If your interface is slow (and it can be slow partly caused by LabVIEW) it can hog LabVIEW.

Ton

No, I haven't implemented that yet.

After upgrading once I saw similar slow down problems, and tracked it down to my LabVIEW Data directory defaulting to a network location, moving it to a local location mitigated all the issues. This doesn't seem to be the cause of the issue now though.

As for system depen

What happened? Did you fall asleep while typing?

I'm confused. First you said moving the data directory helped, but now it's bad again. What happened?

George

George,

Are you having the Project Window opened?

If so, try to open the VI direct without the project, does this speed up the performace?

There was a bug NI fixed in 2010 to solve this, but I'm not sure it solved all Slow Editing issues.

Cheers,

Mikael

I always work withing a project. Since I often have two projects opened this is the only way to go.

I tried a large VI without loading the project and editing seemed fine. So I opened the project and edited the same VI. The response time was about the same. This makes me wonder if it's some kind of system issue. My memory usage was about where it normally is so that probably isn't the cause.

George

I'm using LV2010 on Windows XP (although I saw the same thing with LV2009). It takes at least 10 seconds after I drop a VI (and other things too) on my diagram before I can do anything else in LV. Is there some setting that will fix that. Is it maybe recompling every time? This is getting really old.

George

Maybe a stupid question but I assume you checked 'LabVIEW 2010 IDE support' or whatever during the DAQmx install? Normally, upgrading is fine in my experience. On a side note, with the latest DAQmx drivers, on an upgrade you don't have to uninstall the old one manually - I really liked that new feature.

I figured it out. I had loaded DAQmx 9.2.1 when I still had LV2009. My LV2010 DVDs were from August and had an older DAQmx. So when I loaded the Device Drivers from my LV2010 DVDs it didn't install anything.

George

I just upgraded from LV2009 to LV2010. I installed the DAQ device drivers as well. I can't find any DAQmx VIs. Measurement and Automation Explorer says that NI-DAQmx version 9.2.1f2 is installed. But in LabVIEW there are no DAQmx VIs. What else do I need to install?

I've been installing upgrades for several years and have never run into this before. NI says it's because the DAQ drivers were installed previously and that I need to uninstall my hardware, reinstall the drivers, then reinstall hardware and reboot. That's just silly. Why can't it install some VIs if there's hardware in the system?

George

My project is getting rather big, the the function block busy...especially with nearly all wires clearly labled.

It'd be a pain to downsize every label, one by one. Be nice if I could reduce the font size of ALL labels in one fell swoop. Any way to do that?

Just select all the labels and then select the font size. They'll all be updated at once.

George

<sigh>... I wonder which path to choose?

Let the force guide you my son.

I ended up doing a repair of LV and that fixed it. Probably something with the RTE was messed up. I certainly don't care to investigate further.

I don't understand what language had to do with the problem. I only ever select English. For some reason the installer insists on adding tons of other language support. I swear the installer would be half the size if NI would only give you the language you ask for.

George

Woah! Flashback:

Bad news is that I had to ended up re-imaging the PC, fixing and uninstalling/installing LabVIEW did not help.

Cheers

-JG

Oh man if I have to do that I might as well just go home now.

I just loaded NIDAQmx 9.2.1 (needed to support a new DAQ board) and it messed up my existing LV2009 executables. I'm getting the following errors:

"No supported languages intalled"

"Unable to open resource files"

I tried rebuilding the executable, but still get the same errors. What's going on? In the old days you could load new versions of NIDAQ without hosing up your system. I dread every time I try to update something now.

George

That is almost surely wrong. When the EXE loads and executes, the startup VIs load and run, and that's it. There is no mechanism for dynamic VIs to be loaded unless you write code to load them.

George, by nature it should be hard to browse the EXE for VIs. It used to be really easy, since it was just an LLB, but finally NI tightened the security. No offense intended, but I don't want you or anyone else looking into our executables and harvesting the names of our proprietary routines. But if it's your code, you have some options. You can drop all of your dynamic VIs into "Dynamic VI Container.vi", and include that as the only Dynamic VI in your project. Then code running in your EXE could load it and get its callees from its VI reference.

If that's too ugly and/or slow, you could mantain a list of those VIs (you could actually get that from the lvproj build specs with property nodes, but it might be easier to just maintain your own list). Store the list as a default value of a simple subvi and build that into your EXE.

Yes, it's definitely wrong. I tried it. What did work was this (although it isn't as elegant as I'd like):

1. All dynamic VIs are put in the Always Included box on the Source Files tab.

2. On the Source File Settings tab I set the Destination for each of the dynamic VIs as Support Directory. This loads each of the dynamic VIs to the support directory. I guess this would be a problem if you wanted to keep all you VIs secret, but all my stuff is in-house.

3. Getting a reference to the dynamic VIs requires some different code for the run time system vs the development system.

George

Hello,

Have you try to use "All VIs In Memory" application property ?

No, but since they're dynamic VIs I don't think they'd be in memory.

With the development system I can get a list of dymanic VIs (they start with a unique string) by using List Folder VI. These VIs are displayed to the user.

When I built the executable I put all the dynamic VIs in the Always Included box on the Source Files tab. So now I assume they should be contained within the exe. How do I get a list of the dymanic VIs from the executable?

George

Add this line to the labview.ini file in your labview folder:

disableMenuEffects=True

Or if an entry already exists; change it to True.

Then restart labview

Perfect. That did it. It also helped with seeing the menus on the toolbar.

George

When I run VNC to work remotely, right-clicking in LV doesn't bring up anything. I can right-click on other Windows components though. Is there some setting I can fix to get it to work in LV. If not, is there a better remote program to use?

George