Delay when viewing data from remote panel

[Milqman]

I have a Desktop RT target in my lab.  I use a laptop as a host machine.  I would like for the applications that I develop to be usable by some of my coworkers.  To this end, I set them up with the run-time engine and used the webtool to make a remote panel. 

When I deploy the application freshly on to the target, and they start the app, they have perfect control (in the timing sense).  If one of them closes their window, and another starts using it, it appears that they have proper control too.  Unfortunately, I have discovered that this is not the case.  While they are looking at their screen, I have unplugged the transducers that they are reading.  The graph they watch does not reflect this for quite a long time (on the order of minutes).  Clearly, the data they are receiving is from a cache or a buffer.  It is important that the data be close to real time (they are monitoring thermocouples and adjusting fuel rate to a burner in order to keep constant temperature).  Having a lag is both unsafe and impractical for this purpose.  I have not yet determined the exact source of the time lag (as far as period is concerned).  I think it might be the amount of time that passed between the two different viewings of the remote panel.  I have also not determined what effect stopping the application and restarting it has on this apparent lag.

Is this a known problem?

Is there a workaround?

Is there a fix?

Thanks a bunch,
~milq

[Steven_C]

Hi Milq,

Could you please let me know what version of LabVIEW RT you are using?

One thing I suggest that you try is adding the token "FPUpdateRate=100" to the ni-rt.ini on the target. Please let me know if this fixes the problem. Thanks!

Best regards,

Steven C

[Milqman]

LabVIEW Real-Time 8.2

The issue that I am talking about is not an updating delay, it is updating normally.  The problem is that the data that is being graphed is from an earlier time period.  Everything is graphed frequently enough, but there is some cahcing problem that gives data that already happened.

For example, I start up the remote panel on a computer, everything works fine, I stop the application with the stop button.
I open it up on another computer, and run it.  The graph looks fine, but when I unplug a transducer, it takes a minute or two for it to register (register meaning show a zero value).  This time lag between events occuring, and them being reflected on the screen is unacceptable for my application.  I am monitoring the temperature of something that I am heating, and adjusting a flame to compensate.  That time lag between reality and visualization makes the job unsafe and uneffective.

The time lag seems to be popping up when the application is closed and then opened, or run in a state other than freshly deployed.  Is there a way to deploy the application from a remote panel?  I am developing the app, and I have control over the RT target, but as it is, the person that is using my apps needs to come and ask me to deploy it whenever he needs it.  Which is fine as long as I am at my desk, but sure enough, we have slightly different schedules.

I am suprised no one else has seen this lag, or maybe they have seen it, but their phenomenon is slow enough to where they do not notice.

Any ideas on how to resolve these issues would be great.

Thanks,
~milq

[TCPlomp]

Could you hook a Monitor to the RT system?
And send the actual value from within the VI to the monitor (use debug string)?

Maybe you have just a great back-log  in your system?

Ton

[Jolt]

This is an old thread but closely describes some behavior I have with a RT target (cRIO) running 8.6. When connected to a PC over the network using remote panel all is well in the beginning but after time (~1hour) significant lag appears. Frustrating.

Additionally, the target CPU "creeps" up - eventually running at or near 100%! (Starting from less than 70%) The CPU reports a large increase working on "Timed Structures."  

In shorter tests (~40min) with the development machine running in debug mode (no remote panel connected) I do not see any CPU creep.

I need to do a little more research (like leaving the development machine connected in debug mode for a LONG time to see if there is CPU creep) but if my problem is related to remote panel and there was some insight generated from this thread please post the conclusions.

Again, this might be unrelated and probably deserves a new thread but its worth a shot here anyway... 

Thanks,

-Jolt

[Jon_S.]

Hello Jolt,

The difference  between running a remote panel and the VI in debug mode on the development machine is where the front panel is running.  When you run the VI in debug mode the front panel is acutally running on the host machine.  When you run the VI with the remote panel you are running the front panel on the RT target.  This can make a difference on how much memory is being used on the RT target.  If you were using a chart that keeps an infinite history length you will eventually run out of memory.  Moreover, you have to redraw this array each iteration of the timed loop.  Take a look and see if you are displaying and updating large chunks of data on the front panel.  If this is the case you may want to consider running a host VI on the PC that is updated by Shared Variables, TCP or UDP communication.

[Jolt]

Thanks Jon,

The "where is the Front Panel running" was something I was not clear on. Your other points are well taken but I think my situation does not apply. I have a couple of charts but limit their history to 100 points - everything else is numeric or simple strings. Furthermore, I see no increase in memory usage - just CPU utilization and especially the "timed structures" designation (what exactly does that mean?).

I already have most of the important data in shared variables but just haven't put time into create a test host app - I will probably try this on a limited basis ASAP.

After I posted I gathered some more info and went ahead and started a direct support request there at NI. I will probably post (or start a new, more specific thread) if/when we find out what is going on.

Thanks again for the reply - I am always eager to learn so don't hesitate to throw more wisdom/suggestions out there!

Cheers,

-Jolt