Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

Displaying external data in RTMC Pro 3.1


Clayton Aug 3, 2010 06:53 PM

Hello,
I am trying to integrate weather data from a series of Andover PLCs (building automation controllers) into our network of CR10Xs. We have a lot of temp/rh and wind sensors in place for controlling ski chairlift operations and snow making and would like to be able to display this data using RTMC Pro. With the File Data Source option available in the new version of RTMC Pro (thank you CSI) it seems like this should be possible.

Currently, we can output data from the Andover SQL database as a CSV file, here is an example:
2010-08-03 09:45:00,3.1563129,182.28973,6.9499998,2.865427,168.00385,6.2000008

The fields here are Timestamp (YYYY-MM-DD HH:MM:SS), WindSpeed1, WindDir1, WindGust1, WindSpeed2, WindDir2, WindGust2

The RTMC Pro manual indicates that a CSV like this should be usable, but an FSL or DLD file is necessary. Looking at an FSL from one of our mixed array CR10Xs, it looks like this shouldn't be difficult. I added 101 to the beginning of the CSV to provide an array identifier (I'll write some code or possibly use Split to do this automatically), and then basically duplicated the existing FSL. Unfortunately, RTMC didn't know what to do with the timestamp, and only one line of data appeared despite setting the max records at 5 under the table properties. The table I built automatically added a timestamp with today's date at midnight, then treated the actual timestamp as another field with the value 2,010.00. Here's the FSL I'm trying to use:

Final Storage Label File for: WindCh1_Rpt_TEST.csv
Date: 7/30/2010
Time: 10:52:00

101 Output_Table 1.00 Min
1 101 L
2 Timestamp L
3 WindAvg1 L
4 WindDir1 L
5 WindGust1 L
6 WindAvg2 L
7 WindDir2 L
8 WindGust2 L


Estimated Total Final Storage Locations used per day 14400


Clearly the CR10Xs use a different time stamping format, where year, day of the year, and HHMM are all given individual fields. Is there a way to write the FSL so that the existing timestamp on the Andover data is recognized, or otherwise, can I use Split to convert the timestamp format? Any thoughts on why only one line of data is appearing?

Any advice would be greatly appreciated,
Clayton


ChipsNSalsa Aug 3, 2010 07:45 PM

Your file has a time stamp like a CSI table based data file rather than a mixed array data file. If you included a TOACI1 style header at the top of the file it would probably work. You may also have to put parentheses around the time stamp. Here's an example of a CSI TOACI1 file:

"TOACI1","HyrumCR510TD","24_Hour_Data"
"TMSTAMP","RECNBR","ProgSig","BattVolt_MIN"
"2002-02-03 00:00:00",40,2839,11.84
"2002-02-04 00:00:00",41,2839,11.4
"2002-02-05 00:00:00",42,2839,11.68
"2002-02-06 00:00:00",43,2839,13.73

RTMC knows that the TMSTAMP field is the time stamp. I don't think RTMC will care if the RECNBR field is missing but it may. The rest of it's just data corresponding to field names in the header.


Dana Aug 3, 2010 07:48 PM

The timestamp in an FSL file needs to be in the format:

2 Year_RTM L
3 Day_RTM L (Julian day)
4 Hour_Minute_RTM L
5 Seconds_RTM (optional)

I did a quick test and without the quotes on the date -- Split does not correctly process the date string. If you can put quotes on the date so that it looks like a table-based timestamp, you can use Split's date function to convert the timestamp to a Julian Day based timestamp. The Split help tells you how to make a table-based date look like a Julian-based date (in the index, type Date and choose "format string examples").

Dana W.


Clayton Aug 3, 2010 09:23 PM

Thank you both for your prompt replies. RTMC will accept files with a TOACI1 header. Turns out that the parentheses around the date are not necessary, but the record number is. I was able to get it to work with just a comma as a placeholder for the record number. The reason it would only read the first line of data was because it was the most recent. Apparently data cannot be read in descending order.

Thanks for including this feature, it's one I asked for several years ago and I'm very pleased to see it working out...with a bit of PERL scripting.

Thanks again,
Alex Clayton
Mammoth Mountain, CA


ChipsNSalsa Aug 3, 2010 11:07 PM

That's true. Our data files have the newest data at the bottom and not at the top.

Log in or register to post/reply in the forum.