Hello,
I'm using a CR1000 with a CFM100 module attached, holding a 1GB "industrial grade" CF card. I'm aware that when I upload new programs there's a danger of leaving my CFM in a state where it's not recording data, because it wasn't reformatted correctly and may still have tables from an older CRBasic program (or whatever reason). So I want to report some diagnostics (remotely, by TX312 communications) about the state of the CFM.
I've got a program that pulls the Status.CardStatus string and compares it to known strings (namely "Card OK" but also some of the error messages I've seen). I've also learned that I can pull values from the Status.DataFillDays array which should be several hundred days if the card is working properly but will be zero if something's wrong. This is exactly what I wanted.
But once I started looking at DataFillDays, I thought it would count down over time as records were actually added to the table. But it seems to be a fixed number. I tried switching my data tables between fill-and-stop and ring modes, and this doesn't seem to make any difference. It seems like if it reports 800 days at logger compile time, it will continue to report 800 days next week, next month, or next year.
I've got this idea in my head where I could watch the CFM diagnostics remotely and see the numbers counting down every day, and I'd know that the card wasn't yet full and I'd know exactly how many days I had before the card filled up, and I'd also have some indirect confirmation that the card was /filling/ as time went by. That would be cool.
Are there other Status table fields that I could use to calculate my own "days until fill" value? Perhaps some count of records written into the table so far, and the amount of space needed per record, and then the total size of the table on the card? Is it possible to teach my logger program to do something more clever like this?
What I've got so far is "good enough." As long as the DataFillDays isn't zero, and the CardStatus appears to hold "Card OK", I'm pretty confident that the CFM is working correctly. But I'd like to know if I could get an accurate days-until-fill kind of number that does what I describe.
Mike J+
I'm not really where I can check this, but look at using the data table access instructions TableSize and TableRecord. I think you could use TableSize to determine the approx. number of records that can be stored (this will be a fixed value) and then TableRecord to check periodically (say, once a day) on how many more records you have until "full". There's also TableFull, but that wouldn't give you any advanced warning :).
Hmm... now that I think about this, this may not work since these functions will probably only pull back TableSize from the logger, and not the card itself (which could potentially be bigger than the logger).
Sorry, I think I have resorted to rambling. I don't have a logger at hand and I'm going to need much more coffee before I can recreate the the status table and card info in my head from memory.
Dana W.
Here's what I'm thinking: LoggerNet shows me something like the information I want. Just open the "Connect" window and click on "Station Status," and then the "Table Fill Times" tab. There are columns for Table Fill Time and Time of Fill. The former has the same numbers I see in the DataFillDays array. But how does LoggerNet calculate the latter?
In my case, all my DataTables are defined with a Size of -1, so they all have (approximately) the same number of days until filled (say, 800) and the same time of fill (say, July 3, 2013). If I reload this window next week, or next month, it will still say 800 days until fill (which is not exactly true, because it's been filling for some time already) but it will also (still) say that the Time of Fill is July 3, 2013 (which is correct). So it's counting 800 days from... some date. What?
I haven't experimented with this too much yet, to see if LoggerNet's reported Time of Fill agrees with my intuition. If I recompile the same program, I assume it won't overwrite my CRD tables, so there will be less than 800 days until that card is filled. But will it realize that, or will it just assume that it should count 800 days from Status.StartTime?
I'm also noticing that I could reference CRD files with FileOpen() and presumably FileTime(), which says it returns the "creation" time of the file. So maybe I could (say, once per day) open a representative file on the CRD and pass it to FileTime(), then subtract from RealTime() somehow to see how many days have passed since file creation on the CRD. Compare that to DataFillDays and you've got the number of days remaining until fill. Maybe. Although I have no idea if FileOpen(), FileTime() and FileClose() will play havoc with the logger trying to write data into the CRD. I suppose I could create a dummy DataTable that I don't care about just for this purpose.
Sorry, also rambling.
I talked with the developer, and LoggerNet uses StartTime to calculate that value in the Station Status. That means that this information provided in LoggerNet may not be completely accurate if your data table structure has not changed and thus the existing records were maintained in the card table.
One thing to consider is that you could simply use a counter and increment it once per day. You could use PreserveVariables to save the value of that variable upon recompile, whenever possible. The caveat is that PreserveVariables will save the state of ALL variables in the program, which may not be desirable. In lieu of PreserveVariables, you could write the value out to a CalFile and then read it back in when the program is recompiled. You could do something similar with the number of records stored to the table.
Regarding FileOpen, I don't think you would be able to open the card file. Typically, the file on the card is open until the program is stopped or the button on the CFM100/NL115 is pressed.
Dana W.
Hm, I didn't know about PreserveVariables but I think I'll steer clear, my processing generally assumes that all the variables start up empty.
But I've decided to create a new data table (e.g. NewTable) and give it a DataInterval of 1 day, with one field written. Then I can report NewTable.Record(1,1) which should be the record number of the most recent record.
That's probably better than trying to figure out something by date arithmetic. This way, even if the program is recompiled while leaving a half-full card untouched, or if the logger gets turned off for a month sometime, or if the card is formatted but the program isn't recompiled, I should still get the right picture from the number of 1-day records that were written to the card so far and the number of records that it is expected to hold in all. I should even be able to use NewTable.TableSize for the latter instead of DataFillDays, if I want to.
With these 1GB memory cards, I can afford to waste a little space.
Thanks for your ideas, Dana!
You're welcome, and good luck! Dana W.