5 Replies Latest reply on Dec 5, 2018 8:28 PM by JaredGoretzky

    OPC HDA interface - stops after initial scan - all tags stop getting data

    JaredGoretzky

      Hello,

      We have been using an OPC HDA interface and it has suddenly stopped working.  It has been working based on the defined scan classes to pull data from the OPC HDA server, but we are finding it has stopped.  When we restart the interface it does a complete history recover for all of the scan classes but then stops getting data.  The service is still running and I see no errors in the log window.  The OPC Server has been verified to still be running and serving data via testing with the OPC HDA test tool (Pi and Matrikon versions.).

       

      All of the tags just stop getting data.

       

      Does any one have suggestions on how to troubleshoot this issue further?

       

      thanks,

      Jared

        • Re: OPC HDA interface - stops after initial scan - all tags stop getting data
          Lal_Babu_Shaik

          Hi Jared

           

          I would request you to create two counters one -  device status and other I/O Rate. Also increase the debug level on the interface and isolate any points in errors from he interface. This will help you to identify the issue and you can use trouble shooting steps in OPC guide based on the error.

           

          Thanks,

          Lal

          • Re: OPC HDA interface - stops after initial scan - all tags stop getting data
            gmichaud-verreault

            If you have the interface set to History Recovery Only (/hronly), the interface will shutdown once it reaches the endtime. Could you share your interface configuration (last line of the .bat file)

             

            Gabriel

              • Re: OPC HDA interface - stops after initial scan - all tags stop getting data
                JaredGoretzky

                Hi Gabriel,

                Yes that is one of the first things I checked was if it was set to History Recover Only. Since it is behaving like it is. 

                 

                here is the BAT file line:

                "C:\Program Files (x86)\PIPC\Interfaces\OPCHDAInt\PIOPCHDAInt.exe" 1 /EA=0 /GS=500 /MA /SA=0 /SERVER=localhost::UnifiedAutomation.UaGatewayHDA.1 /MP=30M /PS=NC_CUS_OPCHDAUA_1 /ID=1 /host=NAME:5450 /pisdk=0 /maxstoptime=120 /PercentUp=100 /perf=8 /UFO_SYNC=\\NAME\UniIntFailover\PIOPCHDAInt_NC_HDACUS_5.dat /UFO_TYPE=WARM /UFO_ID=1 /UFO_OtherID=2 /f=00:00:60,0 /f=00:00:05,0 /f=00:00:60,0 /f=00:00:60,05 /f=00:00:60,10 /f=00:00:60,15 /f=00:00:60,20 /f=00:00:60,25 /f=00:00:60,30 /f=00:00:60,35 /f=00:00:60,40 /f=00:00:60,45 /f=00:00:60,50 /f=00:00:60,55

                  • Re: OPC HDA interface - stops after initial scan - all tags stop getting data
                    gmichaud-verreault

                    Is your other interface (failover pair) sharing the same configuration. To perform history recovery on startup, you should have /hi in your configuration file. History recovery is performed at interface startup and when the connection to the OPC HDA Server has been re-established after a loss of connection. On a per-point basis (for both scanned and event tags), the interface will use the timestamp of the last good PI Archive value or the /hi=x command-line parameter, whichever is closer to the current time, to determine how far back in time to retrieve data. In this context a “good” PI Archive value means one that is not a system digital state.

                     

                    With your current configuration, one would expect it to make a 1 min historical call every minute. Are the clocks between the OPC Server and the OPC Interface in sync?

                     

                    If you review the startup logs, can you make sure that the same flags are being passed.

                      • Re: OPC HDA interface - stops after initial scan - all tags stop getting data
                        JaredGoretzky

                        HI Gabriel,

                        I ended up raising a call with support since we needed to find a quick solution.  BUT you were basically on the correct path.  The servers are in separate domains that don't have time syncing between them.  So the PI Node is about 60 seconds in the future.  And the after the initial HDA call the subsequent ones would be in a time period that didn't exist to the OPC server.

                         

                        After we added Start/End Time adjustment (secs) the behavior improved. Now it is just a tuning the correct Adjustment.

                        With support we turned up the debugging and monitoring on a single tag and these errors were in the log.  They indicated an issue with the data set being empty, and then we realized the time issue:

                         

                        D 04-Dec-18 12:30:03
                        PIOPCHDAInt:PIOPCHDAInt:NC_CUS_OPCHDAUA_1 | 1 |
                        1         (5)

                        >> Error in Data = OPC_S_NODATA in OPCHDA call. Point
                        206151

                         

                        D 04-Dec-18 12:30:03
                        PIOPCHDAInt:PIOPCHDAInt:NC_CUS_OPCHDAUA_1 | 1 |
                        1         (5)

                        >> HR = 1, number of Values read = 0. Point 206151

                         

                        D 04-Dec-18 12:30:03
                        PIOPCHDAInt:PIOPCHDAInt:NC_CUS_OPCHDAUA_1 | 1 |
                        1         (5)

                        >> Error in Data = OPC_S_NODATA in OPCHDA call. Point
                        206152

                         

                        thanks for the suggestions everyone!

                         

                        Regards,

                        Jared

                        1 of 1 people found this helpful