LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Real-time controller paused by Ethernet timer

I have the LabVIEW 2018 SP1 real-time module running on a PXIe controller. I'm getting unexpected delays at ~10 minutes after startup and again exactly 10 minutes later, then no more. I ran the real-time trace tool and discovered that an unknown thread is pausing almost every other thread in my application for ~1.8ms. This unknown thread is titled "Terminated (Name Unknown)" and runs on one CPU while the other CPU is mostly idle. It seems to start right after "ETS TCP/IP Timer Thread". I'm trying to figure out how to remove that 1.8ms delay from my real-time application. I've only determined that "Terminated (Name Unknown)" refers to a thread which ends before the trace is stopped. Any help would be appreciated.

Thanks, Glen

0 Kudos
Message 1 of 4
(1,082 Views)

It seems likely that your code is generating this additional thread.  I'd guess that it is one of the first 100 functions that your code executes (but this is only a guess).  Maybe if you posted the code that seems to cause this to occur, one of us might be able to make a "better guess" ...  Note, however, you'd need to post the actual code, best done by compressing the folder containing the LabVIEW Project containing all of your code and attaching the resulting .zip file.

 

Bob Schor

0 Kudos
Message 2 of 4
(1,031 Views)

Bob,

I'm also in touch with tech support. They asked if I could produce a small dummy application and this is what I sent them:

 

Labview code and trace file attached in .zip file.

 

The LabVIEW project is Debug_app.lvproj.

 

It contains a portion of the code which sends 80 byte messages out a serial port every 2ms.

 

The problem is that it gets interrupted about 10 minutes after startup and then again exactly 10 minutes after that.

It appears to never happen again after that.

 

The receiving subsystem detects the gap and interprets it as packets with the wrong length, which is an error.

 

My debug code detects the anomaly in one of three ways and stops the trace:

  • If a timed loop iteration is late.
  • If the elapsed time to write to the serial port is longer than normal.
  • If the gap between serial port write is longer than normal.

In this particular case I don’t know which criteria stopped the trace but it does show where the timing of the messages got interrupted. If you configure flags and enable the user 0 flag, there’s a distinctive pattern which is interrupted. The calling thread in write_loop.vi logs user event 0 before and after calling VISASynchWrite_Other1.vi. VISASynchWrite_Other1.vi logs user event 0 at three places. In the trace, there is a thread (2 in this case) called “Terminated (Name Unknown)”, which appears to be initiated by the “ETS TCP/IP Timer Thread”, and suspend all other system activity for a few ms.

 

The controller is a PXIe-8115.

The serial module is a PXI-8433/4.

It’s running LabVIEW 2018 SP1 real-time module.

 

Thanks,

Glen

0 Kudos
Message 3 of 4
(1,007 Views)

I am ending this thread, because I have more information and wish to start with a better title and more complete and concise description. See https://forums.ni.com/t5/LabVIEW/Ethernet-timer-blocks-serial-activity-in-real-time-PXIe/m-p/4133447...

0 Kudos
Message 4 of 4
(845 Views)