executables

[Paul_R.]

I am new to LV.  I am using Version 2011 on Windows XP.  I am having a problem creating executables.  The compiled versions run more slowly than the uncompiled versions.  Does anyone know of possible solutions?

Thanks,

Paul

[Mark_Yedinak]

Not without seeing your code. We have no idea what is going on in your code and therefore cannot give you any advice.

[Paul_R.]

There are over a hundred vis that make up this project, but the vi that I compile is attached.

[Mark_Yedinak]

Without seeing the rest of your code it is nearly impossible to say where your problem lies. I would suggest that you enable debugging on your application and run the profiler against your application. You need to see what code is taking up your CPU cycles.

Based on this one VI though you could be running into lots of issues. Your code relies too much on local variables and frame structures. Your lower two loops also appear to be greedy loops which will impact performance. Learn ho to use data flow effectively to eliminate the frame structures and the local variables. For example you have one frame structure that initializes some controls/indicators. Why not just run the three frames in parallel. There is no reason to serialize that code.

[Paul_R.]

Mark,

Here is the project.  I do not know if all the vis are going to be attached, but I thought I would try.

Paul

[altenbach]

---

@Paul_R. wrote:

I am new to LV.  I am using Version 2011 on Windows XP.  I am having a problem creating executables.  The compiled versions run more slowly than the uncompiled versions.

---

What is your problem creating executables? It seems you can create them just fine.

Can you quantify that speed statement? is it 10% slower? 10x slower? Is the CPU use higher (as seen in the task manager)? How do you measure the speed?

LabVIEW is always compiled. You probably mean the difference between running it in the development system versus as a standalone executable.

[p-rose]

In a situation like this, I would typically start throwing block diagram disable structures around each of the loops, one by one (starting with the communications loops), rebuild after each iteration until the problem goes away, then narrow in until I find the exact cause. You need to isolate which section of code is bogging down. In the code you posted, some vi's are missing so it's hard to make a recomendation but I noticed the communciation loops have no waits in them. Free wheeling loops could be robbing valuable time from the other parallel processes - perhaps even more so in an executable where debugging might not be helping throttle things down a bit (usually undesirable, but in your case it might have been helping keep things balanced). If those loops are executing continuously as fast as possible maybe try putting a 1 ms wait in each iteration just so the scheduler can switch tasks for a bit.

[Paul_R.]

I failed to mention that I am using TCP/IP protocol to communicate between a client and a server.  Could this also play a factor?  And if so, what are some of the issues that this may present?

Thanks,

Paul

[Paul_R.]

Actually, it appears that it has something to do with the TCP/IP, because when I run the executable locally.  It runs at a similar speed to what I see when I run it as a non-executable.

Paul

[altenbach]

---

@Paul_R. wrote:

I failed to mention that I am using TCP/IP protocol to communicate between a client and a server.  Could this also play a factor?  And if so, what are some of the issues that this may present?

---

It would really help if you could answer some of my question above. Is the program the server or client? We really need much more details.