openpdc Discussions Rss Feed

New Post: Alarm when signal is NaN

patpentz — Wed, 22 May 2013 19:51:22 GMT

Not needed, nor desired. Thanks.

New Post: Historian Web Service no longer returning good data

patpentz — Wed, 22 May 2013 19:06:55 GMT

Very sorry, yet another bug in my code...

New Post: Inner Joins in Filter Syntax for InputMeasurementKeys and OutputMeasurements

patpentz — Wed, 22 May 2013 18:40:16 GMT

Thanks for the quick response. Perhaps you could add 'add joins to filter expressions' to some wish-list. It would simplify some ConnectionStrings, and avoid online edits of the same.

New Post: Inner Joins in Filter Syntax for InputMeasurementKeys and OutputMeasurements

patpentz — Wed, 22 May 2013 18:07:19 GMT

Perhaps more readable...

InputMeasurementKeys={FILTER ActiveMeasurement am
                          INNER JOIN ActiveMeasurement am2
                              ON am2.SignalReference = am.SignalReference + '#VPASLOPEAVG'
                          WHERE am.SignalType = 'VPHA'
                            AND am2.SignalType = 'CALC'
                          ORDER BY am.SignalID};
OutputMeasurements={FILTER ActiveMeasurement am
                       INNER JOIN ActiveMeasurement am2
                           ON am.SignalReference = am2.SignalReference + '#VPASLOPEAVG'
                       WHERE am.SignalType = 'CALC'
                         AND am2.SignalType = 'VPHA'
                       ORDER BY am.SignalID};

New Post: Inner Joins in Filter Syntax for InputMeasurementKeys and OutputMeasurements

ritchiecarroll — Wed, 22 May 2013 18:06:42 GMT

You can't do joins in filter expressions - however, signal reference is already available in the active measurements.

New Post: Inner Joins in Filter Syntax for InputMeasurementKeys and OutputMeasurements

patpentz — Wed, 22 May 2013 17:53:19 GMT

I have several custom adapters that take long series of InputMeasurementKeys (over 100 keys in some cases), with related series of OutputMeasurements. The two sets of measurements have a strong relationship via the SignalReference. My Question: instead of an extremely long text in the ConnectionString, which is difficult to maintain as new signals are added, could I use an Inner Join in the Filter syntax, as in:

InputMeasurementKeys={FILTER ActiveMeasurements am

                                                INNER JOIN [openPDC15R1].[dbo].[ActiveMeasurement] am2
                                                    ON am2.SignalReference = REPLACE(am.SignalReference, '#MW', '#MWAVG')
                                            WHERE am.SignalType = 'CALC'
                                                AND am2.SignalType = 'CALC'
                                                AND am.SignalReference LIKE '%#MW'
                                           AND am2.SignalReference LIKE '%#MWAVG'
                                            ORDER BY am.SignalID};

OutputMeasurements={FILTER ActiveMeasurements am

                                                INNER JOIN [openPDC15R1].[dbo].[ActiveMeasurement] am2
                                                    ON am2.SignalReference = REPLACE(am.SignalReference, '#MWAVG', '#MW')
                                            WHERE am.SignalType = 'CALC'
                                                AND am2.SignalType = 'CALC'
                                                AND am.SignalReference LIKE '%#MWAVG'
                                           AND am2.SignalReference LIKE '%#MW'
                                            ORDER BY am.SignalID};

what I hope to get are two lists that include only measurements where both MW and MWAVG exist, and sorted the same way. That is, so that the correct input measurement matches the correct output measurement.

New Post: Inner Joins in Filter Syntax for InputMeasurementKeys and OutputMeasurements

patpentz — Wed, 22 May 2013 17:47:47 GMT

New Post: Probleme with csv historian

RTEJMJ — Tue, 21 May 2013 16:25:04 GMT

Hello , i create an historian .csv. But i have this error in the file statuslog and i have no archive. :

[21/05/2013 16:38:33] [CSVHISTO] Attempting connection...
[21/05/2013 16:38:33] [CSVHISTO] Connection attempt failed: The process cannot access the file 'C:\Windows\system32\measurements.csv' because it is being used by another process.
[21/05/2013 16:38:33] [CSVHISTO] Exception occured during disconnect: Object reference not set to an instance of an object.

CSVHISTO is the nema of the historian.
I dont know what can i do.
Thank you.
JeanMarc JANSEN (RTE France)

New Post: Historian Web Service no longer returning good data

patpentz — Mon, 20 May 2013 20:19:41 GMT

This is a test openPDC, so I stopped it, and deleted all Archive and Statistics files. Upon restart these files were recreated. The historian statistics metadata look correct, as far as I can tell from a brief inspection. The metadata show the system and concentrator statistics from id=1 to 35, and then a gap until id=957 for the first non-concentrator statistics.

When I use the Historian View, the statistics look good. However, when I use the web service, the data remains as before (Unknown, very old, 0.0). This is true when I use the web service manually from a browser.

I normally use the web service via a program, and didn't notice when the data went bad. It certainly worked fine at some unknown time. Non statistics data still arrives in good form.

New Post: Flat Line test with a public smtp server

sehnpa — Mon, 20 May 2013 20:15:20 GMT

I'm configuring a Flatline Test adapter, but I don't have a smtp server in my computer. Is it possible to configure a flatline adapter with a public smtp server, like gmail?

Thank you
Paulo André

New Post: Historian Web Service no longer returning good data

ritchiecarroll — Mon, 20 May 2013 19:41:34 GMT

Here's a few things you can try:

(1) Check disk space on where historian data files are located (by default, ...\Program Files\openPDC\Archive) - a full disk can cause this error
(2) Stop the openPDC service then delete *_dbase.dat, *_startup.dat and scratch.dat (i.e., anything but a ".D" file) in the archive folder restart PDC and see if the historian service returns to normal operation? This deletes the non-data related files that may become corrupted due to an improper shutdown or other activity - these will be recreated once the PDC restarts - then you can try the tool again.
(3) If these steps do not work, one of your recent ".D" files may be corrupted (e.g., ppa_archive.d) and may need to be deleted - back up all files before deletion of ANY .D files so you do not lose an historical data.
(4) Also be sure to validate the timestamp of the incoming measurement data and make sure it is good quality and a reasonable time.

New Post: Historian Web Service no longer returning good data

patpentz — Mon, 20 May 2013 19:27:38 GMT

I am no longer getting good data from the Historian Web Service (Statistics) at:

http://ISO-PDCD-1:6152/historian/timeseriesdata/read/current/1-1163/xml

every value is Quality: Unknown ReceivedTime: 1/1/1995 12:00:00 AM value: 0.0

I am running openPDC 1.5.226.

New Post: TRANSFER A CALCULATED MEASUTEMT BY OUTPUTSTREAM

kevinjones — Sat, 18 May 2013 16:41:34 GMT

I have never been able to do it directly (although I think you can). What I do is map all of my calculated values to a virtual device and the. Add the device to the output stream. Works like a charm.

Kevin

New Post: TRANSFER A CALCULATED MEASUTEMT BY OUTPUTSTREAM

itan_leon — Sat, 18 May 2013 16:36:37 GMT

Hi!

I created a new measurement by an action adapter and I would like to transfer this measurement through an OutputStream to other remote computer. Is it possible to make this implementation? if it's possible, how Can I do it?

regards,

Itan

New Post: Alarm when signal is NaN

patpentz — Thu, 16 May 2013 16:29:38 GMT

I need to test for a few signals that might be 'NaN'. The values must be both non-zero and non-NaN; would a test for zero work in this case, so that an alarm is raised for either zero value or NaN value.

Otherwise I would have to create a DynamicCalculator that test for these values, outputing a boolean signal which could be alarmed. I hope to avoid this second step.

New Post: PowerCalculation Stopped Working

patpentz — Wed, 15 May 2013 19:17:18 GMT

This and many other adapter problems occurred when the Time Domain service stopped working. OpenPDC is very dependent on good time!!!

New Post: DynamicCalculation Parse Errors - How to prevent?

patpentz — Tue, 14 May 2013 17:20:12 GMT

I found my reference as to how to make double.IsNan to DynamicCalculator. Add as import:

AssemblyName={mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089}, TypeName=System.Math;AssemblyName={mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089}, TypeName=System.Double

I would recommend that this assembly be make always available, since NaN's will become more prevalent.

New Post: DynamicCalculation Parse Errors - How to prevent?

patpentz — Tue, 14 May 2013 17:10:35 GMT

a new wrinkle in DynamicCalculator - many of the functions available do not accept NaN, and generate errors. I understand that double.IsNan is not automatically available in DynamicCalculator, but some 'inport' can be used to provide this. Is this correct?

New Post: DynamicCalculator adapter and LagTime/LeadTime

patpentz — Mon, 13 May 2013 16:37:54 GMT

I have many many instances of DynamicCalculators, some of which work on normal incoming signals, others that operate on calculated data from PowerCalculator and other DynamicCalculators. It is very difficult to get this to work; I've had to set lagtime/leadtime to 37/30 seconds in some cases, and even so some adapters are not returning any results - I imaging they are discarding all data.

Is there a way to tell an adapter to simply accept the latest measurements for the set of inputs, and not to worry about how the timestamps match? Or is there a better way of thinking about this problem?

New Post: openPDC Manager is crashing when trying to view action adapters

patpentz — Mon, 13 May 2013 14:29:10 GMT

Please ignore - somehow copies of DLLs were created, causing havoc!