Report is empty

[siaDaniel]

Hi Stephen,

When I export a completeness report, I find it is empty.

I read about a discussion on codeplex(please copy the url and paste it in the address bar) http://openpdc.codeplex.com/discussions/586354. I think it may be the reason.

But after the three steps, the report is still empty.

Firstly, the statistics measurement is non-zero.

Secondly, the adapter is working.

Thirdly, the Historian Trending Tool can export data. And the timestamp is correct.

When I export a report in openPDCManager, it is empty and couldn't be opened in PDF software.

Did I use it in a wrong way again?

Thanks in advance.

[ritchiecarroll]

Can you report which version of the openPDC you are using?

[siaDaniel]

@ritchiecarroll Thank you for your response.

I download the latest version openPDC v2.3-Synchrophasor.Installs.zip and re-install it.

The result is the same.

[ritchiecarroll]

I see that you are using the same data as input - is the openPDC running continually? These are "daily" reports - you will only get a report after a full's day of running.

[siaDaniel]

@ritchiecarroll You mean the openPDC Service should run for 24 hours and not be interrupted?

I see there are some system measurements like CPU Usage(STAT:37), IO Usage(STAT:45) and so on. If the service runs the hole day, I will get the system measurements' report. Am I right?

Thank you.

[siaDaniel]

Still empty after running one day.

[StephenCWills]

Hi siaDaniel,

I'm thinking the StatHistorianReportGenerator is probably throwing some kind of error when saving your report to a PDF file. The openPDC executes that app as a Big Black Box, so it doesn't really report any errors that occur when running it. Fortunately, it's not too difficult to run it yourself and see what happens. You can adjust the following command and execute it on the command line...

"C:\Program Files\openPDC\StatHistorianReportGenerator.exe" --reportType=" Completeness " --archiveLocation=" C:\Program Files\openPDC\Statistics\ " --reportLocation=" C:\Users\siaDaniel\Desktop\ " --title=" Test Report " --company=" TestCom "

... or you can just double-click the app and enter the parameters through the form that appears. Let us know what you find.

Thanks, Stephen

[siaDaniel]

Hi Stephen,

I run the StatHistorianReportGenerator.exe, but the error is as below.

System.IO.DirectoryNotFoundException: Unable to locate STAT archive. Please check the configuration file to set the archive location.

So I check the file StatHistorianReportGenerator.exe.config. The value of the ArchiveLocation is empty.

Then I fill it an add other settings as below.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="categorizedSettings" type="GSF.Configuration.CategorizedSettingsSection, GSF.Core"/>
  </configSections>
  <categorizedSettings>
    <systemSettings>
      <add name="ArchiveLocation" value="C:\Program Files\openPDC\Statistics\" description="Location of the archive to be opened for statistics." encrypted="false" />
      <add name="ReportType" value="Completeness" description="." encrypted="false" />
      <add name="ReportLocation" value="C:\Users\lenovo\Desktop\" description="." encrypted="false" />
      <add name="Title" value="Test Report" description="." encrypted="false" />
      <add name="Company" value="TestCom" description="." encrypted="false" />
    </systemSettings>
  </categorizedSettings>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
</configuration>

I run it again, the error is about System.ArgumentOutOfRangeException just as below.

System.ArgumentOutOfRangeException: 索引超出范围。必须为非负值并小于集合大小。 参数名: index 在 System.Collections.BitArray.Set(Int32 index, Boolean value) 在 Root.Reports.PdfFormatter.PrepareObjIdsForContainer(PdfIndirectObject_Page pdfPageData, Container container) 在 Root.Reports.PdfFormatter.PrepareObjIds() 在 Root.Reports.PdfFormatter.Create(Report report, Stream stream) 在 Root.Reports.Report.Save(String sFileName) 在 StatHistorianReportGenerator.Main.GenerateReportButton_Click(Object sender, EventArgs e) 在 System.Windows.Forms.Control.OnClick(EventArgs e) 在 System.Windows.Forms.Button.OnClick(EventArgs e) 在 System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) 在 System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) 在 System.Windows.Forms.Control.WndProc(Message& m) 在 System.Windows.Forms.ButtonBase.WndProc(Message& m) 在 System.Windows.Forms.Button.WndProc(Message& m) 在 System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

May I have a look at your config file.

[siaDaniel]

Thanks, Stephen : )

[StephenCWills]

The error message and stack trace you provided have been helpful. We've determined that there is an issue with the PDF writer writing unicode characters with character codes above 10,000. I don't know any more information than that, but we're still investigating the issue.

[siaDaniel]

I have received the report, thanks Stephen.

If there is anything I can do to help testing this issue, please let me know.

Thanks again.

[StephenCWills]

After a bit of investigating, what we found is that the Report.NET library is only capable of using the standard AFM fonts that are expected to be supported by all PDF readers. These fonts use a character encoding known as Windows-1252, which supports only a handful of characters that can easily fit into a small graphic.

I'm wondering if you have any devices named using characters outside the supported set (it doesn't seem possible, but I'd like to rule it out). Regardless, there is some string being generated in your report that is using characters outside the supported set (maybe a date/time string?). We've already discussed some strategies to fix this issue. It may be as simple as changing the culture settings used by the app. However, it could also be that the best we can do is to remove unsupported characters from strings before generating the report. I'm also toying with ideas to include some sort of hash code identifier to help differentiate devices that don't have any unique characters in this stripped version of their names, but that really depends on whether device names are the issue here.

Ideally, the Report.NET library could be extended to support TTF fonts so we could theoretically include the full set of Unicode characters in our reports, but that's outside our area of expertise so it would be much more difficult for us to accomplish.

[siaDaniel]

Thanks for your help. Some character settings inside the OS may cause this happen?

[ritchiecarroll]

Yes - I added a fix last night to force invariant culture to the report generator, this should help for dates. We think the long date was trying to include high-order Unicode characters for some non-US cultural settings.

Want to try the nightly build and see if this helps the issue?

http://www.gridprotectionalliance.org/NightlyBuilds/openPDC/Beta-VS2012/Synchrophasor.Installs.zip

[siaDaniel]

It works on my computer! May I ask how to fix this? In openPDC project or GSF project? Will it update in the next version? Thanks a lot.

[StephenCWills]

Ritchie's fix was applied in GSF. https://github.com/GridProtectionAlliance/gsf/commit/e4a58d3774a1f309a36cf6a88b6ce3e3a2f4a1d4

The only binary that changed as a result of this fix was the StatHistorianReportGenerator.exe assembly. The next release version (v2.4) will include this fix.

[siaDaniel]

Glad to know about that. Thanks.