Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

connection to RT engine has been lost

Hi there,
 
I'm using LabVIEW Real-Time Module 8.2.1 and have a Desktop PC as RT Target.
 
I'm now testing the limitations of the system. In oder to test this I wrote a VI that reads the Digital IN (1channel) of a PCI-6023E DAQ-card.
The read digital signal VI's are placed inside a time critical loop (1Mhz Timed Loop). Around this Timed Critical Loop a While Loop (TCL) is placed, the VI is designed to start with al low tick (1 tick) of the timed loop. Every time the timed loop is late the 'Finished Late ?' function stops the TCL and the surrounding while loop will go one iteration further and increase the tick with 1. In this way the maximum samplefrequency is found very fast, if the tick of the timed loop isn't increasing anymore this is the maximum frequency.
 
I made some tests with the VI, I got some good results with the package handling of the ethernet card in interrupt mode. The VI wordked well and the maximum tick was 50. Divided by the 1MHz clock this is a samplefrequency of 20kHZ.  But when i switch the package handling of the ethernet card to polling mode, the VI sometimes runs wel with a maximum tick of 45, but most of the time the VI doens't respond and gives the error  "Connection to RT engine has been lost" or the error "Warning: Connection to RT target (MotionRTTarget) has been lost". When I try to ping the RT target all packets are lost and no ping.
 
If i remove the outher while loop and run the VI with a fixed tick of 45, everything works fine and I don;t get any errors.
 
Does anyone have an explanation or solution for the problem?
 
Best regards,
Jens Dassen
 
Ps. The VI and screenshot is attached to this post.
0 Kudos
Message 1 of 2
(3,544 Views)
Hello Jens,
 
I have no direct explanation for the dissconects. Maybe because it is set to polling the polling rate becomes so high that it starfs the CPU of the desktop. On the other hand when that is the case you should see the same with the while loop removed.
 
Anyway, you can achief the same mechanism (increasing the period with one tick per itteration if the loop finishes late) without the while loop around it. You can set the period for the next itteration on the fly in the timed loop itself without stopping it. I have altered your VI a bit to reflect this and attached it to this post. Maybe you can have a test run with it to see if this works out for you?
 
Regards,
 
RikP - National Instruments Applications Engineering
Rik Prins, CLA, CLED
Software Development Engineer
0 Kudos
Message 2 of 2
(3,503 Views)