multiple write operations in a task synchronized with trigger

[johndoe777777779]

My goal is to write digital patterns, first a long lasting setup pattern is written, and then a faster burst of pattern is written. I also need to synchronize this task with other actions (for example, clock generation). For the synchronization, I use the trigger functionality. Thus I have two write actions in one task, and this task is synchronized to a trigger. However, with the trigger task and the write task, only the first write call DAQmxWriteDigitalU32 works, and the second write call is ineffectual. Does the second write call need to another rising trigger?

    # DAQmx Configure Code
    DAQmxCreateTask("taskSrlO",  byref(taskHandleSrlO))
    # DAQmx Create Channel
    DAQmxCreateDOChan(taskHandleSrlO,
            "Dev1/port0/line0:1, Dev1/port0/line2:7",
                    "", DAQmx_Val_ChanForAllLines)
    # DAQmx Timing Setup
    DAQmxCfgSampClkTiming(taskHandleSrlO, "", 1,
                            DAQmx_Val_Rising, DAQmx_Val_FiniteSamps,
                            1+dataSrlO.size)

    wrtSrlO = c_int(0)
    # DAQmx Write Code
    DAQmxWriteDigitalU32(taskHandleSrlO, 1+dataSrlO.size, 0, 10.0,
                            DAQmx_Val_GroupByChannel,
                            dataSrlO, byref(wrtSrlO), None)

    #Start output at trigger, the trigger in in taskHandle1
    DAQmxCfgDigEdgeStartTrig( taskHandleSrlO, "/Dev1/PFI14", DAQmx_Val_Rising);

    # DAQmx Start Code
    DAQmxStartTask(taskHandleSrlO)


    # DAQmx Configure Code
    DAQmxCreateTask("",  byref( taskHandle1));
    DAQmxCreateCOPulseChanTime( taskHandle1, "Dev1/ctr2", "",
                                DAQmx_Val_Seconds, DAQmx_Val_Low,
                                0.001,0.50e-3,1.00e-6);

    DAQmxStartTask(taskHandle1)

    # DAQmx Wait Code
    #DAQmxWaitUntilTaskDone(taskHandle1,10.0);

    # DAQmx Clear Code
    #DAQmxClearTask(taskHandle1);

    DAQmxWaitUntilTaskDone( taskHandleSrlO, 5);   
    print("Written1: %d\n" % wrtSrlO.value)

    DAQmxStopTask(taskHandleSrlO)
    # DAQmx Timing Setup (frequency = 50)
    DAQmxCfgSampClkTiming(taskHandleSrlO, "", 50.0,
                            DAQmx_Val_Rising, DAQmx_Val_FiniteSamps,
                            1+dataSrlO2.size)

    # DAQmx Write Code (autostart = 1)
    DAQmxWriteDigitalU32(taskHandleSrlO, 1+dataSrlO2.size, 1, 10.0,
                            DAQmx_Val_GroupByChannel,
                            dataSrlO2, byref(wrtSrlO), None)

    print("before Written2: %d\n" % wrtSrlO.value)
    DAQmxWaitUntilTaskDone( taskHandleSrlO, 50e-0);   
    print("before Written2: %d\n" % wrtSrlO.value)

[johndoe777777779]

Note: here a call to DAQmxDisableStartTrig(taskHandle) before the second DAQmxWriteDigitalU32 helps. But, I do need the second DAQmxWriteDigitalU32  to be synchronized with my generated clock.

Thanks,

[Kevin_Price · Accepted solution]

Consider this as educated guesswork, not definitive statements.   I only program in LabVIEW and don't know the details of the text API.

I'm inclined to advocate that you make explicit config calls rather than trying to rely on implicit behavior.  It may not be necessary to always keep it that way, but it's liable to help during the learning and troubleshooting phase.

The first time you start the task, you first write the data then you call the start function explicitly.  Go ahead and do it the same way for the second start.  (Working theory: the autostart=False setting from the first write call remains persistent so that the autostart=True on the second write call gets ignored.

Another option that's pretty sure to work is to fully clear the task after stopping it, and then fully reconfigure for the second activation.  (This is much less efficient than what you're trying to do now, but it has the advantage of giving you a starting point where you get correct behavior with a slow transition between the 2 segments.  When you start from a "known working" point,  it's often more simpler to determine which change made the behavior break.)

Based on DAQmx experience under LabVIEW, I'm pretty sure (but not quite entirely sure) that if you stop a finite output task, change its sample clock settings, write new data to its buffer, then restart the task, you should *not* need to reconfigure the original triggering settings.  They should persist and still be applicable to next time you start the task.

If you want the counter pulsetrain to act as the sample clock for the task, I don't think you're configuring correctly for that.  I don't see anything that links the pulse train task or terminal to the DO task timing.  I suspect the place to specify it would be the call to DAQmxCfgSampClkTiming where you presently have an empty string "" (which likely means, hey DAQmx, create me a sample clock derived from one of my board's own internal timebases).

-Kevin P

[johndoe777777779]

Thanks for the detailed comments. Yes, as you said the trigger settings stay the same even after stopping the task. So, I just had to generate 2 pulses in my trigger port. It would have helped if it was possible to configure trigger to happen at Nth pulse (rather than 1st trigger pulse).

---

Based on DAQmx experience under LabVIEW, I'm pretty sure (but not quite entirely sure) that if you stop a finite output task, change its sample clock settings, write new data to its buffer, then restart the task, you should *not* need to reconfigure the original triggering settings.  They should persist and still be applicable to next time you start the task.

---