I am trying to read logged data via c++ from a datalogger session configured in PLCnext Engineer.
I have set up IDataLoggerService2, gotten the session name and the variable names.
As mentioned in the docs (PLCnext API Documentation: Arp::Services::DataLogger::Services::IDataLoggerService2 Class Reference) while calling ReadVariablesData(…) the values-enumerator returns an RscVariant-array of objects, which should contain the logged values but I cannot figure out what to do with these „object“ types.
The entry of RscType::Object is also not helpful to me (PLCnext API Documentation: Arp::System::Rsc::Services Namespace Reference).
Thank you in advance for any suggestions.
That method uses Delegates to read the variable names and values - those aren’t intuitive to use, and the documentation could probably be better.
In this case the closest similar example I can find is in the Github example for the DataAccess service, which also allows the reading of multiple data items, similar to the DataLogger service. Specifically, the Read method uses delegates to read the variable names and values.
Here is the call to the DataAccess „Read“ method in the Github example:
https://github.com/PLCnext/CppExamples/blob/58439a536e53fb79e55638ded888bbd14302c497/Examples/DataAccess/src/DataAccessComponent.cpp#L364You can see that the Read method has two parameters - ReadPortNames and ReadResult - both of them delegates. The ReadPortNames delegate specifies the Port Names that should be read, while the ReadResult delegate extracts the port values that are read. I hope that you can use this example to construct your own delegates for the DataLogger ReadVariablesData method.
If this does not help, or if you have further questions, please let us know.
Ah, I knew I had seen a better example somewhere. 
There is another Github example, separate to the CppExamples, specifically showing how to use the DataLogger service.
Part 5 contains a component that uses the ReadVariablesData method:
I hope this helps.
The method call and delegates are not the problem, rather the returned data structure.
I have followed the example given in the second hidden code block of PLCnext_RT_Datalogger/getting-started/Part-05 at public · PLCnext/PLCnext_RT_Datalogger · GitHub.
But it seems the API has changed. In the example the IRscReadEnumerator produces RscVariant-arrays, which in turn contain RscType::DateTime, RscType::Void, …, which are then processed in the switch statement.
In my case the IRscReadEnumerator produces RscVariant-arrays, which contain only RscType::Object of which I don’t know how to get the variable data from.
I’ve just built the project in Step 5 of the example (after a few minor tweaks), added it to the PLCnext Engineer project, and put the sample configuration file data-logger.dl.config in the directory /opt/plcnext/projects/Services/DataLogger.
After sending the PLCnext Engineer project to a PLC running firmware version 2023.0 (and then restarting the Runtime), these lines ended up in the Output.log file:
07.11.23 15:28:52.300 Arp.System.Acf.Internal.ApplicationBase INFO - Application 'MainProcess' was setup successfully.
07.11.23 15:28:53.311 root INFO - DateTime: 5250035695759518704
07.11.23 15:28:53.313 root INFO - EvetCounter: 0
07.11.23 15:28:53.319 root INFO - EvetCounter: 0
07.11.23 15:28:53.319 root INFO - EvetCounter: 0
07.11.23 15:28:53.321 root INFO - EvetCounter: 0
07.11.23 15:28:53.328 root INFO - EvetCounter: 0
07.11.23 15:28:53.331 root INFO - EvetCounter: 0
07.11.23 15:28:53.331 root INFO - EvetCounter: 0
07.11.23 15:28:53.333 root INFO - EvetCounter: 0
Unless I’m mistaken, these messages can only have been generated if the ReadVariablesData enumerator returned an RscType::Array, and the array contained an RscType::DateTime followed by eight RscType::Uint64’s, which is what you’d expected.
Are you able to reproduce this behaviour with the example project? If not, I can send you my code.
I have now taken the exact files from Step 5 of the example and if I compile them for 2023.6 (23.6.0.43 sdk, 23.6.0.43 axc firmware and 2023.6 engineer) it works as intended, but if I compile the exact same project for 2022.6 (22.6.0.43 sdk, 22.6.0.43 axc firmware and 2022.6 engineer) it again just receives RscType::Object entries.
I think our project will mirgate to >=2023.6 in the (near) future anyways but this behaviour still seems weird to me, especially as the example seems to have worked in 2020.6…
It seems my build system was flawed. I switched from using cmake directly (similar to How to use Visual Studio Code to write C++ for PLCnext - PLCnext Community (plcnext-community.net)) to having a Makefile that executes the plcncli tool. Now everything works in all versions that I tested. Still strange how this could produce such subtle errors, but fine by me…