Emerson Exchange 365

• Not Answered

Delta V 7.3 Historian issue

We are having issue related to continuous Historian 

Tag found in Bad scan items log....and also it is in PHIST.SCR...i have added in history collection downloaded the app and dvnist but still m getting the real time data not the history and for testing purpose i have made few custom modules and added in history collection all are going in badscanitem.log

for more analysis i have added both pv.cv and out.cv but still not able to solve the issue

few things i should add here

App Continuous Historian showing bad at overall integrity where as old tags are making history and showing as well

DVNIST Continuous Historian also showing bad at overall integrity

If the parameter in the phve file is not the exact parameter in the history collection for the module, you'll get real time data for the parameter but not the history. this i already checked and its same

Sami Uddin

• 30 Jan 2018 6:48 AM
• Cancel

13 Replies

• Youssef.El-Bahtimy

  

  • 30 Jan 2018 11:01 AM

  Can you read the tag in watchit.exe? If you add the tag to history collection prior to downloading the underlying control module, or the quality of the value is not good, the historian will not create the tag. Phv will let you see real time via opc for any running parameter, but the chart must be configured for the exact parameter path that is historized and be pointing to the right historian to view the history.

  • Cancel
• Sami Uddin

  

  • 30 Jan 2018 4:13 PM

  In reply to Youssef.El-Bahtimy:

  watchit.exe never used...but i was finding it was unable to find in bin as some in earlier post i read about watchit.exe...i m not using any Opc..its Engineering station application station and 2 operator station... i tried to make it active at engineering station but the result is same it is not recording...or creating history but showing real time value ...version is deltav 7.3 and have pi ...

  • Cancel
• Andre Dicaire

  

  • 30 Jan 2018 5:29 PM

  In reply to Youssef.El-Bahtimy:

  Note that PHV realtime data does not come from the History node. PHV gets the realtime data directly from the source module. You need to confirm with Watchit on the Historian Node to see if the server can "see" the module.
  
  If Watchit fails to read from the module (use the MODULENAME/MERROR.CV path) then it is likely the Module is not defined in the workstation's runtime database. You can verify the DVDATA/Download/MODT.SCR file date stamp matches the Pro Plus. If not, Auto Update services is not sending the global data to this node.
  
  I would start with confirming the Historian server has the latest MODT.SCR file and that Watchit can read the data you are trying to historize.

  Andre Dicaire

  • Cancel
• Sami Uddin

  

  • 31 Jan 2018 6:21 AM

  In reply to Youssef.El-Bahtimy:

  Yes i can read the tag in watchit.exe....how should i resolve if the historian did not add the tag but i added in history collection so after adding in history collection and downloading the module and downloading the app and pro station it should be working and creating history but it is not doing it

  • Cancel
• Sami Uddin

  

  • 31 Jan 2018 6:24 AM

  In reply to Andre Dicaire:

  Mr Andre Dicaire
  
  watchit is showing the value with the message coming RT_SUCCESS
  MODT.SCR time stamp matching

  • Cancel
• Sami Uddin

  

  • 1 Feb 2018 12:35 PM

  Waiting for further things to see

  
  

  • Cancel
• Sami Uddin

  

  • 1 Feb 2018 2:34 PM

   DVPI.log file in dvdata.  showing me license point exceeded (in pro plus ) with the tag which is not historised but application station has 1350 points license out which only 337 are used nd in engineering station it has 250 out which only 247 are used ...where as some fatal error msg is present in DVPI .LOG
  

  
  

  Deltav 7.3 with Pi  

  
  

  PHIST .txt => showing tag on historian node 
  

   badscanitem.log  => showing tag showing tag in historian node 
  

  MODT.txt => showing tag on historian node
  

  auto update service is working

  watchit on the historian node showing me the data 

  
  

  it started to happened when we were installing a new application station and for taking back up we stopped pi services...after running pi start command old tags before stooping pi creating history but eventually we have to add vibro meters put them on trending but it does not historize...seen in thread regarding dis legacy matter wrt pwd must match deltavadmin but i think that is not the case with mine ...

  
  

  • Cancel
• Andre Dicaire

  

  • 1 Feb 2018 4:05 PM

  In reply to Sami Uddin :

  Well, we now know the issue is not in the comm layer, but in the Historian. We also know that this is a PI database. In 7.3, DeltaV introduced the Continuous Historian, but allowed existing customers to carry the PI database forward as the "Legacy Historian". In v13, DeltaV has re-integrated the PI historian as the Advanced Historian. So by staying on v7.3 for so long, you've saved yourself migrating to the Continuous Historian when you eventually upgrade:-).
  
  
  You've confirmed that the App Station with assigned license of 1350 History tags has only 337 tags assigned to it. Yet it is indicating BADSCANITEM for tags that are configured in the runtime database: Module name is in MODT.SCR and history Tag is defined in PHIST.SCR, and that the tag is communicating to the App Station as seen with Watchit.exe.
  
  This tells me the issue is limited to the Historian. This being a 7.3 system, it has been quite a while since I worked with this and the PI Scanner.
  
  The PHIST file contains all the Tags that DeltaV wants the history server to collect. This file is read by the history configuration process that creates the tags in PI and the Scanner process creates the runtime connection to the data sources via DeltaV communication. When the scanner is unable to process an item, it adds it to the BAD Scan ITems log. What I cannot remember is whether this is the result of failing to create the tag in the PI database, or failing to read data from the DeltaV Communication layer. We've confirmed that all the configuration information is in the runtime database files.
  
  It would be good to know if all tags are not scanning or just new ones. Like, how many tags are good and how many are bad. If there were 250 good tags, I would wonder if the license scale ups are properly applied in the App station. Not expecting this to be the case, but it would be an important detail.
  
  There are a set of PITools that get installed, and I don't remember any syntax. These are command line interfaces that allow you to see the pi tag configuration. If the tags that are not collecting are not configured in the PI database, we would be looking at that. If they are in the database, then we are back to data collection, and why the DeltaV PI scanner cannot process data into the archives.
  
  The right place to get this resolved is with the GSC. They have access to all the issues relating to 7.3 systems and PI Tools. But being at v7.3, you likely don't have Guardian support. Your next option is to get help from your local service provider.
  
  This may be a simple issue with a simple fix, and having me or others suggest solutions could make things worse. Also, I can't take the time to investigate this on your behalf. I'd love to be able to tell you what the issue is, but I just don't recall what the root cause of these symptoms might be.

  Andre Dicaire

  • Cancel
• fairchdm

  

  • 1 Feb 2018 7:54 PM

  In reply to Andre Dicaire:

  Sami Uddin,
  Since you have a PI Historian you might try going to the OSIsoft tech support website.
  There is a large user community that will answers questions, much link Emerson Exchange.
  If you have an Enterprise PI Historian they might provide you some assistance with your historian problems.
  I have always received excellent support from OSIsoft.
  
  Dennis

  • Cancel
• Andre Dicaire

  

  • 1 Feb 2018 8:18 PM

  In reply to fairchdm:

  I don't think OSI will have any information on issues with DeltaV 7.3. This is an embedded solution where DeltaV provides the PI database configuration and data scanning. The BAD SCAN ITEMS log is a deltaV created log by the DeltaV scanner. You should reach out to your DeltaV service provider.

  Andre Dicaire

  • Cancel
• fairchdm

  

  • 1 Feb 2018 9:47 PM

  In reply to fairchdm:

  Sami Uddin,
  
  Depending on your PI configuration buffering might not be enabled.
  Just something to try and see if your PI Historian is collecting data.
  
  If you are using the PI Buffer subsystem, you can monitor the buffers using pibufss -cfg.
  On the interface node,
  1. Open a command prompt.
  2. Navigate to the PIPC\bin directory.
  3. Type pibufss -cfg and press Enter.
  The output shows the activity on each buffering queue.
  Run this command two or three times, several seconds apart, and compare the Total Events Sent and Queued Events.
  A Healthy Output for a PI Collective might look like this:
  
  C:\Program Files (x86)\PIPC\BIN>pibufss -cfg
  
  *** Current buffer sessions, count: 2
  
  1 [hx-2003r2-x64] state: SendingData, successful connections: 1
  firstcon: 6-May-10 11:51:50, lastreg: 6-May-10 11:51:50, regid: 8
  total events sent: 10, snapshot posts: 4, queued events: 0
  
  I had PI Historian with my DeltaV ver.7.3 also. OSIsoft tech support was well versed in how DeltaV interfaced with PI Historian.

  • Cancel
• Sami Uddin

  

  • 2 Feb 2018 6:00 AM

   Only New ones which i m adding after Stop/start at piserver ..Old tags are making history and showing history in fact few tags are in bad scan log which are also making history and showing it only  the tags which are added after pi server stop/start is not recording
  
  

  
  

  • Cancel
• Andre Dicaire

  

  • 2 Feb 2018 3:01 PM

  In reply to Sami Uddin :

  I did some digging, and that leads to more questions...
  
  The issue is apparently with the PI server. However, suggesting an action without confirming it is the right one is dangerous. Also, if you are not familiar with the PI commands, and end up making matters worse, you could lose all you history data.
  
  My first an most important recommendation is that you confirm you have a valid and complete backup of you Historian before you try to resolve any issue with the PI server. I recall one customer who asked for help recovering his system after a disk crash, but he had no backups. Not a good day for him...
  
  If you have back ups, do you know for sure that they will work? Again, many customers make backups, but never test their recovery procedures, or they don't have any. When an event occurs and they attempt to recover, they find they did not capture key information and had simply copied files. You must use your recovery procedure at least once to confirm it will work.
  
  Specifically for PI, the ARCHIVE files contain data, but do not contain any tag information. You cannot simply register an archive to a database and read data. The archive stores against an Index. The Index is defined in the PI tag database. You must recover the PI database in order to recover the archives. For instance, if you had to rebuild you DeltaV App Station and you simply redownloaded the DeltaV Historian configuration, the new App station would rebuild the PI Tag database. However, the tag indexes would be assigned anew. The PHIST file is in alphabetical order. The original database was built over time, and new tags would get the next available Index. On a new station, the PHSIT tag order would not be same as the chronological order the original database was created. The result would be your Historian has no History. If you have a complete backup, you would also need to recover the PI Tag database that aligns with your archives. Otherwise your archive data will be incorrectly indexed to the wrong tags.
  
  Back to your issue. I found a couple of incidents relating to the "pitimeout.tbl ". new tags being added were showing up in the BADSCANITEMS file. The resolution was to stop the PI system and copy in a "good" file from another location. But I'm not sure if you can simply copy this file from one of the other DeltaV Stations and restart your PI server. You can also try to learn a bit more about this file. Maybe Google it.
  
  There were also calls where the PI database itself had overtime been configured with many tags that had since been deleted. These tags were no longer in the DeltaV configuration, but had never been deleted from the PI database. Eventually, new tags could not be added. The solution was to purge the old files. A utility is provided to do this. I doubt this is your issue given the number of tags in play.
  
  The DVPI.log, and PI EventQdat_file.log may also contain additional information about the issue.
  
  I'm back to strongly urging you to engage a knowledgeable expert who can evaluate the root cause and fix this without doing more damage.
  
  As a matter of course, technical support would always try to reproduce an issue to fully understand it. You could consider enabling a Historian on one of you other stations ( assuming it will be a PI server) and then trying things on this server as a test system. For instance, if you want to find out more about that PITIMEOUT.TBL and how to replace it. Maybe copy the one from the App Station and see if that recreates the issue. IF it does, then you can try to fix it by restoring the "good" original. And if that works, at least you know how to do that.
  
  But if you do try something, and it makes things worse, like you lose all history collection, you will be in much more serious trouble. You could spend a lot of time and make things worse. And then you'll need someone immediately. Really suggest you engage your local service provider.

  Andre Dicaire

  • Cancel