Remote historical data is not retrieved completely viewing it in MAX4

[cs42]

Hi,

since I installed LabVIEW 8 I have some problems retrieving historical data from another computer. Sometimes not all data is retrieved (if I zoom in or out or move back in time) and this missing data won't be retrieved ever.

I already deleted the Citadel cache once, but after this even less data was retrieved... What's really weird, is, that for channels which weren't retrieved correctly, the data gets not updated anymore!

On the remote computer I have a LabVIEW DSC Runtime 7.1 running (MAX 3.1.1.3003) on my local computer MAX 4.0.0.3010 and LabVIEW 8 DSC (development system) is installed parallel to LV DSC 7.1.1 (dev system). LV 8 is installed for testing purposes (I doubt we'll switch soon) and overall I like MAX 4. The HyperTrend.dll on my local computer is version  3.2.1017.

This is really a quite annoying bug!

So long,
    Carsten

Message Edited by cs42 on 02-02-2006 09:18 AM

[jdr_ni]

I haven't seen that before, but I will try to look into it as soon as I get a chance.

Thanks,

J.D. Robertson
National Instruments

[cs42]

Actually this does occur pretty randomly. After a while, all the missing data was shown, but on one graph I see this again today. Somehow I have the impression, that zooming out and/or panning if the data of the current range isn't retrieved yet, triggers this problem.

Thanks.

Carsten

[jdr_ni]

Hi,

We've been unable to reproduce this issue. If you could provide some additional information, it might help us out.

1) How many traces are you viewing?

2) How often are the traces being updated?

3) Are the traces being updated by a tag value change, or by the "maximum time between logs" setting in the engine?

4) What is the frequency of the "maximum time between logs" setting?

5) Is the Hypertrend running in live mode when you zoom out/pan?

6) If you disable/re-enable live mode in the Hypertrend, does the data re-appear?

7) Are the clocks on the client and server computers synchronized? If not synchronized, how far apart are the times on the two computers?

Thanks,

J.D. Robertson
National Instruments

[cs42]

Hi,

> We've been unable to reproduce this issue. If you could provide some additional information, it might help us out.

I did fear this, as even on my computer it is happening just sometimes...

> 1) How many traces are you viewing?

The views I observed this in had 2 to 13 traces.

> 2) How often are the traces being updated?

For some it's pretty often (about once a second), for some it's very infrequent (no change in data, that means updated because of max time between logs). I more often see this for traces that are updated very infrequently. But I think I've seen this for frequent traces as well (for these it does work currently).

> 3) Are the traces being updated by a tag value change, or by the "maximum time between logs" setting in the engine?

It happened for both types.

> 4) What is the frequency of the "maximum time between logs" setting?

Max time between logs is 10 minutes.

> 5) Is the Hypertrend running in live mode when you zoom out/pan?

I think it happened in both modes, but it defenitely did in live mode.

> 6) If you disable/re-enable live mode in the Hypertrend, does the data re-appear?

I couldn't trigger the loading of the data. All I did is wait and work with MAX (zooming, panning, looking at data) and after quite a while (some hours), the data appeared.

Just tested this on a view where data is missing (for some days now!), and it didn't trigger data reloading. Zooming and panning don't as well. There's a gap of up to 3 days now for some traces. 7 of the 13 traces of this view are incompletely shown. All stopping at the same time but reappearing at different ones.

AFAIR from the laboratory computer (these are temperatures and it's very plausable that these didn't change), there wasn't any change in these traces so they all got logged because of max time...

I just created a new view and added these traces: the gap is there as well.

(Sorry to put this all in this entry even if it is related to you other questions, but I started this live test with disable/re-enable live mode. )

> 7) Are the clocks on the client and server computers synchronized? If not synchronized, how far apart are the times on the two computers?

They should be (Windows 2000 Domain synchronized to ADS), but are 5 seconds apart.

One thing I remember now: I have installed DIAdem 10 beta 2 (10.0.0b2530, USI + DataFinder 1.3.0.2526). There I had (and reported) some problems with data loading from a Citadel Database of a remote machine as well. This was accounted to some cache problem. Maybe a component is interfering?

Thanks for investigating.

Cheers,
    Carsten

[erblock]

I'm having the exact same issue it seems, with Lookout 6.02 and remote client Hypertrends.  Additionally, the problem occurs with MAX 4.0 traces.

So far, I've been able to verify that this problem occurs to some extent on every remote client I've tested so far (8 machines).  It appears to be independent of how remote the client subnet is.  The behavior is sporadic, varies from one machine to the next, and even varies by each clean install of client and process files.

It does seem that the data eventually appears, sometimes after more than a week.  I've had chunks of a few minutes, hours, days missing on remote Hypertrends or MAX traces, sometimes all the traces (4 to 😎 and sometimes different chunks of each trace.

NI folks....PLEASE confirm or deny and update us on investigation and/or fix probability and timetable.  This BUG makes remote history checks very annoying and prevents this method form having credibility and otherwise well-deserved showmanship.

Thanks,

Ed

Lookout thread reference: http://forums.ni.com/ni/board/message?board.id=190&message.id=4192

[jdr_ni]

I was never able to reproduce the behavior described in the original post. I did discover a similar bug. If the client application was not shutdown cleanly (crashed, killed, power loss, etc.), the client machine would no longer be able to retrieve particular data pages. This issue was fixed with LabVIEW DSC 8.2.

Also, as Ryan posted in your other thread, short-term gaps in the data are expected behavior.

I will talk to our support engineers and see if we can provide you with the latest Citadel part, so you can see if that resolves your issue.

J.D. Robertson
National Instruments

[erblock]

Thanks for taking a look JD....

Well, the current Active X control for web clients does crash Internet Explorer whenever you refresh or try to manually close the window...so there may be some linkage here.

However, even the client process run under the newest Lookout Full Development version exhibits the sporadic hypertrend displays...ONLY if run on a machine remote from the citadel....

I would like to understand how this should be considered "normal" or "acceptable" especially with plentiful CPU resources on the Citadel server, Gigabit connection on the server end and the client end (I'm talking...it is easy to see 6 MB/sec transfer rates between client and server when moving files, yet the hypertrend traces only need a small fraction of that to quickly transfer many days of data.

I'm not talking about trace gaps that can be quickly recovered by scrolling the trend or changing the trendwidth.  I'm talking about gaps that persist through all sorts of attempts to get a complete fill, including complete uninstal and reinstall of lookout development or client software, etc.  It really is annoying when you expect to investigate an issue that occured over the weekend, or yesterday, or within the last couple of hours, and find there is nothing you can do to get the data...other than physically getting to the machine where the data is stored.

Thanks Again!!

Ed

[jdr_ni]

The type of persistent gaps you are describing are not expected behavior, but short term gaps that disappear after one or two trend updates are expected.

If any applications on the client machine crash during data replication, then all applications on that machine will be affected.

As a workaround, you can destroy the Citadel data cache by shutting down all client applications and the Citadel service, deleting c:\Program Files\National Instruments\Shared\Citadel\__LocalCache, and then restarting the client. However, you will also need to restart the Citadel service on the data server or wait 10 minutes before re-querying for the data. The Citadel data transmission algorithm does not expect data files to be manually deleted by the client and will not re-synchronize after a short-term disconnect.