Hello,
What purpose does exporting the onboard clock to DDC CLK OUT have on your application? Since you are acquiring with the onboard clock, it breaks the source synchronous paradigm that the DDC CLK OUT signal is typicall used for. This white paper talks about various synchronization methods https://www.ni.com/en/support/documentation/supplemental/14/hsdio-generation-and-acquisition-synchro...
Next, you use an advance trigger without a start trigger on your acqusition session. The advance trigger is meant for multi-record acquisition. Do you wish to acquire multiple records, or just all the data in a single record? You also start acquiring immediately, since no start trigger is configured. This may cause issues with synchronization as software will start your acquisition session before your generation session, and you will likely acquire bad data at the beginning of the program.
If you route the clock to PFI 3, you're effectively triggering off the clock, which seems strange to me. Also, since the clock is periodic, likely your "wait until scriptTrigger0" line of your script will execute instantaneously, because once a script trigger is received, it is latched/asserted until it is read or the clear scriptTrigger0 script function is called.
Even if you increase your repeating to 100, you are setting your acquisition size to equal to wfm + wfm1, and then acquiring three records of that amount. Maybe you've changed the record size as well when you changed your repeat, but thought I'd point that out.
If you want to acquire data when the marker0 appears, you should move the marker to assert just before you generate data. Otherwise, you are waiting cycles before "generate wfm" appears, and you will likely acquire less data than you intend.
To debug, you may want to check how many records you are acquiring vs what you have configured. You should also consider reducing the acquisition size/samples per record while you are debugging. You also reduced the timeout to 5s in the code you listed, but you might want to consider leaving it as default 10s while you figure out how the code is working.
My recommendation is to reduce the script to one waveform, without scriptTrigger0 (since it doesn't look to be doing much), and see if you can get marker0 to trigger your advance trigger correctly so that you can acquire multiple records. Once you have that down, you can move towards increasing your records, your acquisition size, and adding more waveforms into your generation script starting from a known working point. It seems like trying to make everything work all at once is making things too complicated, and it is hard to tell which part is failling.
Hope this helps, good luck.
Kyle A.
National Instruments
Senior Applications Engineer
