subVI question

[commodore]

Hi,

I got a small question, will my program that I have written run faster and better if I turn several VI's into a subvi?

Thanks,

Stieve

[GJAKLDFJG]

no subvi is just a representation of sub-routine so it wont change the speed.

[commodore]

Okay , thanks for the responds.

Stieve

[Ben]

---

@commodore wrote:

Okay , thanks for the responds.

Stieve

---

And for the hair-splitters out there...

There is a very small over-head for calling a sub-VI (provided NO data being passed to/from sub-VI). The actaul amount of time depends on the hardware and the number of connectors on the icon connector. At one time, I used NI's top-of the line PXI with high-speed timing borads to benchmark the time required per "extra" terminal. Since the Clock was limited to 80 Mhz I could only measure the average time and it worked out to something like 8 femtoseconds per terminal.

done splitting hairs.

Ben

[smercurio_fc]

---

@commodore wrote:

Hi,

I got a small question, will my program that I have written run faster and better if I turn several VI's into a subvi?

---

Open-ended questions like this usually point to something else going on. Such as your program being slow, or perhaps using up too much memory. If the basic design of the program is poor, making subVIs won't fix it. What is the specific issue that you are looking to find out?

[Darin.K]

---

Ben wrote:

And for the hair-splitters out there...

There is a very small over-head for calling a sub-VI (provided NO data being passed to/from sub-VI). The actaul amount of time depends on the hardware and the number of connectors on the icon connector. At one time, I used NI's top-of the line PXI with high-speed timing borads to benchmark the time required per "extra" terminal. Since the Clock was limited to 80 Mhz I could only measure the average time and it worked out to something like 8 femtoseconds per terminal.

done splitting hairs.

---

Rules were made to be broken, and hairs were made to be split.  The "very small" overhead Ben mentions is real and will affect performance of tight loops, but not the typical subVI usage.  The usual response these days is that this can be eliminated using inlining, and that is mostly true. 

Now to my hairsplitting.  Willy-nilly grouping of code into subVIs can have the effect of thrusting dataflow constraints on unrelated pieces of your code.  Inlining still respects the subVI nature, so it will place a virtual sequence structure around the code it inlines so that the original, perhaps unintended dataflow still exists.  This can also impact performance if you are a bit sloppy.

In my usage, by far the biggest pain of subVI proliferation is the increased file loading time.  I know I have lost more time to the dreaded Loading SubVI window than to the call overhead.

Done splitting hairs.  BTW, I suspect none of this is related to the problem at hand.

[commodore]

First thanks all for the interest.

The application that I am working on is not hard at all from a LabVIEW point of view. I just send digital signals out on various points in time using the flat sequence loop.

At first, it looked as if the DAQmx was to slow for my application, but that was not the case. That's why I posted the question, to know if my subvi-ing would help.

These signals do the same thing as the LSI-11 bus CPU does (alias Q-bus) and depending on the PCB on my backplane, I will get a analog or digital signal as feedback.

I had it working for about 4-5 hours but when I was fine tuning it, the DAC PCB stopped working and I was not able (yet) to get it up and running again. Probably it was something with the prototype setup, I am using a breadboard

with some NPN transistors.

Anyway,I am at home now so I can't upload the program. I will do that tomorrow when I am back in the lab. And hoping the damn thing will work again after 3 months of hard labor!

Bye,

Stieve

[Ben]

---

@commodore wrote:

First thanks all for the interest.

...the same thing as the LSI-11 bus CPU does (alias Q-bus) ...

I have not heard that term since soon after departing DEC after the big layoff.

Last seen in a microVAX if I recall correctly.

Bye,

Stieve

---

[commodore]

It indeed is a very old system.But It still runs in our aluminum and paper factory.

My job is to create a test system for the broken Q-bus PCB's so I can detect the defect IC in less then 5 minutes so repairing the boards takes less time.

And of course, less time is more money. I am using the PXI-1042 chassis, the PXI-8361controller , the PXI-6259 DAQmx(analogue and digital) and the PXI-6515 (digital) to do so.

After a good nights sleep I got it up and running again within 10 minutes, but it does not seem to work consistently.

Is this because of the DAQmx I am using ? Does my coding lack efficiency? Is it the DAC PCB itself? Is it my breadboard prototype? Those are the questions that still elude me.

I have uploaded the code, my guess is that is not the real problem. But if a more experienced person would have a look at it, that would be very helpful.

Bye,

Stieve

[Yamaeda]

For starters, you create a new DaQMX-tast for each read, just wire through from the first one you created.

You also create a new task every loop, create it outside.

Each frame has a wait, the sum of all waits is the minimum loop time, so the wait outside the frame structure is irrelevant.

Since you have well defined frames, it's a good candidate for a state machine.

You should cluster up all DAQMX-tasks and it'll be easier to handle, maybe i can whip up some starting suggestion.

/Y