I am developing a CR1000 program to validate CR1000's installed in the field. One thing I'd like to do is retreive the Table Definitions from a Remote logger using my validation CR1000. I looked at GetDataRecord but I need to know the Table Definitions before hand. Is the TDF a hidden file on the CPU that I can access using a GetFile command? Any other way to do this?
I plan on using this one standard command to collect all table definitions from many different loggers (running different programs). I would use this to show customers what data is being collected and into what table/interval.
Requesting table definitions is a special type of Pakbus packet not implemented in the datalogger operating system. They just know how to respond.
I believe to do what you want, it will require a PC and some scripting. You could either use one of the SDKs like BMP5 Direct or use Cora Script in Loggernet.
The PC could also serve as a display for your system.
Thanks Jacob for the reply but I need a solution that does not require a PC. If I have a PC on site then I will just collect data with loggernet. I'm trying to minimize the number of devices a field tech needs to do this work.
Assuming you are just using it in the field for a temporary test, there are a lot of inexpensive tablets that run full Windows 10. It is not much bulk to add to the system. You can make a simple display interface that operates easily with the touchscreen.
If I understand correctly, you want the diagnostic CR1000 to query the Table Definitions (*.tdf file) from the CR1000 under test, so that it (the diagnostic CR1000) can read/grok those definitions and then take action, such as retrieving final storage records from the device under test. (possibly with GetDataRecords).
As Jacob mentioned, we provide tools that work on PC-based devices for doing activities like these, but your development set on the CR1000 is more limited (essentially just CRBasic).
You will obtain (in my opinion) just as much information about the tables by retrieving the CRBasic program from the device under test and then parsing the DataTable declarations in that program (as well as a few other items like the main scan rate). The TDF file doesn't contain much more than what can be assessed by examining the CRBasic program itself. Are you trying to dig up some fancy information out of the TDF, or is it just the basics (table name, table interval, names of variables being sampled, averaged, max-ed, min-ed, stdev-ed) ?
The CRBasic program is easier to obtain and parse (using the CR1000 as the toolset) than a binary TDF file. If I had to write a CRBasic program to parse either a text program, or a binary file like the TDF, I would probably opt for the text program. (which is the CRBasic program of the device under test in this case).
It is possible in theory to come up with some stream of bytes that could be sent from one logger to the other that requests the table definitions, and then also capture the response bytes that are sent back and put them into a file. An alternative would be to implement a policy that whoever places the program into the dataloggers under test, also would generate the TDF file with the CRBasic editor and place it onto the USR, CRD, or USB device of the logger. Then you would be able to retrieve the TDF file, assuming no one has put a different program into the logger since the time the TDF was posted.
However, after you do all of that you would still have to understand the format of the TDF and parse through it (using CRBasic). With the TDF format unpublished, I think that is an uphill battle.
So that is why I would probably pursue parsing the CRBasic program itself.
Another option, though it would involve a lot of work, would be to purchase the JavaSDK then adapt the Get Table Definitions code given in Java over into some CRBasic routines. This would allow the right "binary" data stream to be sent from the diagnostic CR1000 over to the device under test and then receive the response and parse it, etc.
Once again - a much better way would be for the diagnostic device to not have to be a datalogger, because then you tie your hands down to just using CRBasic and nothing else.