Lookout

cancel
Showing results for 
Search instead for 
Did you mean: 

Future of Lookout - Updates?

Still actively developing on Lookout, but also have ClearSCADA in our portfolio. We were planning to go InduSoft, but stalled on that until the need arises.

 

Start a new thread detailing your issues.

 

Biggest thing we are seeing right now in Lookout is driver related (Lookout Drivers, not Windows).  Although it adds to the cost, we have deployed OPC servers that seem to resolve most issues.  I was recently contacted in regards to the GE driver grabbing information from a completely different site/driver!  

 

As for licensing costs, atleast for now, Lookout is holding, even with 3rd party OPC server added compared to others.  But with Schneider and Invensys picking up all the other players, and with LabVIEW a laborartoy and scientific focus, NI may soon be out of the running for our SCADA and HMI systems.

 

 

-----------------------------------------------------------------------
Forshock - Consult.Develop.Solve.
0 Kudos
Message 21 of 31
(3,976 Views)

Jeff,

 

What kind of problems?  Overall, I've had excellent server performance with Lookout 6.5, 6.6 & 6.7 in Win7-x32&x64, Srv2008R2, Win8-x64, Win8.1x64 and Srv2012R2.

 

There are a few things which can really make your life easier.  I run redundant server processes simultaneously on two separate machines and protect them such that the chances they are both down at the same time are very, very small.  I use simple symlink switches to choose which server data to dispay in all client processes.  

 

I save system updates for process shutdown windows whenever possible and manually control updates on critical processes such that only one server of a given process goes down at the same time.

 

Set the .ini file setting "AskBeforeShutdown=0" and make sure you always save changes in your server processes.  This will prevent "rogue" or forced shutdowns of Citadel during remote shutdown commands or windows updates which is how most database problems occur.

 

I run all my server processes in virtual machines which just makes things easier if you have the resources.  The reboot times are also much faster.  

 

I run Lookout as a service on all my server process machines.  For very large Citadel databases (over 5 GB or so), I have better luck if I set the Lookout service startup as Automatic - Delayed Start.  This gives Citadel time to get its stuff collected prior to Lookout server processes wanting to work with it.  It is particularly helpful during a restart after a forced stoppage of Lookout, in which case, Citadel usually works extra hard to detect and repair database corruption.

 

The client side is a little more shakey, but honestly, less worrisome also.  Hypertrend traces do not like any disconnects from the server and for the most part, the client process needs to be reloaded after a server disconnect or reboot has occured and reconnection is complete.  For this reason, I've converted all my client processes to web clients.  In IE10 & IE11, even though they usually crash when refreshed, they automatically reopen after the crash and it just seems simpler for folks to hit F5 or mouse click the IE refresh icon and acknowlege the crash than to reopen the client file with the Lookout menu.

 

Also, I've had issues with trace/data intensive hypertrends causing screen flashing and/or lockup issues in Lookout 6.6 & 6.7 which are much less apparent and intrusive when they occur using the web client.  The web client is buggy and tricky but once you get through that it actually performs quite well.

 

If client hypertrend traces could properly survive disruption/reboot of server process connectivity, I would be extremely happy with Lookout.  NI has acknowledged this "bug" and I would be surprised if it was not addressed before the next release.

 

It is a bonus that Labview and Lookout can use the same database.  It has been 17 years since NI bought Lookout from Georgetown Systems with the hope that they could port Lookout's technology to LabVIEW and replace Lookout.  Of course that dream has been a lot tougher to achieve and I'm not sure LabVIEW will be able to depart from loop based deterministic timing or allow online compiling anytime soon Smiley Frustrated

 

The only reason Lookout has survived this long is because it's original designers were that good!  If NI had kept promoting Lookout to keep/gain customer base, I can't imagine it being anything less than a rock-solid secondary SCADA market powerhouse by now.  But they just robbed it's technology for LabVIEW and stopped all but the bare-minimum in support and development.

 

I'ts not to late to change that NI !!!!!  But time is running out.

 

Ed

Message 22 of 31
(3,967 Views)

Thanks Ed.  Since our upgrade to 6.6, we have had many issues with the communications between the servers and clients, but more importantly, I've seen incorrect data displayed on the Servers.  The servers are talking to the field devices thru mostly RS-232 serial ports.  The drivers are set to pole once a second.  I came in yesterday and saw what were obviously wrong numbers.  I'd never seen this behavior before. 

 

To "fix" it, I modified the expression and typed the exact same text back into the "yellow line" and the data updated to correct values.  What is strange, is the data was fine until we had to restart the computer due to a windows update.  When the process reopened, the value went from 0.0 (which was correct) to 35.4.  The trends showed the signal being 0.0 for 12 hours before the restart, but after it was 34.5.  I "modified" the expression by typing the same expression and it went back to 0.0.

 

The driver object is set to pole once a second, so how this could happen is beyond me.  But as you can imagine, is very troubling.  Have you ever seen behavior such as this?

 

Again, thanks for your input.

 

Jeff 

0 Kudos
Message 23 of 31
(3,958 Views)

We are currently fading out Lookout.  We are looking to replace Lookout with Proficy iFix or Inductive Automation Ignition HMI SCADA package.  Due to lack of support and worry of the software being discontinued are the 2 biggest reasons for the switch.  

 

Thanks,

Mike Warner

MWarner
0 Kudos
Message 24 of 31
(3,956 Views)

JMiller:  You mentioned that you had bad data show up on your system inside, what drivers are you using?

-----------------------------------------------------------------------
Forshock - Consult.Develop.Solve.
0 Kudos
Message 25 of 31
(3,948 Views)

Yes, I have seen this and also in Lookout 6.7.  Trends are fine but Lookout data is old.  I'm usually able to refresh and/or restart to correct the issue and I've only seen it happen on clients remoted from a different subnet (actually far away, on a different Class A network).  I can't say I've never seen this issue on clients within the same building, even on different class B subnet, but it would be much more rare for me.

 

All my clients are 6.7 or 6.7.1 now and I plan to bring all my servers to 6.7.1 early in November.  I will report back any changes in behavior, especially since this will be the first time since Lookout 6.1, that I've had all servers and clients with the same version of Lookout.

 

I have reported this issue and have not heard back as to whether NI confirms the behavior.  One tip for this would be to make sure your clients are connectable to the server with only a machine name (no IP address maps or FQDN maps).  I control DNS on clients and NIC registration on servers to make sure there is no confusion as to how the client finds the server.  I almost guarantee that the cause is a bug relating to logos, computer names and IP address maps.  I've been able to almost eliminate the issue with safeguards similar to the above.

 

I would like a comment from Ryan on this....

 

Ed

0 Kudos
Message 26 of 31
(3,943 Views)

We're using the Tiway, Modbus, Ascii, and DNP driver objects.  The particular instance I mentioned in my post was a DNP object. 

0 Kudos
Message 27 of 31
(3,920 Views)

That is interesting, as we refer to the server machines via their ip addresses.  Our client expressions are similar to: "\\192.168.101.10\process\item"

 

You are saying this is not the proper approach and the expressions should all refer to the computer name.  With some effort I could make these changes, but as I mentioned, what is most concerning is the data is incorrect on the server machine itself which is polling a dnp object once per second.  On the server, I have created an expression that reads the data from the DNP object, and do some math on the number from the DNP object.  We then log the result of the expression to the historical database. The result of the expression is what has shown to be incorrect.

 

 

 

 

0 Kudos
Message 28 of 31
(3,919 Views)

The IP addressing issue goes way back to early Lookout 5 or maybe 6.  You can search the forums for this.  At the time, I think it was only Hypertrends that needed the machine name (as if it was on the local subnet).  They probably have fixed this by now (Citadel 5?), but I got in the habit of never using IP addresses and It has worked great for me both on local networks and from around the US.

 

Now your original post was not clear that this was occurring on the server!!!  That is another story altogether.  There are a couple things I would look at to get to the bottom of this.  These are things where I have seen problems but didn't necessarily make sense of them.  Instead, I just worked around them.

 

1.  I always place driver object data into data tables.  Very rarely, do I reference driver object data directly, either digitally or with Hypertrend.  Back in the old days, you could not log driver data so if you wanted trends, you had to put the driver data into data tables first.  I stuck with the old methods even after driver objects allowed data logging.  I have had one or two problems with direct driver data access but did not find out why and just went to the data table method to solve.

 

2.  Check for circular table references or multi-stage table references.  I think they have improved this also since I last had a problem because I get lazy frequently and have not seen the issue reappear lately.  Here is the "old" issue.  If you connect one table cell to another, along with a calculation, sometimes it did not work.  I use multiple tables so for example if I connect driver1.M40001 to table1.A1 and then use a second table to perform the math operation on the data such as table2.A1=Table1.A1*100/3.14159 and reference table2.A1.  The example above, technically would not be a circular reference, even if done with a single table.  I don't remember exact examples and not sure if the problem was truly a "circular" reference or just convoluted multi-stage, etc..  For sure, I have seen issues with multiple calculation within the same table causing incorrect data displays without any Lookout alarms!

 

Those are the only two things that I can recall "for sure" have caused bad data displays, other than networking issues.  I cannot say I've seen any changes in proper availability of data at the server with Lookout 6.2 through 6.6.

 

After reading your post again...

Do you have the expression object logging to database?  You could connect that expression back to a data table for logging and then display from the table's cell.  This is what I would do routinely.  To save on Citadel space of course, I would remove logging of the expression object and only enable logging of the table.  I do not have experience of how reliable the expression object logging would be but as a matter of course, I think that logging anything with a calculation involving another data object is a risky practice (for success with Lookout, anyway...).  I've definitely seen similar issues before, so I started connecting objects or data table cells with connections that include calculations - to other cells, using those "result" cells for trend connections and data displays.  Hope this makes sense...  It's late 🙂

0 Kudos
Message 29 of 31
(3,908 Views)

Thank you Ed.  I understand your method and we will try it and see what happens.  I appreciate the information you have provided very much.

 

Jeff

0 Kudos
Message 30 of 31
(3,902 Views)