LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do you use projects?

There's a button on the toolbar that filters the view - you can turn off dependcies so they won't even show up. I don't know why it takes so long for your program to run, I've never had it check dependencies when I run anything. Try removing them from the view like I said and see if it stops that from happening.
0 Kudos
Message 11 of 24
(1,785 Views)
There's a button on the toolbar that filters the view - you can turn off dependcies so they won't even show up.

But that affects nothing EXCEPT the view itself.

I saved the project with that view OFF, then loaded it again, and loaded my main VI.

Turning the view ON showed the dependencies as empty, as expected.

I turned it OFF and hit the RUN button. 36 seconds later, the DEPLOY window appeared.

I cancelled the deployment, and turned on the view. The dependencies were all there.

IOW, it had done the same thing and taken the same amount of time, except it didn't show it.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 12 of 24
(1,778 Views)

Hi CoastalMaineBird,

You said that the Deploy window poped up.  Does that mean that you are making a Real-Time project? 

A possibe way to increase the speed is to turn off Autodeployment for shared variables.  You can do this by right clicking on the shared variable library and selecting undeploy.  Then you can deploy the library once, and unless you add new variables you will not have to deploy it again.

Also, is this slowness associated with all projects or just the one you are currently working on?  Maybe if we reduce the project we can associate the bottleneck with a specific VI.

Brian K.
0 Kudos
Message 13 of 24
(1,754 Views)
You said that the Deploy window poped up. Does that mean that you are making a Real-Time project?

--- Yes.

A possibe way to increase the speed is to turn off Autodeployment for shared variables. You can do this by right clicking on the shared variable library and selecting undeploy.

I don't know what you mean by "shared variable library". I am not using shared variables, as all the papers I have read say that TCP is faster. In my case, it's point A to point B, and speed is important, so I have my own TCP code.

Also, is this slowness associated with all projects or just the one you are currently working on? Maybe if we reduce the project we can associate the bottleneck with a specific VI.

Sensible, but it doesn't seem to work that way.

I made a copy of my project file and opened the copy.

It was 37 seconds from the CNTRL-R on my RT program to the START of the DEPLOY window coming up.

I removed ALL the host stuff from the project - same 37 seconds.

I loaded the project again, and ran a small test program which was also in the RT side of the project - 34 seconds.

I removed EVERYTHING except this small test program - 34 seconds.

I created a new project from scratch, and threw in this test VI - 34 seconds.

The weird thing is all the crap that appears in the dependencies list - 40+ versions of DAQ MX CREATE CHANNEL - error code database, search and replace pattern - this has nothing to do with my program (well, I do create a single MX channel in this test, but not all 40 kinds).

If I start from scratch, and put a 2+2 = ? VI into the RT side, it's less than 1 sec. Of course that doesn't do any useful work.

I can break down an run a small subVI that the tester uses - 34 seconds.

I suppose if I keep going, I can find a particular VI that causes it. Will report back if I do (not tonight).

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 14 of 24
(1,737 Views)
So, I create a new project with my little test program in it. Part of this test program includes "DAQmx Create Channel (DO-Digital Output).vi". I added that to the project.

If I load the main VI, it's 34 seconds between CNTRL-R, and the DEPLOY window popping up.

I close the project, and open it again. If I load the CREATE CHANNEL vi by itself, it's still 34 seconds between CNTRL-R and the window.

If I remove the main program, so that there's nothing in the project except the CREATE CHANNEL vi, close the project and try again, it's almost instantaneous.

So it's the DEPENDENCIES thing that's killing me.

The question still remains: Why do I have 40-50 instances of DAQmx CREATE CHANNEL, and 50+ instances of DAQmx READ, and 50+ instances of DAQmx WRITE in my DEPENDENCIES list? I do use 3-4 of each one of those, but not 40.

And there are at least 90 VIs and controls that start with SIM - including things I've never heard of, like SIM ROSENBROCK MANAGER. Yet when I load one of these and ask it to FIND ALL INSTANCES, it finds none.

Anybody have a clue?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 15 of 24
(1,725 Views)
OK, how is THIS for stupid?

My little test program uses SIGNAL PROCESSING - SIGNAL GENERATION - SINE PATTERN.vi to generate a sine wave.

If I replace that with a constant array, the dependency time drops to about 1.5 seconds, instead of 34. I still have all the irrelevant DAQmx stuff, but all the SIM stuff is gone.

Does it really take 90+ VIs to generate a simple sinewave?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 16 of 24
(1,720 Views)
OK, I replaced the VI SIGNAL PROCESSING - SIGNAL GENERATION - SINE PATTERN with SIGNAL PROCESSING - SIGNAL GENERATION - SINE WAVE.

Basically no change.

But if I do the sinewaves myself, using the SINE/COSINE function, the time goes from 34 down to about 1 sec.

But if I have that sinewave function ANYWHERE inside ANYTHING that's in my project, EVEN IF THAT FUNCTION IS NOT USED in the program I'm running, then I'm back up to 34 seconds.

That's absurd. Something must be seriously broken with the dependency-checking logic.

I replaced it in the real project, and now my times are 1-2 seconds, even for the real program.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 17 of 24
(1,709 Views)

One thing I still don't quite understand about the problem you're having. You say that you experience this delay when you press 'run', but I've never had a project check dependencies when I run a VI. It only checks them when it builds an executable, and of course this is going to take some time. If your project is updating dependencies every time you run the main VI, I'd say something is wrong. However, I can't see how this could be the case.

0 Kudos
Message 18 of 24
(1,702 Views)
I guess that dependencies are checked before deploying RT VIs.
0 Kudos
Message 19 of 24
(1,694 Views)
I am more and more confused.

In trying to make a test case to send to tech support, I made a VI which uses nothing but the SINEWAVE PATTERN vi, and it works just fine.

Still checking....

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 20 of 24
(1,693 Views)