Skip to content
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

Closed
wwang72 opened this issue Mar 6, 2017 · 10 comments
Closed

Initializtion Issue #21

wwang72 opened this issue Mar 6, 2017 · 10 comments

Comments

@wwang72
Copy link

wwang72 commented Mar 6, 2017

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

@ritchiecarroll
Copy link
Member

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.

@wwang72
Copy link
Author

wwang72 commented Mar 6, 2017

Richie,
Yes, I was doing the way you suggested. I used the assemblies in the openHistorian V2.2.2.0 to build my adapter and tried to run this adapter on openHistorian V2.2.0.
Ferriad

@ritchiecarroll
Copy link
Member

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 Initialize function?

@wwang72
Copy link
Author

wwang72 commented Mar 6, 2017

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()
{

        base.Initialize();

       
        OnStatusMessage("Initialized Event Trigger Completed");
    }

@ritchiecarroll
Copy link
Member

ritchiecarroll commented Mar 6, 2017

That's a big initialize function. One quick thing jumps out, what is the m_eventRecordFilePath set to?

Note that by default the openHistorian gets installed with the NT SERVICE\openHistorian local user account and this account has almost zero rights to the system - actually the only rights it has at all are those granted by the installer, e.g., read/write access to the installation folder.

If your folder path is anywhere else on the system, the NT SERVICE\openHistorian user will not have needed rights. To give the user rights to another folder you will need to right click on the folder and go to security to edit rights available to the user...

Thanks,
Ritchie

@wwang72
Copy link
Author

wwang72 commented Mar 6, 2017

Ritchie,
The m_eventRecordFilePath is set to the {$installation folder}/event_log.txt. One thing to mention is- we use the same log method in our other adapters, however, they can write log successfully.

@ritchiecarroll
Copy link
Member

ritchiecarroll commented Mar 6, 2017

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 Initialize function and step through code to see what the issue might be.

@wwang72
Copy link
Author

wwang72 commented Mar 6, 2017

Ritchie,
the issue has been resolved. I tested the adapter code and there was indeed a bug in the Initialize. When I fixed the bug, and the code was running well on the openHistorian V2.2.2.0 Debug mode. Then, I moved it to the openHistorian V2.2.2.0 installation folder and tried again. This time, the console suggested that 'the adapter .dll was used by another program'. Here is the error image:
image
Then, I tried to remove the action adapter on openHistorian Manager, restart the openHistorain service, reaname the adapter .dll file, and add the action adapter back to the openHistorian Manager, the issue was revolved.
Not sure if it was related to the naming of the adapters because I updated that .dll file for serveral times and did not change its name.
Thanks for the reply! You are awesome.
Ferriad

@ritchiecarroll
Copy link
Member

Great! Glad this is working.

@wwang72
Copy link
Author

wwang72 commented Mar 17, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants