hypertrend trace sloped or stepped?

[erblock]

What version of Lookout and what OS?

[dc@aci]

Version 6.1  Build 27 on Windows XP.

How do I force the system to save the data to Citadel when it is zero so this will not happen?  This is my 3rd time to ask this question but no one has responded.  Can someone from NI answer this please?

[Ryan.S]

To answer your question first, Citadel actually is saving the data if it is zero. The "ghost point" is being used if the data value doesn't change. For example, on your first screenshot, the LPS-W Line 2 had the same value from 9:36 to 9:58. During this period, it is a horizontal line, which means your Citadel worked correctly when the value was not changed. Value 0 or 10 make no difference to Citadel. Citadel doesn't care whether it is 0 or 10, it just logs the data. So I don't think the problem is in Citadel.

Also from this screenshot, the trend disappeared from 10:05 to 10:20. It apparently that the "ghost point" is not logged. I suspect the data quality was not good at that moment, which means Lookout didn't get good data and didn't log anything. Then, after it gets a good data again, the trend connects the last good value to the current one.

I need more information to identify what's wrong. Please make a diagnostic log file. I want to check if the modbus object gets the correct response from the PLC. Maybe when the pump is off, the PLC response is not zero, but a value with bad quality?

If the trend is from Modbus serial, select Option->serial port, enble the Diagnostic file for the serial port, input file path such as d:\log.txt, check Value in Hex. If you use Modbus Ethernet, select Option->Modbus Ethernet Option, enable it, input file path such as d:\. After this problem happens again, give me the log file.

What's the timout you set for the Modbus object?

[dc@aci]

Thanks for the response.   The value of zero is displayed on other pages and I am 100% sure that the data quality is good.  I have already verified this by clearing the value to a non-zero number and then watching it change back to zero.    The value is provided by the OPC client and not modbus.  The PC is connected via 100 MB ethernet to the PLC which is 5 ft away.  Communication between the PC and PLC never has interruptions.  The OPC server is OPTO22 Mistic Data Server and has been used on this project for over 10 years.  This issue never appeared on the previous version of Lookout (4.5).

Not to confuse this issue with others but I have also seen this same response with Moscad drivers aquiring their data over a wireless network with delays of over 30 minutes. 

Any other ideas? 

[erblock]

Connect Data Table object cells to driver object (OPC Client).  Display Data Table members in Hypertrends.  The only issue here is if citadel connectivity is lost, Hypertrends will display last updated data from Data Table until connection is reestablished and cells are updated by driver.  I get around this by using Multistate objects to display a greyed "Offline" across the hypertrophy to make it obvious that data is not "live",.  I use timer to trigger the Multistate upon appropriate time without "update" data member of driver object being fired.  You can also use the gauge object to grey out live digital data.

You will only see real traces based on real data (except when comms are down) and there will be no interpolation between live point changes).  For example, if flow was 100 when comms were lost, the data table will straight-line 100 until comms are restored, at which point the Hypertrophy will jump to the new live value immediately).

Ed

[erblock]

There were some early issues with 6.1 Hypertrends.  Did you apply updates/fixes?

[dc@aci]

What is the current build number?  I stated that we were using build 27 in an earlier post to this thread.  I would assume that Ryan would have caught this if there were updates. 

Ryan... are there updates to the Hypertrend past build 27?

[Ryan.S]

There is a Hypertrend fix, but it fixes a crash issue. It's not the same one as yours.

Lookout 4.5 used Citadel 4 database while Lookout 6.x uses Citadel 5, and we also modified something in driver object, so it is possible that Lookout 6.x has different behaviour from Lookout 4.5. But it doesn't mean lookout 6.x works incorrectly.

The problem with wireless network and Moscad is expected and easy to explain. The horizontal line on the hypertrend is because the "ghost point" is logged. When the data is updated and the value doesn't change, the "ghost point" will update its timestamp, then the Hypertrend loads the "ghost point" and you will see the trend on Hypertrend keeps going as a horizontal line. But if the remote device doesn't reponse for a while, for example your wireless network has 30 minutes delay, there is actually no data updated, then the Citadel will log nothing. The trend on Hypertrend will stop at the last live data. Then, after a while the response comes to Lookout and update the data, Citadel will log this data and the Hypertrend will draw a line from the last live data to the current one. There will be no horizontal line because there was no incoming data during this period.

So it is possible that the same thing happens on opc communication. The data quality is good, but maybe it is not updating. I'd like you to log the opc communication. Make an opclient.ini file in Lookout folder. Input

[opclient]
DiagnosticPath=D:\

The communication log file will be saved in D:\. Each opclient object has a log file with the object name. After the problem happens again, give me the file. If it is too large, upload to ftp://ftp.ni.com/incoming

Ed is right that the datatable may be a workaround. No matter if there is live data, the trend on datatable cell will keep updating.

[dc@aci]

I will get this setup. Probably take a couple of days to respond since I do not have access to the system.

[dc@aci]

Ryan,

I forgot to mention something.  The trend during a flow of zero actually does not draw the line.  You can see this on the images I previously sent you.  You stated that it should.  It does not draw a "ghost point" line for the MOSCAD system either.