Hi,

We have a DataLogger that contains entries of several DataPoints. We'd like to read all entries of one of these DataPoints. Therefore we use an xSelect statement with a 'predicate'. The name of the DataPoint we want to read is: 'SMART/Channel 1/iLON100- 1/Type Translator- 1/F_IN1'

In order to exclude all other DataPoints (for ex. 'F_IN2', 'F_IN3' and so on...), we use a predicate '[contains(UCPTname, "F_IN1")]'. We don't get any datapoints at all.

If we provide the whole name: [contains(UCPTname, "SMART/Channel 1/iLON100- 1/Type Translator- 1/F_IN1")], it doesn't work either.

The only means to read any datapoints, is to use a predicate that contains only 'network/channel/device'. As soon as the predicate contains the functionalblock name, or parts of it, it doesn't work.

Is that normal, or are we doing something wrong?

Best regards,

Daniel

I believe the xSelect in the Read() is filtering on the Data Logger object (<Item xsi:type="UFPTdataLogger_Meta_Data">), not the actual entries in the log.  I think you are limited to the position and UCPTlastUpdate predicates.  

-Jonathan

I've been trying to use the List() function with xSelect in an FPM application, and I haven't quite figured it out yet.  The SmartServer Programmer's Reference (document# 078-0347-01A) has some good examples on page 24.  You might want to try the following:

//Item[@xsi:type="Dp_Cfg"][starts-with(UCPTname, "SMART/Channel 1/iLON100- 1/Type Translator- 1/F_IN1")]

 Hope this helps.

Jonathan,

If I compare my predicates with the UCPTname in the Meta_Data, that seems to confirm your assumption. (Wondering what's the reason for filtering the Meta_Data)

That means that we have allways to read ALL the entries of ALL DP in order to get ALL entries of ONE certain DP. Tens of data logger readings instead of one... and then filtering the data manually... Hope that will be improved in future...

Thanks and best regards,

Daniel

mrusso,

as far as I understand, xsi:type for DataLogger entries is 'UFPTdataLogger_Data', not 'Dp_Data' which is for the DataServer. I actually did try the starts-with predicate, but that doesn't work either. I am affraid Jonathan was right (see post above), we can't filter DataLogger data.

Thanks and best regards,

Daniel

Hi

The 'UCPTname' belongs to the data logger itself. You can use UCPTpointName to select some DPs. E.g. to select one DP from all loggers:

 //Item[@xsi:type="UFPTdataLogger_Data"][UCPTpointName="Net/LON/iLON App/Digital Output 1/nviClaValue_2"]

Hello dev26,

I'm just wondering whether that really works with your SmartServer. On my SmartServer, the 'UFPTdataLogger_Data' - class doesn't have a 'UCPTpointName' - member, but a 'UCPTname' - member in which the point name (not the data loggers name) is stored. Trying to filter for 'UCPTpointName' throws an exception 'Server returned an invalid SOAP Fault.'.

Regards,

Daniel

Yes, it works. But you have to use the equal compare for it, not 'contains' or 'starts-with'. Just try exactly my example.

P.S.: of course, you have to use a real DP name from your logger, otherwise it will return 'Data point not found' fault.

dev26

IT WORKS! (Indeed, I didn't realize you used the equal comparison.)

Thank you for your help.

Could you tell me where you found that in the Programmer's Reference, or any other document? As I'm also struggling with other things (for example: messageProperties_system, UCPTenablePath in AlarmNotifier config) which I can't find in the Programmer's Reference, I'm wondering whether there is more information provided somewhere else.

Best regards,

Daniel 

There is a lot of XSelect examples in the file iLON100.xsd itself. I don't know if they are always up-to-date, but at least it's a good start point.

About messageProperties_system - it's defined in iLON100_System.wsdl file which looks like some internal stuff. I think it purposely not documented and should be not used.

UCPTenablePath: all properties of type E_Path are XPath to select some special text from other configuration parts. I think I saw an example of it somewhere in the programmers guide, maybe for scheduler. In this case it should be <UCPTenablePath>../DataPoint[UCPTnickName="MyEnableDP"]</UCPTenablePath>; the DP itself must be of type UFPTalarmNotifier_Input_DpRef, with <UCPTnickName>MyEnableDP</UCPTnickName>.

Daniel,

It's either the migration or the sync that caused the problem.  I will try to reproduce the error with a test migration.  In regards to the System Service methods, the following code demonstrates how to read and write to the SmartServer's system info:

   //------------Checking System Time-------------------------------------------

  //This code checks the SmartServer's time and system info and then sets a new time

  iLON_SmartServer_System.messageProperties_system time = new iLON_SmartServer_System.messageProperties_system();

  string timeResult = SmartServer.SystemService_Read_Info(ref time, timeData);

   iLON_SmartServer_System.messageProperties_system systemInfo = new iLON_SmartServer_System.messageProperties_system();

   string staticResult = SmartServer.SystemService_Read_Info(ref systemInfo, staticData);

   Console.Out.WriteLine("\r\n Changing the SmartServer's System Time\r\n -------------------------------\r\n -------------------------------\r\n");

   string revisedTimeData = "<iLONSystemService><TIME>SI_TIME<UCPTsystemTime>2008-07- 05T10:20:00</UCPTsystemTime></TIME></iLONSystemService>";

   Console.Out.WriteLine(revisedTimeResult);

   Thread.Sleep(10000);

   string newTimeData = "<iLONSystemService><UCPTsystemInfoType>SI_TIME</UCPTsystemInfoType></iLONSystemService>";

   Console.Out.WriteLine(newTimeResult);

Hello Jonathan,

Thanks for that good advice. It works now!

Regards,

Daniel

(Migration: At least in our case there was not only the time settings that went wrong during migration... Wondering if Echelon is currently working on some known problems.)