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: 

Periodic freezing/pausing of executable, LV 8.2

Hello,
 
I have created an executable from a VI created in LabVIEW 8.2 (Professional Developer Suite).  The VI and executable work fine on the machine in which the VI was created (Windows XP).  The executable is to run on a machine without LV installed.  The program is to interact with a stepper motor driven syringe pump via RS-232, and data is collected using a PCI-6259 DAQ card and a NI SCC-68 connector box.
My problem is that when I run the executable the program seems to momentarily freeze/pause from time to time; however, the program is able to complete fully.  I have noticed that the program seems to pause in conjunction with the computer's clock on the Taskbar; the block diagram of the program includes an "Elapsed Time" Express VI, which I have been told is related to the computer's clock.
Would anyone be able to give me some advice one what could be going wrong?
 
Thank you very much,
Karin
0 Kudos
Message 1 of 9
(3,422 Views)
Hey Karin,
At this point I think we need to further diagnose the problem to isolate where the "pause" is happening in your code. There are a couple of ways to do this ranging from using File I\O to a debuggable executable. I would start with a debuggable executable. Check out the knowledgebase titled How Can I Debug My LabVIEW Executable? I really like this tool a lot because you can use highlight execution and the other debugging techniques from the development environment with your exe.
 
Some things to look out for are race conditions , sequence of execution (are you sure you're code is doing what you think it is doing?), errors and so forth. Also try to isolate the problem to either LabVIEW or driver calls.
 
Hope this helps out.
 
Chris C
0 Kudos
Message 2 of 9
(3,405 Views)

Hello Chris,

Thank you for your reply.  I tried debugging the executable and had no luck finding the problem; the network connection is too slow when I perform the remote debugging and I was not able to observe the program run at normal speed.  I also checked the orignal vi for "race calls" and other such possible sources of error, but did not find any.
However I tried running my executable on another machine and it ran fine; that is to say it did not periodically freeze/pause.  The specs of this machine are: Pentium III 1.00 GHz processor, 496 MB Ram, Windows XP SP2.  The machine in which the executable paused/froze was a: Pentium IV 2.40 GHz processor, 512 MB Ram, Windows XP SP2.  (The development system's machine has same specs of this latter one). 
Furthermore, if this if of any relevance, the machine in which the executable ran properly did not observe the Taskbar clock to pause, while the machine in which the executable paused/froze periodically did observe the Taskbar clock to pause.  Please recall from my original post that the periodic pausing/freezing appeared to occur in conjunction with the pausing/freezing of the Taskbar clock on the PC.  I revised the original vi to use the "Tick Count" function to measure time, in place of the "Elapsed Time" express vi that I was originally using, however this did not solve the problem.

My question is this: if the executable is able to run fine on one machine, is this an indication that the problem is not within the coding of the orignal VI, and perhaps is in the PC itself?  Would you know of any settings/configurations (in either the build of the executable or PC settings) that may be causing my executable to pause on some machines but not all?   I would greatly appreciate any other possible suggestions on this matter.

Thank you very much,
Karin

0 Kudos
Message 3 of 9
(3,363 Views)
Karin,
 
You asked "My question is this: if the executable is able to run fine on one machine, is this an indication that the problem is not within the coding of the orignal VI, and perhaps is in the PC itself?", not necessarily. If you have a race condition in you code, a faster or slower PC can reveal the problem.
 
You mentioned that the clock seems to pause for a bit. What is the CPU usage at when this happens? How long does it pause for?
 
Something else you could try to really see if your program is freezing is to put down a second, parallel while loop in your main vi that blinks an led once every 100 ms. This is a good test. Let us know what you find.
 
 
Chris C
 
0 Kudos
Message 4 of 9
(3,343 Views)
I would think that if your OS appears to hang as well as your LabVIEW app (as indicated by the PC Clock freezing), that the problem would not be with your code but rather something happening on that machine which ties up the OS and/or processor for some time.  Chris is right that race conditions can be exposed more or less frequently depending on your system because they occur as a result of timing issues.  I still think it's possible it's your code, but more than likely it seems to be something with this particular system's sw and/or hardware configuration.
Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 5 of 9
(3,336 Views)
Hello,
 
I am not quite sure what is meant by implementing a while loop in parallel to the main vi, could you give me a bit more guidance on this please? 
On the front pannel of my executable, I have a chart which displays the pressure reading from a pressure transducer.  The pressure is to be regulated about a user specified pressure value, and this regulation is performed using a "PID" function.  It was my thought that program was pausing when the chart momentarily paused (i.e. ceased to update itself even though the pressure value on the transducer was changing).  Is it wrong to conclude that the program is pausing because the chart is pausing?
 
Also, the clock pauses for a fraction of a second, the exact amount of time I have not been able to measure... However I performed some tests with a stop watch: I allowed a stop watch to count up to 5 minutes and observed the deviation of the Taskbar's clock from the stop watch's 5 minute mark.  The Taskbar's clock was found to be slower than the stop watch's 5 minute mark by anywhere from 2 to 11 seconds.  Also, I performed the same test without the DAQ card inserted into the PC's PCI slot and found the Taskbar's clock to not deviate from the 5 minute mark of the stop watch.  Could this lack of pausing of the clock without the DAQ card be some indication of what the root problem of my pausing executable may be?
 
Thank you very much,
Karin
0 Kudos
Message 6 of 9
(3,327 Views)
Karin,
I'm not quite sure if DAQ could be causing the problem here.... I gues what I'm more concerned about is if your code is locking up or if your computer is locking up. One way to determine this is create a completely separate while loop in your top level vi who's only responsibility is to blink an led or better yet, look at times between iterations.
 
So to implement this, open your top level vi, create a new while loop (do not drag it around any existing items). This is a parallel while loop. You can use a blink a boolean indicator and note if it ever "skips". At that point, we'll know that it isn't your code that's freezing. The next step would be to close all external process (such as antivirus and such) that might be trying to take system resources periodically. Speaking of which, do you know the "hangs" occur with any sort of frequency? That is, is there a pattern?
 
If there's a question about DAQ potentially causing the problem, try removing the DAQ portion of your code and see if you still have problems.
 
 
 
Chris C
 
0 Kudos
Message 7 of 9
(3,312 Views)

Hello Chris and Travis,

I was able to solve my problem by updating the BIOS version on the problematic PC.  If you recall, my latest observation was that the Taskbar clock would pause when the DAQ card was inserted in the PCI slot, and my executable would pause in conjunction with the pause of the clock. 
The specs of the motherboard and BIOS revisions are:

ASUS P4B533 ACPI BIOS Revision 1011 - this one had the problem
ASUS P4B533 ACPI BIOS Revision 1013 - this was my developmental machine which had no problems
ASUS CUV4X-E ACPI BIOS Revision 1001 - this was another machine I tested the executable on; it had no problems.

I upgraded the BIOS revision to 1015 on the problematic machine and this solved the problem.

I just thought I might post this information on the forum in hopes it might help out some one else with a similar problem.

Thank you both for all your help,
Karin

0 Kudos
Message 8 of 9
(3,278 Views)

I'm glad to hear you are up and running!  It's interesting what sort of problems in your hardware or third party products can have on LabVIEW.  We've seen some interesting things over time, the main culprits seem to be video cards and DLL code, and it’s pretty unusual to see a BIOS problem that doesn't totally hose your system.  Looks like we were on track in our debugging hunches.

have a good afternoon, I wish you the best on your app-

Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 9 of 9
(3,267 Views)