Computer Lockup

[Will]

I am running a LabVIEW application using FieldPOINT. The main program has a sequence with 20 frames. I am controlling a set of lights in sequence using a PID VI and writing these values to the lights using the FP WRite Vis for the lights on that particular sequence. Nine lights is the most that I am controlling, and then most of them have 3 to 6 lights in a sequence. The problem I am having is that the computer likes to freeze up when I am running my application. I ran a similar application before with fewer lights per sequence, and I've had to add to accomodate for our application now. Can anyone give some insight on this. Also, where do I find the memory management window, where I can see how much memory is being used up per VI.
Thanks

[JohnM]

Bodycote,

First I am going to need more information on which version of LabVIEW, FieldPoint Explorer, and Windows you are using. I will also need to know which FieldPoint hardware that you are using. Next, does the computer lock up, or does the application no longer respond? How long does it take before the application "locks up"? If the computer �locks up�, do you receive any kind of error message? Have you tried moving your application to another computer because most often a computer lock up is cause by a resource conflict on the system? Have you tried reproducing the �lock up� by communicating with the FieldPoint Hardware using FieldPoint Explorer? Does your program call FP Open and FP Close more than once (this will create problems since we are allocating a
nd deallocating system resources more than what is needed)? If it does, move these VIs to the top level VI and pass their refnum to the subVI that is using the FP Write/Read VI. Continuing, have you created a smaller program that reproduces the problem, but does not use the PID VIs? By eliminating components, we will be better able to determine where the problem is occurring. Finally, if the above steps to not help you correct your problem, then I will need you to attach your VI to this discussion thread so that I can review to make certain that we have not missed anything.

Best Regards,

John M

For the most recent version of FieldPoint Explorer click on the following link:

http://digital.ni.com/softlib.nsf/web%2Fall%20software?OpenView&Start=1&Count=500&Expand=9#9

For the most recent fixes to your Windows operating system visit Microsoft�s web site.

[Will]

I am running LabVIEW 6.02, FP Explorer 2.0.4 Build 137, and Windows 98 on a PIII 966MHz 256MbRAM, using 4 FP-TC-120, 3 FP-AO-200. What the computer does is it just freezes, it does not give an error message, and the cursor doesn't move or nothing can be closed... not even CTRL-ALT-DEL work, so we have to hold the power button until computer shuts off. I have not tried to use another computer to see if the problem happens... kind of limited on this. However, one technician here noticed something. We run a cold cycle and a hot cycle. During the hot cycle, the solar lights I mentioned are controlled with a subvi, and the temps are logged. During the cold cycle, only the temps are logged. The lockups only occur during the hot cycle when the light subvi
is running. So I am wondering if the structure of this subvi is what is making it go all crazy. I am including the subvi. If you can look through it, eventhough I know you can't run it, but just check if the program has redundancies, or maybe you can suggest another way of doing the same thing but with less nodes...
Thanks

[Aaron_G]

Looking at your vi, a number of things stand out as possible contributors to errors and hang-ups. First of all, it is better to move the FP Create Tag.vi's outside of the loops. It means that you have to track which refnum is which, but saves processing power and memory.
Secondly, your methodology appears to be overly complicated. Why use a While loop that is set to be executed twice instead of a For loop? Additionally, I would recommend breaking your code out as parallel While loops rather than one 26 step sequence. Having the loops in parallel means they are executing at the same time rather than in series. This is much better for PID since the way it is set up, you will have two PID iterations with a deltaT of 100 ms, followed by an approximately
5200 ms delay (assumes 100 ms/iteration, 2 iterations/while loop, 26 while loops), then a deltaT of 100 ms again. Complicating matters further is the fact that each sequence step may touch one or more of the "zones" in earlier sequences and the deltaT's being used for the PID calculation go out the window...
Likewise, with 26 sequence frames, it is harder to get a feel for what is going on.
Furthermore, one common reason for total lock-ups is a While loop with no delay function in it.
Sorry to be so critical, but those are the areas that I see for improvement.
Regards,
Aaron