LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Process freezes for a few seconds


@Basil-B wrote:

Have you tried CoastalMain's suggestions in the previous two posts? The boolean should help us narrow down where the problem is arising, whether its from the read processes being slow on the network or whether its the writing and graphing properties. 


I tried a variation of it. With the block diagram open, I clicked on the 'Highlight Execution' button immediately after the program paused. The very first highlighting activity showed dataflow coming out of the TCP Read vi. Every 'highlight execution' click produced exactly the same results.

 

Note, there are two sequential TCP Reads. The first one reads a header which tells the second one how many bytes to read. It is the second TCP Read that is pausing, as if it were waiting for data to come in. The TCP Write that feeds me the data, does the write in a single operation (it does not write the header and then write the data).

0 Kudos
Message 11 of 12
(300 Views)

@Les__Bartel wrote:

@billko wrote:

@Les__Bartel wrote:

The plot thickens...

 

The computer has 3 NICs. Everything works fine with one or both instruments on ONE NIC. Unplug the non-essential instrument from the switch and connect it to a 2nd NIC (either one of the remaining NICs), and the network stops briefly every 14 seconds. Data is buffered from the essential instrument and we catch up when the network wakes up again. Note that the non-essential instrument that gets plugged into the other NIC is not configured properly to talk on that NIC. If it is configured to talk on the 2nd NIC, it does communicate properly, but we still see the freeze every 14 seconds on both instruments simultaneously.

 

This is beginning to look like a Windows network problem.

 

I did find mention to a CAR (313508) that may be related, but I haven't been able to find much info about that CAR.

 


Do you think that maybe configuring the "non-essential" instrument to properly work on the NIC should be part of the troubleshooting process?

See my bolded text. I tried to say that I ran it both configured and not configured.

 


My apologies.  I msiread it.  I missed the "if" at the very beginning of the sentence, and without that key word, it became confusing to me because it seemed as if it was configured incorrectly for the second NIC, which I did think was odd, since you said you were connecting it to the second NIC to begin with.  At any rate, I was following this thread because it seemed to be a very important topic to be following.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 12 of 12
(300 Views)