Any advice on slow path control dialog?

[bconway6]

Hi,

I have a path control that is giving me trouble with LV2010 and WinXP. My VI seems to be running fine (it keeps updating analog inputs etc.) and the rest of the computer seems to be working as well (can switch windows, manipulate other applications, etc), however the file dialog box seems to be very slow. It takes about 10 seconds for a mouse click inside the dialog to select a file. The control works (if I am patient enough), but very slowly as if the computer/windows is too busy to handle the file dialog.

Any advice regarding the path control?

[SteveChandler]

I couldn't open it because some subvis were missing. I removed the subvis and a bunch of variables until the run arrow was not broken. The path select is instantanious. Maybe it is waiting for a network share?

[bconway6]

Thanks for the effort! I appreciate it.

I have now disabled the subVI that is responsible for reading the inputs and that seems to have fixed the flow file dialog problem. Now I need to figur out how to implement this workaround into the VI itself.

[altenbach]

Your code looks like it's written as a literal translation of text code, using local variables as "variables", breaking all dataflow, then placing sequences to enforce execution order.

From a quick glance, here are some obvious misconceptions that make the code inefficient. While you are at it, you might want to polish some of this. Rewritten as a propert state machine, it would not take more than a screen width (instead of 6).

Top: You are writing to a terminal and to a local variable of the same terminal at the same time. Since both operations do the same thing, once is enough.

Bottom: You are slicing through an array on element at a time, resizing the array in the shift regsiter with each iteration of the loop, causing constant memory reallocations. You could easily look at the elements in reverse order without modifying the array. Your code here is also very dangerous, because under pathological conditions, the loop might never stop.

[bconway6]

Ok, I've cut some things out of the program taht don't pertain to this problem and will make it easier to debug (hopefully).

To work the code into the VI I just removed the subvi and made it native to the main vi. This did not solve the problem though, just moved it. It seems that the delay is coming from the DAQmx read. The DAQmx task is a multiple channel, 100 sample read. the samples are then read and averaged with array manipulation. If I disable the array manilulation portion of the diagram, there is no change in behavior of the file dialog. If I disable the DAQmx portion the dialog is as snappy as anything else.

Has anyone else seen this kind of behavior? Nothing else seems to be affected by the DAQ operation other than the file dialog.

[bconway6]

Thanks for the advice altenbach. I agree that a proper state machine would be the preferred archetecture for the program in general and that there are many improvements that could be made the the program from a best practices perspective. Time and my own labview experiance level are the main factors in these issues.

[bconway6]

I cut EVERYTHING out of the program to see what the cause is or what potential workaround there is. Here is a screen capture of the front panel and block diagram.

It is very clear that there is a connection between the DAQmx read and the delay of the path control dialog. I cannot think of any reason that the DAQmx read would only effect the path control dialog.

[altenbach]

Well, that code is quite a dog (see also), but what exactly is the loop rate of the while loop?

---

bconway6 wrote:

It is very clear that there is a connection between the DAQmx read and the delay of the path control dialog. I cannot think of any reason that the DAQmx read would only effect the path control dialog.

---

I don't understand what you are saying. Does the loop rate slow down when the path control is in the loop?

[SteveChandler · Accepted solution]

I think what he is referring to is that the loop may be executing very fast and slowing down everything. Try putting a 50mS delay in the loop and see what happens.

[bconway6]

That's the thing, I'd expect the loop to be slowing everything down, but it does not seem to be the case. I may just not be noticing it, but the rest of the program seems to work in a timely manner with the exception of the path control dialog. The front panel updates with new values, the rest of the computers functions seem to be in working order as well. Any ideas why the only part of the computer affected is the path control dialog?

I did insert a small delay into the loop and that has fixed the problem.

I appreciate your help altenbach and SteveChandler!