Lookout 6 Hiccups

[skibum019]

Sorry, this is a bit long winded....

I seem to have found the case of some of our hiccups with Lookout 6.0. We had been having problems with client workstations and extremely slow or now historical data trending on their clients. I had checked many things, including rebuilding the server and client processes, using ActiveX Trend vs. Lookout Trend and visa-versa, we used both an upgraded database and new database from scratch, etc.... I had spoken with support numerous times and they all had me trying different fixes.

NOTE:
Client Computers Discussed are Windows XP Professional SP2
Server Computer is a Windows 2003 Server Machine

One of our new client computers would not update historical trends at all, live data was fine, it would read that data and you could see it updating, but any historical trending would not work at all. I noticed that there is a new folder structure under the following (this will vary depending on your server computer's name and your server's database you are connecting to) "C:\Program Files\National Instruments\Shared\Citadel\_LocalCache\_monet_\_c__program_files_national_instruments_lookout_6_0_database_". I noticed that on machines that were trending historical data properly (or at least as properly as they could be, still slower then 5.0), there were files in this directory that seemed to be duplicating the database file structure on the server's machine, on the machine not trending, there were no files or just a log file (don't really remember). This raised my question about how the server and client communicate when using trends, I never got a straight answer from support, except to say that they talked to R&D and supposedly this folder has nothing to do with the historical trending on the client computer.
***HOWEVER***
During a recent non-related software upgrade, we found an issue with user rights assignments on Windows XP Professional workstations where for some reason, if a user was part of more then one group and they were a part of the "USERS" group, they would receive restricted access on the local computer even if they were a part of "POWER USERS" or "ADMINISTRATORS". We ended up having to make users part of the "POWER USERS" group only, to solve the unrelated problem. After doing this, the user with the non-functioning client noticed that the trends started updating on his computer.....and low and behold, there is now over 200MB of data in that cache folder, something tells me that the cache folder just might have something to do with the historical trending on 6.0 client computers. Hopefully at some point this post will either give someone some insight to a similar problem or at least any other database related issues they may be having with Lookout 6.0......or at least amuse someone.

If this all sounds a little sarcastic, it probably is....
Don't get me too wrong here, I do appreciate the new functionality provided with 6.0 and the new Citadel 5.0 database structure, but I think there are some serious inefficiencies in how the database functions and it seems like there is a major lack in documentation and knowledge on how it operates in the background.

[AWBlair]

We have been having significant problems with 6.0/Citidel 5.0 i.e. MSSQL with about 250 data points. We have found work arounds for the Client TCP problems, but cannot resolve the MSSQL issues. Were are running a clean W2000SP4 with one client. Periodically the database becomes corrupt and or the system crashes and must be restored. We have duplicated the problems on independent sets of hardware. Seems like every two or three weeks some other problem crops up. We cannot seem to get NI to resolve our issues. I am about ready to give up on NI and switch back to WW.

[Ricardo_SR]

Hello,

We are aware of some issues that Lookout version 6.0 has and because of that we have worked very closed to customers that were affected by it. So far we have been able to work on fixes and workarounds for these problems. Please check on the Lookout Update Page for any updates. Some of the hypertrends problems are already fixed under a patch. For any other problem you might have, please open a SR and that will help us give you a fix or workaround and get that feedback to the R&D group.
For the MSSQL issue, if you could provide us with more information. It would be great if you could give us a SR# or something that could give us a better description of the problem. So far we have not heard of any problem like the one you describe, so we are interested in knowing more about it.

Thank you

Ricardo S.
National Instruments.

[skibum019]

Yes, I am and have been aware of the fixes for sometime now, and I have worked with support.....too much......Over the last few months, I have opened numerous support calls and discussed my issues a number of times with tech support. HOWEVER, they were never able to appropriately answer my questions, and as I stated in the starting thread, I was given incorrect/inacurate information, this is extremely frustrating! I was told that the local_cache directory on the client machines does not have any effect on the hypertrends....HOWEVER, I know this is not an accurate statement. Machines without any files in this directory, do not show trends. Machines with files in this directory do. I have machines that have somehow stopped updating this directory...those machines have trends up to the date of the most recent file in the directory, and nothing after that. This is not a problem with the database on the server, the server machine can open the client application and show all trends properly...this is a problem with the cache directory not updating properly, but nobody has given me any information on how this update occurs. I will be calling again to open another support request, and I will be addressing this problem directly.

[fixthis]

I have been having similar issues with lookout 6.02.

1.  Hypertrends do not work effeciently meaning that I am seeing signal trends appear and disappear.
2.  Hypertrend historical data window does not update when moving the cursor across the trend chart.
3.  Lookout crashes while editing.

I followed tech support's suggestions on re-installing 6.02 with their guidelines and registry cleanup utility and have installed files based on their recommendations.  All this and nothing appears to have made any difference in 6.02's performance.

OP sys: xp w/ sp2.

[DimensionFinder]

Hello There:

This is strange. I have spoken with tons of customers who have had successful experiences with Lookout 6.02. However, I am glad that you have brought this to our attention.

Does Lookout crash when any object is edited or modified or is there a particular scenario in which this happens?
Does the hypertrend update at all or is it just the cursor that gives this issue?
Lastly, what objects are you using in your process?

Thanks,

Jaideep

[fixthis]

1.  Lookout has crashed when trying to create a spreadsheet object, when adding signals to hypertrends, when creating pushbuttons and switches, and when adding signals to the database.

2.  The hypertrend chart updates, but the signals do not always appear.  But when wanting to look at values of the signals in the hypertrend, the data window that pops up for the hypertrend does not update the data while moving the cursor across the hypertrend chart.

3.  I use a variety of objects in my processes such as spreadsheets, pushbuttons, switches, animators, etc. 

Any information would be greatly appreciated.

Thanks,

fixthis

[Doug M]

fixthis,
I am unclear on what exactly you are seeing.  "hypertrend chart updates, but the signals do not always appear."  Do you mean the chart keeps scrolling, but the signals disappear?  When you say "data window that pops up for the hypertrend does not update the data while moving the cursor across the hypertrend chart." I assume you are referring to the cursor data window -- what method are you using to move the cursor -- by clicking the arrows on the Hypertrend, by clicking on the cursor itself and moving it, by clicking the arrows in the Cursor data window, or by manually changing the time in the Cursor data window, either by using the arrows or typing a new time in?

Does this happen with both the Lookout Hypertrend and the NI ActiveX Hypertrend object?  Does it happen when only one trace is on the Hypertrend or only with a larger number of traces?

We are very interested in knowing about Hypertrend/Citadel issues customers are experiencing, but unless we can reproduce the issue or have a very clear understanding of what is going on, it is very difficult to determine what the cause is or any possible fixes -- is it possible for you to post screen shots, and a very simple process file that will reproduce this problem?

[fixthis]

Hello Doug,

The charts scroll, but the signal doesn't always appear.  Even when we scroll back using the cursor or the arrow buttons, the signal does not appear.  The cursor data window does show the values of this signal in this situation.  It is as though the signal is not being recorded to the database in that particular time frame.  If I scroll back further into the past, the signal is there.  I usually restart the server when this happens and it sometimes corrects this issue.  This happens when looking at the hypertrend object, and not the activex hypertrend.  It also happens on hypertrends that have 8 signals and ones that have more 8+ signals. 

I also noticed that this problem happens more on client computers.  We have the same version of Lookout on our client computers as well.

[Doug M]

fixthis,
Thanks for you information.  Let's get some more details -- so this happens on the server computer, and not just the clients? If so, we can rule out a networking issue.  If the ActiveX Hypertrend can see the data, it is not a database issue.  If the data has been recorded to the Citadel database, it should be viewable at anytime by the Hypertrend or NI ActiveX Hypertrend, even after restarting the process -- so we need to figure out whether the data is actually being recorded to the database.

You mentioned that it happens with 8 or more signals.  Does it happen only with 8 or more, for example with only one signal?  Is it every signal that stops showing up or just one or two, but the rest update fine?

Again, any screenshots or code?