-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initializtion Issue #21
Comments
Could be an issue with the dependencies. I would suggest referencing the GSF assemblies (e.g., GSF.Core.dll and GSF.TimeSeries.dll) that were installed with the openHistorian in your adapter project and rebuilding - this way you are using the same assemblies as the openHistorian that will be using your adapter. |
Richie, |
Perhaps the function is throwing an exception? Have you checked the ErrorLog.txt? Have you tried (1) putting code in a try / catch, or (2) attaching to process with a debug build with a break point in the initialize function? Can I see a copy of your |
Actually, I haven't written a try/catch clause. The thing I wrote is a process percentage log in the Initialize() function. I debugged the code in Project Alpha, all the break points were hit, it ran well, and it reached 100% success. However, in openHistorian, even the 10% success was not even reached. Here is the code: public override void Initialize()
|
That's a big initialize function. One quick thing jumps out, what is the Note that by default the openHistorian gets installed with the If your folder path is anywhere else on the system, the Thanks, |
Ritchie, |
The best suggestion I have is to compile the adapter in debug mode, copy the DLL and the associated PDB file into the openHistorian installation folder. Then while running Visual Studio as administrator, attach to the openHistorian process, i.e., from VS menu select "Debug > Attach to Process" and find openHistorian.exe. Once attached put a break point in the |
Great! Glad this is working. |
Hi Ritchie,
I am trying to replay the local historian data (V2.2.2.0) to debug our action adapter codes. However the built-in local historian input adapter(openHistorian 2.0 (local)) crashed the openhistorian.exe when I initialized it. It seems it established a connection then the openHistorian was disconnected. The input adapter is named “FNETSREAMER”. Here is the message:
[cid:image003.png@01D29F50.3DB94DC0]
Here is the configuration of the input adapter, the outputMeasurement is a self-defined measurement as ‘Analog Value’.
[cid:image004.png@01D29F4F.2C47EE30]
This happened in every machines where we installed the openhistorian V2.2.2.0. I am not sure if I was doing it right. Your help is appreciated.
Ferriad
FNET
From: J. Ritchie Carroll<mailto:notifications@github.com>
Sent: Monday, March 6, 2017 3:06 PM
To: GridProtectionAlliance/openHistorian<mailto:openHistorian@noreply.github.com>
Cc: Ferriad_Wang<mailto:wwk55551111@hotmail.com>; Author<mailto:author@noreply.github.com>
Subject: Re: [GridProtectionAlliance/openHistorian] Initializtion Issue (#21)
Great! Glad this is working.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#21 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHMsfbxFcD-Y8WSEFAAaIHpIsAp0pgdGks5rjGckgaJpZM4MTrEw>.
|
Hi,
I was trying to write an action adapter to handle the FNET event. I put the built adapter under the openhistorian V2.2.2.0 directory and I saw it in the openhistorian manager. Then I configured the parameters and click 'initialize'. However, there was no message on the console although i had written the onStatusMessage() in the initialize("xxxx"). I also wrote a log logic to check, but it seemed the logics i wrote in the initialize() were not called. In order to ensure my code was right, I debugged the same code (but different dependencies) for the latest Project Alpha V0.2.107.0. This time, it seemed the initialize() ran well, and so did the publishFrame() logic. I could not figure out where was the problem. Any suggestions?
Best,
Ferriad Wang
FNET, UTK
The text was updated successfully, but these errors were encountered: