X-Series two digital outputs on opposite edges of a continuous counter task

[cbutcher]

I have some code that is currently working but I believe is likely to cause problems as the clock rate rises. At the moment, I write 8 values (Task B) on falling edges of a Counter Output Pulse Generation task (C), and use a software-timed single boolean write for the other task (A).

Ideally, I would like to set A low on a rising edge of Task C, then have 8 falling edges for task B, then set A high on the next rising edge (so 9 samples for A, 8 for B, and continuous output for C).

If C were not continuous, this is pretty easy. I just start both digital output tasks before starting the pulse train, then use the Timing VI to set the sample clock edge. However, with a continuous sample clock, I'm not sure how I can prevent the two tasks from falling out of sync (e.g. A goes low, B doesn't start, A remains low and B starts, ..., A goes high, B writes the final sample but A is already high, and the input registers are disabled on the device).

Is there some better way to make this work? I can't put them in the same task (my first attempt) because I need to prevent additional samples being written to B, which as far as I can see requires that A uses rising edges whilst B uses falling. (Actually, as I read this and look at the images, I realise the more accurate description is that I need to deassert A before C can create another falling edge after the samples are all written - preventing intentionally writing samples is handled by the Stop).

My guess is that making A sample clocked on rising edges and disabling auto-start will help, but I don't think it excludes the problem, just makes it a bit less likely.

[Kevin_Price]

I'm pretty sure you can't have 2 distinct hw-timed tasks running at the same time on the same X-series board.  You are looking to solve this within a single board, right?

The main way I know of to be sensitive to both edges of a clock is to use a DI task set up for change detection.  This would end up being a dummy task, used solely to generate the "Change Detect Event" signal that can be exported as a sample clock for your DO task.

Which X-series board do you have?   Many of the common ones only have 8 bits on port 0, the only port that supports hw-timing.  That's another obstacle that could prevent 9 distinct hw-timed DO bits.

In which case, I'd probably be trying to do a more normal DO with the 8 bits clocked on falling edges and try to sync up a 2nd counter to do the 1 bit on the rising edge.

Does your pulse train task have another purpose besides acting as a clock for these bits?  Some things might work out better if it could run at 2x or 4x, and then the DO only changes values every 2nd or 4th sample.

-Kevin P

-Kevin P

[cbutcher]

Reading your response makes me think I might have been a bit unclear - in this example, I'm only looking to have two lines, where the number of consecutive samples is 9 and 8 respectively (so that the one with 9 samples brackets the one with 8). Rereading makes me unsure I understood properly when I read - do you mean that connecting a digital write to DAQmx Write with more than 8 samples (with or without regeneration) will cause a different timing method to be used/disqualify hw timing?

I'm tentatively hopeful that a shared trigger (maybe a dummy PFI line) could be used, but I might need to be careful to avoid triggering between a rising and falling edge (as apposed to between a falling and rising edge).

In a separate group of tasks (also using the clock line, and the reason I don't think I can stop the clock) I have a digital change detection line which is triggered by a "Busy" signal falling, and triggers a selection of reading and writing tasks. All of these are using the counter's output terminal as the source for their sample clock timing.

The board is a USB 6356 (not the PXI one). I also have a USB 6366 available, but I think that's the same board but with a faster maximum analog input frequency.

When you describe the change detect event, you mean to have it detect for example rising edges on the clock output, then use the event as the sample clock for the groups of tasks that require rising rather than falling edges? I can take a look into this more closely but it would mean rewriting the other tasks to not require the change detection, since as I understand it there is only one event available (although you can monitor for multiple different edges).

[Kevin_Price]

Ok, I've re-read and examined the code more carefully now.  I see the quandary.

Another part of your app has already taken control of the change-detection aspect of DI.  You won't be able to make a second distinct DI task based on a different set of change detection parameters (which bits, which polarity).

Right now change detection only detects the falling edge of "Busy".  It'd be handy to also:

- detect both rising and falling edges of a CO pulse signal

- have one set of tasks only get triggered by the "Busy" change

- have two other signals only get triggered by 1 polarity each of the CO change

Those aren't gonna happen directly on a single board.  You can probably work the 2 signals responding to CO if you bring in the other board.  You'd set up change detection for both edges of the CO signal and put both A and B bits into the same task.  Then you've got to carefully assemble the data for A & B bits -- for example, you'd double up each value you're currently planning for B b/c you'll be getting twice as many "change detect" pulses  since you'll be sensitive to both edges.

What remains is a way to be sure you know which edge produces the 1st change detect event, whether rising or falling.  You may be able to do this by starting the DI change detect task *before* the CO task, thus you can know which edge will be coming first.

-Kevin P