Why such a long time to access VI list on RT target?

[Dr_Laine]

I start a simple small VI on a PXI-8187RT target, then switch execution target to LabVIEW for Windows.  When I switch back to my RT target, I get the message "accessing VI list" for 15 seconds.  Then the front panel of my simple VI appears, but is busy (hourglass mouse icon) for 60-75 seconds.

I am implementing a program with an RT VI that must first be started on the RT target, then a host VI on the PC that shows the front panel.  Every time I want to start this program, I have to wait 1 1/2 minutes to get control of my remote system!  Are there any settings I can check, or any reason it would take so long to bring up a simple VI from my RT target?

My System:

Windows XP P4 ethernet to

PXI-8187RT in 1002 chassis

PXI-7350 motion card

LVRT 7.1

Thank you.

[A.S.]

Hi Laine,

There are a couple of reasons why it may be taking so long to load the VI's front panel after connecting to it.

1. Your VI's front panel may be too big.  If the front panel has a lot graphs, images, etc, it will take longer to load since it takes more memory.  I would suggest making the front panel very minimal , only displaying values you absolutely need.

2. Your VI doesn't have enough sleep.  If your VI contains a while loop running too fast, with little or no delay, this could starve the communication thread.  The communication thread runs at a lower priority, so unless your VI has an explicit Wait or Wait Until Next ms Multiple function in its While loop, the communication thread cannot execute.  It has to wait for the VI to sleep long enough for it to ensue front panel communication.

Try using the Real-Time System Manager, found under the tools menu.  This will let you  monitor the memory and CPU usage of your VI without having to target LabVIEW to it. Its lot let invasive method of monitoring your RT system.

Hope this information is helpful.  Please let us know if you have any further questions.  Have a great weekend!

[Dr_Laine]

Thanks for the quick reply.

1) There is only one object on my front panel (error indicator).

2) I tried introducting a wait timer in my main loop, but I still have the same behavior.  I am using a TCP Listen.vi in my main loop.  It had a timeout setting of -1 (wait forever), but now I have put timeout of 100ms with a loop wait of 200ms (had to put a case structure around the rest of my code with error status input FALSE).  But I still have the same behavior.  Do you know if TCP Listen includes internal wait time, or does it dominate the processor until a connection is established?

Using the RT System Manger, I see that my RT CPU usage never gets above 4%, and there is plenty of free memory.

I even stopped the VI using RT Sys Manager, switched execution target back to the RT target, and this time it took 2 minutes to release the front panel!  So I think there is another problem not related to the VI structure.  Could there be some MAX setting incorrect, or even an incorrect dip switch?  I've checked as thoroughly as I know.

Some interesting behavior: if I target Windows and MODIFY the vi that is running on the RT target, then switch back to the RT engine, LabVIEW catches the discrepancy and asks if I want to update or abort.  When I click OK (update), the new VI is loaded immediately and I have full control.  It is like there were no VIs running on the RT engine, and I simply targeted it and loaded one.  So this leads me to think that the problem is in the loading of the current VI from RT engine....

Thanks.

[A.S.]

Hi Laine,

From what you are describing, you don't seem to be building a startup executable for the RT target.  One thing to check is to make sure the target doesn't have an older executable loading on startup.  You can either set the Disable Startup VI dipswitch or disable it through the BIOS (check your controller's manual on this one).  Also, ensure that your system is not starting up in Safe Mode (you can look at your controller's monitor output for this).

Do you see this behavior if you just build a small VI from scratch, that doesn't involve any TCP commands, etc.  Something simple like an adder in a while loop with a delay would be good.  Can you download the VI then retarget it quickly?  Or does it also take 2 minutes?

The Wait on Listener command doesn't take up 100% CPU because it is not a polling function.  So I don't think thats the problem.  Is your RT VI running in Time-critical priority?

Finally, another thing we can try is to run a couple of examples.  Open the Example Finder (Help » Find Examples) and go to Toolkits and Modules » Real-Time » Deploying and run the TCP Deploying - RT Engine and Host Computer examples.

This will help us isolate if the problem is indeed with the TCP functionality or perhaps some other part of your application.

Hope we can find a solution for you.

[Jaegen]

I have to jump in here and say I have seen much the same behaviour as Laine is describing.

It doesn't seem to have anything to do with the actual VI running on the RT system, it just seems that the system by which LabVIEW checks a running VI on the RT system versus it's corresponding file on the host PC, and then releases control back to the RT-targetted LabVIEW, takes a very long time.  As Laine has mentioned, if the file on the host PC has changed, LV seems to pick this up very quickly and prompt you.  But if it hasn't, the process seems to take much longer than it should.

Hope this info helps,

Jaegen

[Dr_Laine]

I am not using any startup VIs, nor am I operating in safe mode.  My loop is running in High priority, but exhibits the same behavior in Time Critical.

Some additional test data on load times (includes request VI list, load VI and release control to user) is below.  All loops use 100ms wait until timers unless noted.

Empty while loop = 3 sec.

While loop with 10 controls and 10 indicators, no operations = 3 sec.

While loop with 4 math operations and shift reg = 4 sec.

Timed loop with 1 add and shift reg = 12 sec.

While loop with TCP listen = 20 sec.

While loop with TCP listen, 5ms wait = 20 sec.

Example>TCP Communication - RT Engine.vi listening on TCP = 65 sec. (12 sec. to complete req. VI list)

Example>TCP Communication - RT Engine.vi transferring data = 85 sec. (20 sec. to complete req. VI list, 2 x wait on RT eng. to respond)

Thanks

[A.S.]

Hi Laine,

Is your system connected via  crossover network? Also, have you installed the LabVIEW 7.1.1 updates?  The updates for LabVIEW Real-time fixed some latency issues in TCP communication in RT.  Check out the readme file below that discusses the updates/fixes implemented in 7.1.1. 

https://download.ni.com/support/labview/labview_rt/Updates/Windows/7.1.1/Readme_RT.html

Below are links to updating LV Development system.  This needs to be done before updating LabVIEW RT to 7.1.1

http://download.ni.com/support/labview/updates/windows/7.1.1/readme.html

I know that this may take a bit of time to do. But we addressed some serious performance issues in this update for RT that may be the answer to your questions. Can you try this and let me know of the results. I was not able to get the same behavior as you, but I have 7.1.1 isntalled...I hope you get the same results as I do.

Have a nice day!

[Dr_Laine]

Thanks A! (can I call you "A"?)

I had no idea of this update - will try it and let you know the result.

[MF]

Just wanted to chime in with the same type of problem. I think all of these problems stem from using a cross-over cable for network. Using regular router network, we did not have the problems.

Our system was the following:

PXI 8186 Real-Time
Host computer was PC with XP Pro

We had things working perfectly at the office using the office network. When out in the field using a cross-over cable, getting into development mode was impossible because a compiled startup.exe was running on start-up. We were able to go into LV -> Tools -> RT System Manager and stop the code there. But concerned that I had turned something on by mistake, I turned off VI Server under the RT Options. Then I could not even use the RT System Manager to stop the startup.exe because it requires VI Server. I ended up calling the NI rep who told us to stop the startup.exe by changing a setting in the PXI RT Bios.

Today I had a look at the BBS on NI and there are quite a few people that have had cross-over cable problems. Please post if the 7.1.1 update solved the problems.

Michael Froehlich
WinSoft

[Dr_Laine]

I have not done this update yet, and may not with the new release coming out.

Whie targeting the host, I have been making changes to the RT code, saving, then targeting the RT system.  It still takes 15 seconds to access the VI list, but finds the changed VIs almost immediately after that and aborts any VIs running on the PXI.

If I make the upgrade, I will post the results here immediately.