Hello there,
i got a new probem with time-measurement. My signal ist a non-periodic signal and i need to measure the time between the first and second falling or rising edge. I use the LabJackU3-LV at the moment. So here´s what i did until now:
Thats the Examplesignal:
At this example i would need the time between the first and second rising edge. So there´s my problem:
With this code i can´t be sure about wich edge i catch with the Timer:
import LabJackPython
import time
import u3
d = u3.U3()
d.getCalibrationData()
d.setDOState(ioNum=0, state = 0)
d.configIO(TimerCounterPinOffset=4, NumberOfTimersEnabled=1)
d.getFeedback(u3.Timer0Config(TimerMode = 2))#u3.Timer0Config(TimerMode = 3) misst Zeit zwischen fallenden Flanken
TimerClockBase = d.configTimerClock() #default 48MHz
print(d.configIO())
i=0
while i<15:
d.setDOState(ioNum=0, state = 1)
t=d.getFeedback(u3.Timer0(UpdateReset = True, Mode = 2))
time.sleep(0.2)
d.setDOState(ioNum=0, state = 0)
print(t)
time.sleep(0.5)
i+=1
LabJackPython.Close()
------------------------------------------------------------------------------------------
And the result was:
{'TimerCounterConfig': 65, 'DAC1Enable': 0, 'FIOAnalog': 0, 'EIOAnalog': 0, 'NumberOfTimersEnabled': 1, 'EnableCounter0': False, 'EnableCounter1': False, 'TimerCounterPinOffset': 4}
[0]
[169174]
[14129]
[14018]
[14130]
[13167]
[166171]
[166459]
----------------------------------------------------------------
With the d.setDOState() is just create a single pulse for an elecrical circuit. It´s not the signal i want to measure.
Every time I start one puse, i´ll get answer signals like the pic but always a little bit different. Somtimes i got just 2 pulses, sometimes 4. But I always want to measue the first two edges. The time in between varies from 2 ms to 30 ms.
So these values are not matching with the pic before, but show what my problem is.
The value about 160000 would be the right one, the other not. It seems like Python need different time to read the Timer value. One time he take the first 2 rising edges, the other time the second and third.
So now my question: Is there any solution to get sure that the timervalue will be the one from the first and second edge?
In the future i got 3 different signals and want to measure them paralell with the u6. It would be the same problem I think.
Thanks for your help!
best regards
Andy
.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")
With the T-series devices you can use a similar timer (DIO-EF) in oneshot mode, where the timer measures one period between the first 2 edges after each read, but with the U3 the timer only supports continuous mode where a it updates the measurement on every edge.
Perhaps you should stream the timer reads. Since you know the minimum period is 2 ms, if you read the timer value every 2 ms or faster you know you will get the measurement for every edge, and then in software you can decide which ones you want or not. You can read the timer this fast using stream mode. Most people would stream channels 230 & 224, such that the timer value will return each reading only once and other readings will return 0:
https://labjack.com/support/datasheets/u3/operation/stream-mode/digital-...
If you want to try it with LJStreamUD, use "config defaults" in LJControlPanel to configure the timer as the power-up default and then power cycle the U3.
The T-series sound perfect for that, but i don´t have one :/. I need to use the U3-LV or U6.
I can´t use the LJStreamUD because i need to open the JabJack in Python and you can open it just onece.
I tried you advice to steam the Timer and it worked. But there some inconsistencies for me. Maybe you can helb me to what the problem is.
As tamplate for the script I used the steamTest.py on github. The signal I analyzed, has two rising edges ~4.7 ms apart.
In the script i changed that i first configure the Timer0 as written in DataSheet and i append the list from CH224(TC_Capture) to the list from CH230(Timer0). So as answer I´ll get a List with the timer values.
d.getFeedback(u3.Timer0Config(TimerMode = 12) #(16-bit Timer rising Edges as recommended)
TimerClockBase = d.configTimerClock(TimerClockBase = 2, TimerClockDivisor = None) #default 48MHz
d.streamConfig(NumChannels=2, PChannels=[230,224], NChannels=[31,31], Resolution=3, ScanFrequency=SCAN_FREQUENCY)
With this Code i got answer like this: Index 515 is the one from CH230; 1115 the one from CH224.
So here some questions:
With this timervalues i don´t get my time of 4.7 ms anyway. Why do i need the CH224? I read the 3.2.1 - Streaming Digital Inputs, Timers, and Counters, but when i want the MSW when the LSW? Which are the true values i need? For 4.7 ms i would need i value of 225600 with this Trimerconfiguration. The 15+16 are overflowes? How to include them to my calculation?
After this i tried other Tiemerconfigurations:
TimerClockBase = d.configTimerClock(TimerClockBase = 5, TimerClockDivisor = 256) # 12MHz / Divisor 256 = 46875
Answer was:
So now with the TimerValue 220 at Index 521 I´m abele to calculate the time: 220/46875Hz = 4.69 ms!
My signal ist just the 2 rising edges. So why are there some other values in the list?
At the end of the script there are some prints:
2 requests with 48.0 packets per request with 25 samples per packet = 2400 samples total.
423 samples were lost due to errors.
Adjusted number of samples = 1977
The experiment took 0.453152 seconds.
Actual Scan Rate = 5000 Hz
Timed Scan Rate = 1200.0 scans / 0.453152 seconds = 2648.118070757715 Hz
Timed Sample Rate = 1977 samples / 0.453152 seconds = 4362.774521573335 Hz
Afer running the script i get a list with 2 lists in it. There are 2400 values like the 2400 samples total. Sounds good. But there are 423 samples lost due errors... Why is that. Could i loose the values i need? Maybe thats why the first fonfiguration doesn´t work?
Thanks for your help!
best regards
Andy
Lets resolve the 423 missing samples and see how the data looks afterwords. Missing samples/scans occur when there is a stream buffer overflow on the U3. That happens when your application is not reading stream data at a fast enough rate from the U3. Make sure your stream loop has minimal delay between streamData calls to make sure it can reads 5000 scans per second, which looks like your currently configured scan rate. If you have sleep calls in your stream read loop, lower the sleep times or remove then. That applies to other large overhead code such as plotting. If that information doesn't help with the missing samples, I will need more information on your stream read loop code too see what is delaying it so much, as a 5000 Hz scan rate shouldn't be too hard to keep up with depending on your computer and processor.
Some additional information, a scan of 65535 values indicates where the missing samples happened, and r["missed"] indicates how many scans were skipped (missing samples = r["missed"]*numChannels). With those "overflows" you were detecting, those could of been where the missed samples scans occurred.
Regarding general usage with streaming channels 230 and 224, channel 230 is the lower 16-bits and channel 224 is the upper 16-bits of the 32-bit timer value. So when reading your stream data back, the full 32-bit value using the first scan is:
scan0 = r["AIN230"][0] + r["AIN224"][0]<<16
And then:
scan1 = r["AIN230"][1] + r["AIN224"][1]<<16
And so on.