I would like to record constant values (defined using Const or in a ConstTable structure) in a DataTable (or equivalent) as a program starts up. Can this be done in a DataTable, i.e., using the sample() instruction?
I would like to update such a table before the scan begins, e.g.:
BeginProg
CallTable LogConstants
Scan (SCAN_SECONDS,Sec,0,0)
...
NextScan
EndProg
Kirving,
Does the following work for your application? I would be interested in learning more about your application.
ConstTable
Const A = 1
Const B = 2
EndConstTable
DataTable (Constants,True,100)
Sample (1,A,FP2)
Sample (1,B,FP2)
EndTable
BeginProg
CallTable (Constants)
Scan (1,Sec,0,0)
NextScan
EndProg
Yes, that what I'd like to do. I wasn't able to figure out if a datatable sample() instruction could (or couldn't) handle a constant.
My goal is to have a record of (all or some) constants defined in a program. There are two reasons for this need, the most obvious being that constants in the ConstTable block might not otherwise be logged or recorded anywhere if they're changed.
The other reason is that, even if we know what the constants are in a program, the resulting data table may hint (incorrectly!) that a given program applies to the entire data set, and so it may not be possible to tell what constants were in play if the program is changed (and the change doesn't force tables to be reallocated).
My hope is that your solution should leave a time-stamped record of the values of the constants alongside other data tables.
Will this work for constants of type string as well as numeric?
Thanks!
You shouldn't have any problems with numeric vs. (reasonably sized) strings (don't try and store a thesis in there).
I did a similar thing on the CR200 so that the field techs could retrieve the Constants / Settings used, since you can not retrieve a CR200 program from the logger. So, I understand where you're coming from.
See your other post regarding multiple ConstTables
I've been testing storing constants in a datatable as described above, and it works very well for the most part. A couple of issues have come up, and could perhaps be clarified in the documentation. The test bed is a CR1000 at revision 17.
One issue is that the sample() instruction doesn't record the name of the constant, but instead the fields are named "Anonymous1" and so on in the final table. This seems reasonable, as the constants are probably replaced in the running program with their values, so no name exists when the data table is called. The fieldNames() instruction can be used to work around this issue.
The other issue is that the 'fp2' data type gives incorrect (and varying) results when used in this way. The workaround seems to be to instead use the 'ieee4' or 'uint2' types as appropriate. The 'string' data type works fine.
I haven't seen problems with the 'fp2' data type in other output tables, so this is a little worrying. Is it best to avoid that data type in some cases?
I can think of a couple of "wishlist" ideas that might help with the first issue. One would be to add a SampleConstant() instruction to retain the name, and maybe even to omit the data type (since it's not specified in the constant declaration).
Another would be if sample() and related output instructions allowed an optional argument for the fieldName, so the extra instruction wouldn't be needed.
* Last updated by: kirving on 8/18/2009 @ 6:37 PM *
Attempts at storing constants in a data table are not working very well. I thought things were maybe just confusing due to floating point representations, but the results are just wrong in some cases.
I have some constants declared normally, others in a ConstTable:
const STATION_ID = 5160
ConstTable
...
const ATRH_MODEL = "HMP45C"
const ATRH_SN = "?"
const AT_MULT = 0.1
const AT_OFS = -40
const RH_MULT = 0.1
const RH_OFS = 0
...
and these datatable output instructions:
DataTable(Constants,1,20)
sample(1, STATION_ID, uint2)
fieldNames("STATION_ID")
sample(1, ATRH_MODEL, string)
fieldNames("ATRH_MODEL")
sample(1, ATRH_SN, string)
fieldNames("ATRH_SN")
sample(1, AT_MULT, ieee4)
fieldNames("AT_MULT")
sample(1, AT_OFS, ieee4)
fieldNames("AT_OFS")
sample(1, RH_MULT, ieee4)
fieldNames("RH_MULT")
sample(1, RH_OFS, ieee4)
fieldNames("RH_OFS")
...
the resulting data table output looks like:
TIMESTAMP 2009-08-18 17:22:22.13
RECORD 0
STATION_ID 0
ATRH_MODEL HMP45C
ATRH_SN ?
AT_MULT 0.1
AT_OFS 8.265195e-040
RH_MULT 0.1
RH_OFS -2.81945e-011
Hmm, somehow -40 became 8.265195e-040, which is plainly wrong.
Here's the output when those ieee4 entries were fp2:
TIMESTAMP 2009-08-17 16:48:16.86 2009-08-17 17:19:39.84
RECORD 0 1
STATION_ID 0 0
ATRH_MODEL HMP45C HMP45C
ATRH_SN ? ?
AT_MULT 0.1 4
AT_OFS 0 0
RH_MULT 0 328
RH_OFS 0 0
Here there were two records output, either because I cycled power on the logger or because I changed a different ConstTable constant (not one of these) using the CR1000KD keypad.
Am I doing something wrong? Cycling power in the first case, with the values sampled as ieee4 data types, yields completely different (and erroneous) values for the zero-valued constants.
The ConstTable itself seems to work well, other than only 7 characters of the names are visible in the list (the full names are however displayed in the edit screen). All the constant values are displayed clearly and correctly, can be edited, and the program restarts and compiles as advertised. Further, the program signature changes, and downloading the program shows the new values for any constants that were changed. All that is good, but I'd like to record the values with a timestamp -- otherwise it might be difficult to know what values were in place when data are generated.
Perplexed...
Ken
I recently came across this limitation with the storage of constants - we will forward the issue to the development team.
Meanwhile it is simpler to forget trying to store the constants and either declare the values as variables which you directly initialise at the start of the program, perhaps after the BEGIN and before the main scan OR create variables you set equal to the constants again at the start of program. This is a little wasteful of memory but avoid the need for the fieldnames declarations.
I've changed the scheme to use a string array for the purpose, arguably a cleaner approach anyway. The & operator does the conversion from constant to string value, so no worries about types.
Thanks for the help. -- Ken
For future reference I am told and just checked using OS17 that the issues with the use of sampling constants has been fixed in recent operating systems.
The issue with the Anonymous name of the variable in the datatable still persists requiring use of the fieldname command.
* Last updated by: aps on 8/20/2009 @ 3:51 AM *
Our tests were run using OS17, with unreliable results from types other than string. Do you not see problems with OS17?