Jump to content

Oswin

Members
  • Posts

    4
  • Joined

  • Last visited

Posts posted by Oswin

  1. I'm using the `uldaq` Python library with a USB-CTR04 device.

    Whenever I call the `get_pulse_out_status` method, it always gives me `TmrStatus.RUNNING`, regardless of the actual state of the timer.

    Python 3.10.6 (main, May 29 2023, 11:10:38) [GCC 11.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information. 
    >>> import uldaq 
    >>> devices = uldaq.get_daq_device_inventory(uldaq.InterfaceType.USB) 
    >>> daq = uldaq.DaqDevice(devices[0]) 
    >>> daq.connect() 
    >>> tmr.get_pulse_out_status(0)
    <TmrStatus.RUNNING: 1> 
    >>> tmr.pulse_out_stop(0) 
    >>> tmr.get_pulse_out_status(0) 
    <TmrStatus.RUNNING: 1> 
    >>> tmr.pulse_out_start(0, 100, 0.5, 0, 0.0, uldaq.TmrIdleState.LOW, uldaq.PulseOutOption.DEFAULT)
    (100.0, 0.5, 0.0)
    >>> tmr.get_pulse_out_status(0)
    <TmrStatus.RUNNING: 1>
    >>> tmr.pulse_out_stop(0)
    >>> tmr.get_pulse_out_status(0)
    <TmrStatus.RUNNING: 1>

    I believe this is a bug. The method should return `TmrStatus.IDLE` when the pulses have ceased.

    P. S. Issue raised on Github as well: https://github.com/mccdaq/uldaq/issues/56

  2. On 2/28/2023 at 7:46 PM, Fausto said:

    The USB-CTR04 and USB-CTR08 do not support Timer triggering, unlike the USB-1808 Series.  Only the Counter Input and Digital I/O subsystems on the USB-CTR Series support external triggering.

    Hi Fausto,

    Thanks for this clarification. Understood that triggering is not possible with timers on the USB-CTR boards. That helps.

    However, that does not completely answer my question. My main inquiry is whether there is ANY way to repeat a timer's output every X us? The concept of triggering was just an example of a way that might achieve that. Now that I know triggering is not possible, is there any other way to do this?

    As a reminder, here's an illustration of what I am seeking to accomplish:

    On 1/25/2023 at 11:20 AM, Oswin said:

    Let's imagine we're dealing with just one timer here, for simplicity. I want this timer to output a finite number of pulses at a particular frequency and duty cycle. This is easy enough to do with the pulse_out_start function. Next, I want to repeat this resulting waveform every 100 us. THIS is what I am struggling to do and what I need the most assistance with.

    Many thanks,
    Oswin Rodrigues

  3. Putting my DM conversation with an engineer over here as an update to this:

    Quote

    If it is not possible to perfectly synchronize two timer outputs due to a design limitation, that is an acceptable answer. I appreciate the clarity in that. As mentioned in my original post, this part of the problem is not a big deal, because I can use the initial_delay argument to shorten the gap between the two waveforms and align them within a sufficient tolerance.

    The bigger issue for me is the second part of my post: how to repeat a timer output at a microsecond-level interval period. Allow me to explain. Let's imagine we're dealing with just one timer here, for simplicity. I want this timer to output a finite number of pulses at a particular frequency and duty cycle. This is easy enough to do with the pulse_out_start function. Next, I want to repeat this resulting waveform every 100 us. THIS is what I am struggling to do and what I need the most assistance with.

    I tried the code below, but it results in a pulse waveform that repeats every 14 ms, NOT 100 us. I figure this has to do with the accuracy of the time.sleep() function.

    import time
    
    while True:
      timer.pulse_out_start(...)
      time.sleep(0.0001) # Sleep for 100 us

    Is there any way to accomplish this? Perhaps using "triggers" for the timer i.e. the set_trigger function with the RETRIGGER option?

     

  4. Hi,

    I am interfacing with the USB-CTR04 board using the uldaq Python library. I have two desired outcomes:

    1. To drive two timers in sync with identical pulse waveforms
    2. To time the start of these pulses with microsecond accuracy

    Here's an example of what I mean: every 100 us, I would like TMR0 and TMR1 to both generate 50 pulses at 100 kHz with 50% duty cycle.

    However, I face difficulties with executing this level of control using the Python library. Specifically, in order of the objectives:

    1. Driving Timers In Sync

    pulse_out_start method only accepts one timer ID. I have to call it separately, once for each timer, like this:

    for id in TIMER_IDS:
      timer.pulse_out_start(id, ...)

    This results in a delay of about 5-7 ms between when the two timers start their pulse waveforms. I was able to work around this by using the initial_delay argument for the first timer. I gave it a value of 0.007 s, which caused the waveforms to align within 1 us.

    This works, but I'm wondering if there's a better, more correct way to do this i.e. a way that I can command the board to drive both timers simultaneously.

    2. Timing Commands With Microsecond Accuracy

    Python's time.sleep() method does not work at resolutions of microseconds. I tried the following:

    while True:
      start_both_timers()
      time.sleep(0.0001) # Sleep for 100 us

    But the measured spacing between consecutive waveforms is around 14 ms, not 100 us. This has to do with how time.sleep() works and the accuracy of the clock that drives it.

    I'm wondering what's the correct way to do this. Maybe I can use a third timer, say TMR2, to run at 10 kHz (100 us) and somehow use its rising edge as a trigger for the other two timers?

    I see there is a set_trigger method for timers, however the linked API reference only says to specify the trigger type e.g. POS_EDGE  and to use RETRIGGER (for my case) in pulse_out_start. It does not say how to specify TMR2 as the trigger source.

    I'd love to know how to use triggers with timers, since there are no examples for this in the library.

    Thank you for your time. If I can get help with only one thing, I would say the second issue is more important. I have an acceptable workaround for the first one.

    Cheers,
    Oswin Rodrigues

×
×
  • Create New...