USB-1608G, Acquire Data synched with trigger restart

[radikarl]

Hi,

I have an USB-1608G and I want to acquire 8 differential signals (analog voltage) in Labview simultaneously, synchronized to a digital egde coming from a motor. The motor generates a digital egde at each full revolution and turns at constant speed (1,2 or 5 revolutions per second, depending on my specific test parameters).

I'm trying to get a finite number of samples for each revolution of the motor.

My sample rate also depends on my specific test parameters, but it's usually 100Hz or 1000Hz and I'm trying to acquire as many samples as possible before the next trigger fires.

Now here's my problem: I tried to take e.g. 950 samples at 1000 Hz for a motor speed of 1 rev per sec, so there should be 50 ms time for recognizing the next trigger pulse. But unfortunately, not every trigger is recognized by the USB1608G.

I tried to keep my Labview-VI as simple as possible at first, in order to minimize execution time of the daq-loop, no signal processing etc.

there's a loop with "start daq", "read" and "stop daq", nothing more.

when I go to 900 samples for the above configuration, the duration for the execution of these 3 VI's takes slightly over 1000 ms, see picture attached. In this case, all triggers are recognized, but I give up on 10% of data I want to acquire (900 instead of 1000 in this example).

I would expect the device to "settle" within a few milliseconds, but not that much. the motor speed itself is quite constant, I measured the period of digital egdes to be within +/-1ms of the desired duration

Is there a proper way to do this? Maybe there's a better approach. When I only use one start trigger and then keep acquiring a finite number of samples, the voltage measurement is not synchronous to the motor position after some time, so that doesn't work for me

 

Thanks.

 

Edited November 9, 2023 by radikarl

[DAQman]

The USB-1608G has a retrigger mode, but unfortunately, it is not supported with LabVIEW. This is because it requires using the status function, which was never exposed to ULx LabVIEW users. As a workaround, you must use finite mode, which requires restarting the task. This puts you at the mercy of Windows and the execution speed of the intermediate ULx layer. My tests using a 1-second trigger and a 1000 hz sample rate, indicate it could capture 900 samples, but 950 resulted in missed triggers.

An alternative approach would require an incremental shaft encoder that could output pulses while the motor is turning. You could then use the external clock feature to force a measurement on each pulse. 

[radikarl]

Thanks for your reply. I will have a look at my servo controller to check, if it's possible to map the encoder ticks as pulse on digital out. This could be an elegant solution.
Otherwise I'll problably have to live with the loss of the last 10% samples for each motor revolution.

For which software is the retrigger mode supported? I've used python and matlab once in a while, so this could be an option for my data acquisition, if I can use the retrigger mode.

[DAQman]

It would be best if you programmed the USB-1608G directly using the Universal Library API, so Python should do it. Once you have started a continuous background scan, you can use events to notify you of the trigger by indicating that data is available. Or, loop on the get_status function and wait for the buffer index to change.

[radikarl]

Before I try Python, I want to stick to Labview and try the method you proposed, using encoder ticks as external clock.
For my first test setup I used a function generator to create pulses of either 10 ms or 1 ms and connected it to AICKI. This will later correspond to my encoder ticks, where I only will use 100 ticks per revolution with slowest speed of 1 Rev/sec (=10ms pulse period) and highest speed of 5 Rev/sec (=2ms pulse period).

I set up an external clock analog voltage measurement using only 1 channel at first. I tried two different versions, in the first only 1 sample is read per loop iteration. In the second one I read multiple samples per iteration. I measured the time it took to acquire the data samples. Both versions showed an odd behavior:

When I read single values, the time between each sample is about 2ms regardless of the external clock being 2ms, 5ms or 10ms. But every 256 samples there's one sample that took significantly longer (750ms for 5ms pulse period, 2040ms for 10ms pulse period).

When I read multiple samples (100 per iteration, representing one motor revolution), the duration for acquiring the samples alternates between one (or two) short intervals of 3ms and one long interval, depending on the pulse period (500ms for 2ms period, 1270ms for 5ms period, 2500ms for 10ms period).

I actually would expect the acquisition time to be consistent with my external clock, otherwise I can't be sure the measurement is synchronous to my motor shaft.
Is there anything specific I must consider when using an external clock?