WHY??? C Program = No Delays, Labview = Delays >> Intermittent delays in subroutine serial RS232 loop 115200 Baud. Windows 7 LV 2012

[bdwhaley]

In 30 years of LabVIEW development I've not seen such a strange problem.    Maybe some one can help me  out.    

Here's the problem:  

Large 1,000 ms delays intermittently occur across two instances  of a LabVIEW executable at the same exact system time.  (SEE ATTACHED  TIME STAMPS SCREEN CAPTURE FOR COM 11 and COM 14 where there was a > 1000 ms delay)  

• The subrotine RS232 communication loop  was ported over from a "C" program that ran rock solid and  didn't have this same problem. 
• No logging to the hard drive occurs in this subroutine , just serial communication.
• The executables are running on the same DELL  7910   high performance server communicating with satellites that orbit the earth 24x7.   (RS232 115,200 Baud,  Windows 7,  6 processor threads).    
• One executable is using COM 11 and the other is using COM 14. 
• The executable has a time critical   "subroutine" loop  that drops CRITICAL data if there is more than a 100ms delay.    
• The subroutine is not reentrant because it is the only instance used in the entire program. 
• I have placed time markers in the subroutine loop that tell me exactly where in the code the delay has occurred.  In most but not all cases the delay occurs at the "WAIT MS"   or  "WAIT UNTIL NEXT MS MULTIPLE"   I've tried both,  and they both have the same intermittent problem. 
• What gets me is that the executables that are running independently of each other are logging the delay at EXACTLY the same  instant.    This leads me to believe it is an operating system issue.  Or some problem that the two executables  have when competing for time critical system resources.  
• This intermittent delay  problem happens on other computers and on windows XP
• The large delay happens even when there is just one Executable  running.
• This problem is especially bad when the user resizes or drags the window of the  executable.
• If the system is left alone,  the > 1000 ms delay problem may happen only  once or twice a day. 
• I have not yet attempted to set the processor affinity  or execution priority in task manager
• The executable is also running some other non time critical loops that perform SQL database entries,  logging to the hard drive,  and state machine management.  

Would love to hear from somebody on this.    

Thanks,  

Brad Whaley  

Electrical Engineer @ Boeing

[Bob_Schor]

If you are running Time-critical Code in Windows (as opposed to inside a Real-Time OS, such as LabVIEW RT), you have to be wary of Windows processes/services deciding "It's my time to have the CPU".  Not only does this include things like Antivirus/Malware software, but "automatic updates" and other routines that do "who knows what or when".

Have you considered repurposing a PC as a LabVIEW RT platform?  Have you looked to see what tasks and services are running in the background?  Do you know if there is a burst of network activity from your PC at the time of the "pause" (could be innocent or nefarious)?

Bob Schor

[crossrulz]

Time Critical = You should be using an RT!!!

The fact that it happens with just one executable tells me that Windows is just deciding to do something else for a little bit of time.  With both, I could make the case that you were competing with each other for resources due to VISA or something.

[bdwhaley]

Why does the C program not have this problem?

[billko]

I'm not sure why, but LabVIEW graphics has always seemed to be very CPU intensive if you do stuff like resizing a window while it is executing, or if controls are overlapping.  I think that's because of the way LabVIEW redraws stuff.

Maybe something on the front panel is causing LabVIEW to do a bunch of redraws, enough so that you are occasionally late, and with resizing, any hopes of being on time are dashed?

[altenbach]

---

@bdwhaley wrote:

• The executable has a time critical   "subroutine" loop  that drops CRITICAL data if there is more than a 100ms delay.

---

Can you be a bit more specific with the terms:

• Is the subVI set to "time critical" or "subroutine" priority? (and if so, why?)
• How is the call setup?
• You are talking about a "subroutine loop". What is that? Is this a timed wile loop with a certain priority settings or something else?
• Is the front panel of the subVI closed when testing? Is debugging disabled?
• Does it work better if you use more normal priority settings?
• How is the "drops data" implemented? (Timeout, polling, etc.).
• ...

[crossrulz]

---

@altenbach wrote:

Can you be a bit more specific with the terms:

• Is the subVI set to "time critical" or "subroutine" priority? (and if so, why?)

---

Well, it cannot be "subroutine" priority if VISA or Serial is involved (asynchronous nodes are illegal in subroutine priority VIs).

[natasftw]

How are you communicating with a satellite if you have to operate within 100ms?  The time to travel there and back is closer to 700ms.

If you're looking for 100ms, you're going to be talking to something in between the PC and satellite aren't you?

Beyond that, it's hard to really say what's different between the C and LV code.  We've seen neither.  You say "ported."  Did you duplicate the code?  Did you turn the C code into DLLs and call those?  How did you port the code?

Why would it happen at the exact same time?  That does sound like the OS looking to do something more time critical.  Why wouldn't this impact the C code?  Hard to say without seeing the code.  Do you have a GUI associated with the C code?

[altenbach]

---

@crossrulz wrote:

---

@altenbach wrote:

Can you be a bit more specific with the terms:

• Is the subVI set to "time critical" or "subroutine" priority? (and if so, why?)

---

Well, it cannot be "subroutine" priority if VISA or Serial is involved (asynchronous nodes are illegal in subroutine priority VIs).

---

I just was trying to understand the terminology used. The term "subroutine" is used as a priority in LabVIEW, while code is typically called a "subVI". We definitely need to see some code to help further....

[bdwhaley]

Hello -   this is a follow up post from a previous topic some of you may have already addressed, but I realize that I didn't lay out the situation well enough and I want to start fresh.  

OBJECTIVE: I am trying to match the performance of a C program doing high speed RS232 communication with Satellites through Modems.  

Background:   

• For years the  C Program has done all the RS232 communication at 115,200 .  It has no GUI and runs from a command prompt.   We don't see this C program having intermittent delays and dropping data.  
• When we used LabVIEW to replace the  C program    we experience intermittent delays causing lost data anywhere between 100ms to 1,000ms delays at the "Wait ms"  function.  
• Take a look at the attached diagram image to see our code.
•   In the labview program  we have a VI  that reads the bytes at the serial port and parses the data    
• we configured the  execution option  to "time critical"  and made the problem get a little better.  
• The intermittent delays happen 1 - 5 times each day  with no human intervention.  
• The intermittent delay problem gets 100x worse in the LabVIEW program when moving the front panel display around the desktop, minimizing it,  or resizing it,
• I know the immediate answer is to use labview real time,  but  is there any other options besides that?  

Note:  There are hundreds of PCs running this program and doing SQL, FTP,  RAS Dialing, and other stuff,   so we can't easily convert them all over to LVRT.