From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how can run my vi real time?

Solved!
Go to solution

hi

i have a vi that use many loop in loop(that 128*128) in it.
and use some equation(contains: n!&gamma(n)) on it.

it's work correctly but the problem is :when i click on the run, it take about 1 second to answer be show.
but i want it run real time. and want to answer be ready at less than 50 ms.

what's problem? and What should I do?


thanks

0 Kudos
Message 1 of 16
(3,133 Views)

First you need a realtime processor - which is to say a separate computer running a RT operating system that is networked to your PC.

 

Second, you add that processor to your project as a new host.

 

Third, in the project you drag the VI from development system (named My Computer) to the RT host.

 

But before you do any of that you need to be sure the code is as efficient as possible.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 16
(3,122 Views)

If the computation takes 1 second instead of 50ms, LabVIEW RT will not help. Your computation time is limited by pure number crunching! (most of the time, LabVIEW RT runs on hardware that is slower than a high end desktop). Note that the word "realtime" in this context does not mean fast, it just means less jitter in the execution time and thus more predictability (see also). Of course if it can be implemeted to run on an FPGA, that might be a solution. 😉

 

It is possible that your VI is slow because you algorithm implementation is inefficient. (Make sure all operations are done in place, avoid datacopies, avoid coercions, avoid local variables and property nodes. especially inside the innermost loops , keep the front panel of subVIs closed, disable debugging, and so on...). What we have learned from past LabVIEW coding challenges is that the execution time of the winner can be orders of magnitude faster than the slowest entry. It is all in the coding!

 

A 20x speedup (and sometimes much, much more!) is often possible. Feel free to attach yor VI and so we can see if there are any obvious problems in your implementation. Also don't forget parallelization to use all available CPU cores. Certain code arrangements can also take better advantage of SIMD instructions than others.

 

As a first step, you need to design a functional benchmark applications so you can accurately compare code alternatives. How do you currently measure the execution time?

 

How much precision do you need in the output? If approximations are acceptable, you could implement a lookup table and use interpolation, for example. I recently did that for one of my problems and the execution time went from 10 seconds to microseconds. 😄

 


@hamedi wrote:

i have a vi that use many loop in loop(that 128*128) in it.
and use some equation(contains: n!&gamma(n)) on it.


Are these 2 stacked loops, each running 128 times?

How many is "many"? Why can't you combine all into one stack of loops?

128x128 is small!

What is  "n!&gamma(n))".

Is n! a factorial?

Is that a gamma function?

What operation is "&"?

What is "n", are all inputs always positive integers?

What is the datatype of the input and the output?

What is the maximum range of "n"

Message 3 of 16
(3,094 Views)

hi dear altenbach
thank you for your answer

I've simplified my vi but problem is still not solve.
my output is a pic. i want to run continuously and I want to see a continuous image(As the time between images is less than 50 milliseconds)

but if you run continuously my vi see images with about 1 second  distance.

i attach my vi(the main is zeit128) and hope that you can help me.

thank you

0 Kudos
Message 4 of 16
(3,066 Views)

I cannot open your zip file. I think it is corrupted. Plase try again.

 

(edit: I think it is a rar file renamed to zip. I was able to open it now)

0 Kudos
Message 5 of 16
(3,062 Views)

Well, the entire z-conv subVI only depends on i and j, which are both in the range 0..127. This can be calculated once and turned into a 2D array diagram constant. The result will never change! Also use plain primitives, not express VIs. See how much faster it is after implementing this. 😄

 

(haven't looked at the second loop pyramid. That seems to be the slow part because your formula node in the innermost loop contains two loop stacks)

0 Kudos
Message 6 of 16
(3,051 Views)

Do you have a link that describes what you are trying to do here?

0 Kudos
Message 7 of 16
(3,042 Views)

hi
thank you for your answer.

I'm a physicist. and it's a project that difficult to explain for you.

i think the problem Probably related to zernfun.vi
Because when i remove it from main vi. and replace it with 'add' the main vi is Real-time.

please chek it(zernfun.vi) and if it possible for you help me.

thank you.

0 Kudos
Message 8 of 16
(3,024 Views)

I wasn't asking for an explanation, just for a link that describes it. Or is this original reasearch without precendent?


@hamedi wrote:

i think the problem Probably related to zernfun.vi.



... looking at zernfun, I see a lof of quite silly constructs. but I doubt they would cause a significant slowdown. For example, you are creating a blue array of "i"s and later indexing into it using index array? don't you simply get the value of the index back? Why the detour? The factorial function could easily be replaced by a lookup table, because it only has small integers as inputs. (I don't know how fast it is, though).

 

Was this ever designed to run on an FPGA?

0 Kudos
Message 9 of 16
(3,007 Views)

OK, looking at this in more detail, you are repeating mostly the same operations millions of times. 95% of your code can be turned into a lookup table. Here's what I would do. Seems pretty fast (~12ms on my very old desktop). 😄

 

Sorry, it is too big for the forum, thus I uploaded it to my skydrive here. (LabVIEW 2011)

 

You can parallelize the second FOR loop, which brings it down to ~3ms on my quad core machine (not shown in the attached VI) 😉

Message 10 of 16
(2,995 Views)