Error 200077

[AeroSoul]

If your for loop only loops once, you can remove it.

[SUJITniser]

Yes, the for loop is running for once but I put it because of the timing. If I remove the for loop then how the time function will be put there? 

[Kevin_Price]

At the beginning of the thread, you were looking for a way to run your code on a PXI-6704 that only supports software timing.   But in msg #5 a couple months later, you seem to be back to using a PXI-6361 which supports hardware timing for DIO.

So for sure the better way to get precise and repeatable timing is to go back to using hardware timing, which you set up with a call to DAQmx Timing.  Choose a sample rate that matches the timing resolution you need, and then create the digital pattern that turns particular bits on and off at the desired times.

-Kevin P

[SUJITniser]

Actually, I need 4-5 digital signals and also some analog signals for my experiment so I am using Pxi 6704 for analog output and  Pxi 6361 for digital output. I need precise timing for this signal and at that time I was using "Onboard clock" as my reference but this clock was running for only 1 channel at a time sp all the channels could not be run at the same time. But I need all the channels running at the same time, as well as all, will be having a different time span. So I am using this type of "On-demand digital signal generator" which is controlled individually (specifically the time span of the 'on' and 'off' state). So can you advise me on a better way to do this thing or this process will give me the best precise timing?

[Kevin_Price]

The software timing you've been using will *NOT* result in highly precise timing, though I suppose this all depends on how we each define "precise".

Software timing under windows will typically give you a distribution of *actual* times that can vary from your *desired* times.  My sense of the variation is that well over 95% of the actual times will be within a few msec of the desired timing.  There will likely be a number of excursions that'll be off by something in the 10's of msec.  There may or may not be a rare instance of something being off by 100+ msec, depending mostly on how long you keep running.

I don't consider that to be "precise", certainly not for the sake of something like injection timing.

So you're going to need to use hardware timing which means you should probably be using the 6361 for analog output.  You should also probably be driving this whole thing with the encoder as a kind of master timing signal, much like in the discussion I pointed you toward.  Using counters instead of DO will make it easier to adjust pulse firing positions on the fly as well, if that's something you need to do.

Spend some more time reading and understanding that linked thread and the code.  I *think* that should be a decent base starting point for you, then you'll need to add 1 or 2 additional timed output signals, right?

-Kevin P

[SUJITniser]

Thank you for your suggestion. Actually, we need 4 to 6 analog channels but PXI 6361 has only 2 analog voltage channels so we have to use Pxi 6704 in that case until we bought another hardware to do this which will be having hardware timing. But I want to learn how to do this hardware timing. So if you can give me an example of how to do it then I can continue and also suggest from where I should read about that. Thank you for your help.

[SUJITniser]

I need some random digital pulses which are controllable in a specific time span, so as you suggested I was going through "counter finite output" and the other examples, there I am not able to give the data (0 or 1) which in the previous program (in the above VI) I can easily give and also control the time. So if you help I will be really thankful to you.

[Kevin_Price]

Sorry, in my last reply I got this thread mixed up with another I was in.  Never mind the suggestions about driving timing with an encoder, using counter output instead of DO, and references to a linked thread & code.  Those things related to the other discussion.

It sounds like you just need to sync AO and DO with precise hardware-based timing.  In my opinion, the most straightforward way to do that is to configure the DO task to "borrow" its sample clock from the AO task and then start the DO task first.

Make sure you define the same amount of AO and DO data to be generated, even if long stretches of that data are just 0's.

This *partial* example illustrates how to share a sample clock.  It uses AI and CI tasks, but the main ideas about timing and sync are all the same.  For your output tasks, you'll need to write data to the task buffer with DAQmx Write *before* you start the tasks.  It'll be easiest to use Finite Sampling if your output generation is short enough to allow it.  That'll probably be fine if your total # of samples is under 100 million or so.

    (Even if you'll ultimately need to do continuous sampling for longer times, I'd recommend you start doing your testing and troubleshooting of the sync behavior with short finite sampling tasks.)

-Kevin P

[SUJITniser]

Thank you for your reply. I tried what you have suggested. I write the code for the generation of digital pulse with hardware timing with the help of DaqMx Timing(Sample Clock) for only one channel. But the timing resolution is not good here also I have attached a photo of the output(Oscilloscope signal) where you can easily see the discrepancy which was I think less in the software timing Vi(the previous one). This timing part only depends on the sample rate of the sample clock. But in my program, I need the freedom to change this timing according to my experiment. As well as I need many such channels (Analog output + Digital output) with this timing freedom. I understand that for more channels I have to share the clock but how should I control the timing part in that case also? Please have a look and give some suggestions.

[Kevin_Price · Accepted solution]

[Edit: saw after posting that you already pulled the discussion back over here.  Thanks.]

First, let's pull the discussion back here into this thread instead of piggybacking on that other one with the old example I linked to.

Next, the code you posted is very much NOT the way to get precise timing from a hardware-clocked task.  What you seem to be doing is giving the task a single sample to generate, then you start the task and wait for a software-timed delay and then stop the task.  The whole process (write 1 sample, start and wait, then stop) gets repeated for your additional digital states.

Look closer at the shipping example for hardware-timed digital output.  You'll see that you need to define digital states for each sample time across the *entire* time period of the generation task.

In your case, you have 4 transitions for this one digital line and a sample rate of 100 Hz.   So let's suppose you want a total generation time of 1.00 sec, and to transition high at 0.20 sec, back low at 0.35 sec, high again at .75, and low at 0.95.

    You would create a finite sampling DO task with 100 samples.  The first 20 would be low, the next 15 would be high, then 40 more low, 20 high, and the final 5 low again.  You'd write that entire set of samples *ONE TIME* to your task, start it, then wait for it to be done.  That'll give you hardware-precise timing for all those digital state transitions.  You'll have timing *resolution* of 0.01 sec, but you'll find that the repeatability of any edge-to-edge timing measurements you make will be down in the small fractions of a microsecond.

-Kevin P