Hi everybody!
I am currently writing a Python interface for communication with CR 1000 (and possibly other) dataloggers. So far, I have implemented a number of packets and responses from the BMP5 Transparent Commands manual which are working fine.
Here is one question the manual did not answer. It is fairly easy to read tables if you know their name and somehow know (or guess) the matching table number. But what is the correct way to get table numbers and names from a CR1000 automatically?
I tried the example in the BMP5 Transparent Commands manual which uses a file upload request to "CPU:Def.tdf" to get the table definitions. This command returns an error code of 0xE (file not accessible). The manual text asks you to request a file named ".TDF". However, this request returns nothing.
I'd appreciate any hints on how to solve this.
Kind regards
Dgf
* Last updated by: dgf on 6/22/2009 @ 11:39 AM *
I'm afraid that the manual is somewhat out of date as recent versions (starting with 15 for the CR1000) introduced the feature of allowing the client to request the definitions for a particular table. If you want the complete set of table definitions, you need to request the ".TDF" file (note that there is no device designation or file name preceding the period.
Thanks for the explanation. I can now retrieve the table definitions by requesting the ".TDF" file.
The reason why it did not work before is a little strange: if I send a file upload command for ".TDF" with Swath > 0x5B4 (1460), there is no response from the logger. Smaller values work fine. On regular files, even 0xFFFF works fine for Swath.
> recent versions (starting with 15 for the CR1000) introduced the
> feature of allowing the client to request the definitions for a
> particular table.
That is cerrtainly a nice feature but it does not really help with the table number. You still need the full ".TDF" table definition to get this. It is unfortunate that all the commands rely on table numbers but these numbers are never provided explicitly.
Based on some information I have for the GetDataRecord instruction, data tables are numbered in sequential order, as they appear in the program.
*That's based on GetDataRecord.* I have not tested this to see if it holds true in your scenario, nor how Public & Status tables affect this.
Just throwing that out there as something to think about. Of course, even if this does hold true it requires that you know the table structure in the datalogger, one way or another.
Regards,
Dana
Dear Dana,
thank you for your reply. It seems that the only general way to get table numbers is to download the full table definition list by requesting the ".TDF" file. By "general" I mean that you have no other way of knowing the table number, e.g. by guessing it from the source code.
The whole issue is a hen & egg problem:
- you need a table number and table signature to request data
- if you only know the table number, you cannot retrieve the
table definition -> no table signature -> no data request!
- if you only know the table name, you can retrieve the table
definition (-> table signature). However, you don't get the table
number this way -> no data request!
So, whatever you do, there is no alternative to retrieving the full table definition list. Therefore, the otherwise useful feature to retrieve a single table definition by name ("TableXX.TDF") becomes useless.
However, I have a suggestion how to solve this: the status table has a list of table names in the DataTableName field. If it would contain the names of all tables - including "Status" and "Public" - in the correct order then one could retrieve table name and corresponding table number from there. With this information, it is easy to get the table definition.
Kind regards
Dietrich
The Getdatarecord table numbering is as Dana says from top to bottom in the program. The status and public tables do not come into it.
However, that numbering is I believe different than that used at the comms level where the status and public tables have to be considered and hidden tables too.
The issue of getting table full table definition from the logger has been a bit of a problem over the years. In our next release of Loggernet we have improved this somewhat by getting the CRBasic editor to generate the TDF file on the PC which the Loggernet server reads to get most of the info its needs. The server then only does a quick validation that the PC based TDF file matches what is in the logger.
I am afraid I can't tell you if and when some or all of that functionality will be added to the BMP5 development kit. However, once the CR basic editor is released you will be able to generate and read those files in your own code, although as they are binary files, interpretation is not so easy, but should not be much different from interpreting a retrieved TDF file.
There is a mechanism available starting with CR1000 OS version 15 whereby a client can request a table definition summary file from the datalogger (.TDFS). If this file is requested from an older operating system, the datalogger will respond with the standard .TDF for the datalogger. The following is an EBNF syntax for the .TDFS format:
.tdfs := fmt-version os-version os-sig serial-no
power-up-prog compile-state prog-name
prog-sig compile-time compile-result model
{ table-summary }.
fmt-version := byte. ; always 0x10 for .TDFS
os-version := asciiz.
os-sig := uint2.
serial-no := asciiz.
power-up-prog := asciiz.
compile-state := byte.
prog-name := asciiz.
prog-sig := uint2.
compile-time := nsec.
compile-result := asciiz.
model := asciiz.
table-summary := table-name [ table-size table-sig ].
table-name := asciiz. ; empty name terminates the list
table-size := uint4.
table-sig := uint2.
tables-term := byte. ; zero to terminate the list
This is not documented in the development kit that you are using because that document has not been updated since before version 15 of the operating system was released.