Recent Control & Safety Systems Discussions
Similar Posts
Extracting History Collection Data
DeltaV using Data Compression for history collection
Alarms and Events stoped collecting data for paticular Area assigned
Removing History Collection
DeltaV History collection Issue.
Share

Missing data in Historian (Collection).

(Version 12.3.1)

After adding an extension license to the Continuous Historian Application Station, extra parameters are added to the historian. Unfortunately not all added parameters are collected.
The license count was increased from 3000 to 4000.

The actual status of the Historian Application Station is:
License properties:
- data values used: 3195
Diagnose reports:
- Downloaded 3165
- BadRead: 24
- DcLoad 1.5 .. 5 (varying)
- DiLoad 0.6
- HsLoad 0.7.

badscanitems.log shows the unscanned items, which all can be seen using WatchIt.
All parameters show:
State: Disconnected
DataType: Unknown
LastReadCode: RT_LOCATING

What can be the cause of this problem and how could it be solved?

Maarten van der Waal

9 Replies

  • Andre Dicaire
    I'm not able to find any reference to the read code RT_LOCATING. As you know, DeltaV automatically resolves paths in the runtime system, using the downloaded module table. The referenced parameter is found by its host node, Module (or container) name and a valid path within the module. I tried to reproduce this based on my demo system but I cannot recreate a scenario where Watchit returns RT_LOCATING.

    Since you know which parameters are misbehaving, can you focus on one and give us more information? Is this a diagnostic parameter, Module parameter, or what? You stated that all the badscanitems.log parameters can be "seen" using watchit, but you then say they are all disconnected, Unknown and RT_LOCATING. So they actually cannot be seen using watchit? Please clarify.

    Watchit results I can explain:

    This is based on an example tag for exploring some known errors: MOD_NAME/BLOCK1/ATTR.CV

    Code: Description:
    666 LOCATE_FAILED (i.e. "MOD_NAME/BLOCK1/ATTR.CV") The PATH is valid, but not found in the Module Table (it is not assigned to a node or does not exist)
    (i.e. "MD_NME/BLOCK1/ATTR.CV") The Module name is misspelled.
    666 INVALID PATH (i.e. "MOD_NAME/") The Module exists, but the path structure is invalid, such as no attribute defined
    (i.e. "MOD_NAME/PARAM1.") The path is invalid, because a period is present, which requires the field to be defined. If no period is there, CV field is assumed.
    60 RT_NOT_CONFIGURED (i.e. "MOD_NAME") The module name is incorrect or the path is incomplete. With the "/" watchit does not see a valid module name
    59 RT_NOT_COMMUNICATING The Module host node is not communicating, and may be disconnected (The client node is aware of the module but there is no response)
    You also see this if the path is incorrect, such as a misspelled Function Block.
    31 RT_INVALID_ATTRIBUTE (i.e "MOD_NAME/BLCK) The module exists, but the path is incorrect, such as a misspelled Function Block name.
    32 RT_INVALID_FIELD (i.e. "MOD_NAME/BLOCK1/ATTR.SV") The path has an invalid field.
    0 RT_SUCCESS (i.e. "MOD_NAME/BLOCK1/ATTR.CV") full path is valid and parameter exists.

    The module table in the Historian Application station uses the Module Name in the path to look up the host node where the module resides. It than makes a request to create a Proxy Client/Server to have that node send the defined parameter.field by exception, based on the update rate of the History tag. If the module is not in the MODT.SCR file, or if the source node is not communicating, you get a "LOCATE_FAILED".

    If someone is willing share a complete list of possible Watchit Response codes, that would help.

    Andre Dicaire

  • Maarten van der Waal

    In reply to Andre Dicaire:

    Andre, thanks very much for your reply.

    Your reply indicatesI was unclear about the status of the parameters
    (1) The parameters can be read using WatchIt giving a status string 'SUCCESS'.
    (2) The indicated status words in my first post are found in the badscanitems.log.

    The parameters exist: downloaded items having values found by WatchIt.
    These parameters however cannot be found by the Continuous Historian.

    The question is: how can I make the Continuous Historian read existing parametervalues, where they are reported in the scanitemsbad.log as described above?
  • Andre Dicaire

    In reply to Maarten van der Waal:

    That is much clearer. Are you using Watchit while logged onto the App Station or from a different station? If not, log on to the App station of the historian and let us know if the values return SUCCESS.

    I'm at a loss as to why these parameters would report successfully to Watchit on the App Station, yet fail to bind in Continuous Historian. Please provide more details about these parameters, such as their path, what version of DeltaV the App station is running. If you can open the PHIST.SCR file with Notepad and post the definition for one of these parameters, along with the Watchit window results.

    I found an issue with the Condition block expression view where by if you enter the path in the expression in lower case, the expression viewer fails to find it at run time. The lower case path is not valid and DeltaV communication layer looks for upper case only. What if the path in the PHSIT.SCR file is in lower case? Watchit forces the path to uppercase, so the same path would work.

    Do any other parameters work from the same location? what is common about the paths that don't work? do they have similar names? Similar locations? You've shown the system is not under licensed, or overloaded. I don't have any other explanation at this time.

    Andre Dicaire

  • Maarten van der Waal

    In reply to Andre Dicaire:

    Andre, thanks again for your reply.

    The History collecting Application Station is working using
    - Windows Server 2008R2 (v6.1Build7601:SP1).
    - DeltaV v12.3.1 Build 5219 (updated with 1231_WS_09_CSS)

    The missing parameters are mostly new added items.
    However a small number of old items is also missing Historical data.

    Using WatchIt on the collecting Historial Application Station, it appears that the badscanned items report status LOCATE_FAILED.
    On other workstations, RT_SUCCESS is reported for the same items.
    Collecting Historical data from another workstation results in collected data for the 'missing' parameters.

    A full download of the Application station did not give a change.
    A full download of the Setup Data on the P+ (to include the Module Table) did not give a change.
    Diagnose shows the status of the DeltaV network in GOOD condition for the primary and secondary network for all stations including the History collecting Application Station.

    Below lines from PHIST.SCR are shown, where between brackets the status shown in WatchIt on the collecting station is given.

    (WatchIt: LOCATE_FAILED)
    PHLI
    {
    PATH='XV1107/PV_D.CV'
    ENAB=T
    CDEV=0.1
    RATE=10
    STEP=2
    CONT=T
    MAX=86400
    }

    (WatchIt: RT_SUCCESS)
    PHLI
    {
    PATH='BV427/PV_D.CV'
    ENAB=T
    CDEV=0.1
    RATE=10
    STEP=2
    CONT=T
    MAX=86400
    }

    All above indicates that the History collecting Application Station is not able to locate the module.
    Apparently the module table cannot be read correctly from this Station.
  • Andre Dicaire

    In reply to Maarten van der Waal:

    The fact that Watchit gives a Locate Failed status tells us the App station's Module table (MODT.SCR) does not have the module names, or the Device table (DT.SCR) does not have the node. This information updates via Auto Update service (Yellow Pages). You can confirm if these files are up to date by comparing the files in the DeltaV/DVData/Download folder on the App station and the Pro Plus.

    I would expect that all parameters for the affected modules will behave the same. If you have some modules from the same node that are collecting, that will confirm the issue is not with the DT.SCR but the MODT.SCR. You can open these files in notepad (open notepad and drag the file. They are viewed by Windows as screen saver files, but are in fact text scripts. You cannot modify them as they are checksummed).

    Workaround may be to copy the MODT.SCR file manually from the PRo Plus to the App Station. Could auto Update be turned off for this node? Let us know if the affected modules are in the MODT.SCR file.

    Note that the node identifier is used in the MODT file, and this is correlated to the Node name in DT.SCR. Or you can view the Node Identifier under the Properties/Advanced tab of the controller.

    This is not a Historian issue. It is a runtime communications issue and once you can connect with Watchit on that node, History tags will work.

    Andre Dicaire

  • Maarten van der Waal

    In reply to Andre Dicaire:

    Andre, thanks again for your excellent reply.

    I agree fully with your conclusion.

    First of all in the download directory of the History collectiing Application Station between several .SCR files, no (!) DT.SCR nor MODT.SCR files is present...

    Opening the Auto-Update Service Control indeed shows that for this station none of the 3 checkmarks ischecked.
    So I set the checkmarks, click on 'Set' and the message 'Auto-Update successfully changed on all selected workstations' appears.
    So far so good, but downloading the App station, its Setup Data or the Continuous Historian did not show any change.

    So I reopened the Auto-Update Service Control and saw that no (!) change was made for the auto-update for this station.

    So now we have the challenge to set the auto-update for this workstation!

    I manually copied the DT.SCR and MODT.SCR to the download directory of the App station. No result.
    After this a download of this station, the Continuous Historian nor the Setup Data from the P+ gave no result...
  • Andre Dicaire

    In reply to Maarten van der Waal:

    Not sure why there is no MODT or DT file. Without these two files, DeltaV would not find any tags. Could these be "hidden"? Are there any SCR files listed?, PHIST.SCR for instance? Does it's time stamp align with the Pro Plus?

    Is it possible this station was reconfigured such that there is a DeltaV/DVData/Download folder on the C drive and on the D drive? check in both locations if they exist. Also modify the Windows Explorer "Organize/Folder Search Options and select to show hidden files. I'm fishing as I don't know why these files would not be there, or why when you copied it, it still did not appear. My thought is if you mapped the App station drive on the pro plus, you would have had to select the shared folder, but if this is under the C drive and you are looking in the D drive, or vice versa, that might explain it. Just guessing.

    You should consider logging a call with the GSC. They may be aware of an issue and if not, this would need to escalate to get a resolution.

    Andre Dicaire

  • Maarten van der Waal

    In reply to Andre Dicaire:

    Andre, thanks for your answer and conclusion.

    I assisted my client remotely this week and was on site today.

    I looked at error messages on Windows and DeltaV level. Several messages was found that a directory could not be found.
    Suddenly I saw the whole YellowPages directory missing! Somehow this directory must have been lost completely.
    After a simple copy of the YellowPages directory from another Application station to the History collecting Station suddenly the needed files came to their location, so the Download folder was populated with .SCR files.
    Also the Auto Update Service Control showed all checkmarks.
    All parameters now were found with the status RT_SUCCESS and all configured parameters were collected.

    Andre, thanks very much in cooperating! You directed me in the unexpected and good direction.
  • Andre Dicaire

    In reply to Maarten van der Waal:

    You are most welcome. Glad you were successful in resolving this, and letting the community know what the source of the issue turned out to be.

    Andre Dicaire

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.