Hi, For testing out some things with the LabJack T7-Pro we have, we run a version on a low level with command-response method using the on-board Lua scripts. To see if what we are expecting to happen actually happens, we use Lua to store to the on-board microSD card using file:write(...). Sometimes we like to read what is happening faster than 1 second (RTC can read only to the second), so we have tried playing with this (code snippet below):
LJ.IntervalConfig(0, 10) --set second argument as interval to 100 for 100ms
while ... do
if LJ.CheckInterval(0) then
CurrentTime = MB.R(61522, 2) --Read SYSTEM_TIMER_20HZ "Internal 32-bit system timer running at 20Hz."
ElapsedTime = (CurrentTime - startTime) / 20 * 1000 --for milliseconds.
timeStr = string.format("%09d", ElapsedTime)
file:write(timeStr, delimiter,...) --write to file with elapsed timestamp
end
end
But we have had mixed results...if you log using this method it actually is usable, but you have to adjust the times after; say you were sending commands each loop iteration at 10ms each loop, it writes to file at each loop iteration maybe saying 0 for four entries, then on the fifth entry says 50.
If you have read this and asked yourself, "Why doesn't this guy just read a stream through an application then save it?", I would say that is a great idea, but when trying to test behavior on a basic level or test it is nice to rule out other possible problems. And actually, I will say, I have streamed, but sometimes is it valuable just to run the on-board script test (much faster to implement). An analogy may be: If I wanted to get to the roof, I could use a jetpack, yes, but if I used a ladder (thus eliminating the use of fuel) I know I will not explode.
More to the point: "How would one log a timestamp at less than a second using command-response method and on-board Lua script, while saving to on-board microSD card?" OR If others have done this in the past, what method did you use? Asking others what they have used is why I went to the forums to post and not just get an official answer. If you have done this, chime in, please.
Thanks, if you can help.
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
Try using the CORE_TIMER. It has much higher resolution. Just be careful of the binary roll.
Tried this before and did have overflow, any quick way to get around that?...I do some programming, but not usually handling these issues(binary overflow).
Code was changed to this and values came back negative & large after a short while:
LJ.IntervalConfig(0, 10) --set second argument as interval to 100 for 100ms
startTime = MB.R(61520, 2) --read CORE_TIMER at 40MHz (40000000 cycles / second ).
while ... do
if LJ.CheckInterval(0) then
CurrentTime = MB.R(61520, 2) --read CORE_TIMER at 40MHz (40000000 cycles / second ).
ElapsedTime = (CurrentTime - startTime) / 40000000 * 1000 --for milliseconds.
timeStr = string.format("%09d", ElapsedTime)
file:write(timeStr, delimiter,...) --write to file with elapsed timestamp
end
end
Thanks, if you can help.
To handle counters that can roll we need to do a couple things. First we need to be sure that we are sampling that counter at least twice as fast as the counter's shortest possible roll period. Sampling any slower than that will result in aliasing that will make solving the roll issue impossible. The CORE_TIMER is 32 bits running at 40 MHz which gives us 107 seconds. Second, we need a little math.
The math is a little easier if you are only interested in the time step, but total time is not much harder. For total time we need to compare the value of CORE_TIMER to the previous reading. If the value is smaller than the last time it was read then we know a roll occurred and we need to add the counter's maximum value + 1 or 2^32. Each time a roll occurs another 2^32 must be added to the total.
If all we want is a time-step then there are some tricks we can use. Subtract the previous value from the new value. If you can force 32-bit unsigned math, then you're done, if you can not then we need to add a step. If the result of the previous subtraction is less than zero, add 2^32.
Consider a 4-bit counter which can represent 16 value, 0 to 15. The first time we read the counter it returns 13 and the next reading returns 2. The counter must have counted 14, 15, 0, 1, 2 for a total of 5 counts, but our math turns out 2-13 = -11. To account for the roll we add the number of values that the counter can represent for -11 + 16 = 5.
"More to the point: "How would one log a timestamp at less than a second using command-response method and on-board Lua script, while saving to on-board microSD card?" OR If others have done this in the past, what method did you use? Asking others what they have used is why I went to the forums to post and not just get an official answer. If you have done this, chime in, please."
Have you seen the Lua examples? In Kipling there is a drop-down box labeled "</>" on of the examples there is "Log voltage to file" That example demonstrates one method of logging to file with a time-stamp. It uses strings to avoid data truncation issues associated with the single-precision datatype.
Also, customers have reported being able to log to a file at 200 Hz, but 10-100Hz is more reasonable. It all depends on how far you are willing to go to optimize the process