Besides that, when I tried to implement a digital delay, the delay was
performed with the same resolution as the analog output clock i.e. if I
transmit a signal with a 500KS/sec, the minimum delay I can get is
1/500KHz.
Yeah, that doesn't surprise me..
Also, for my understanding, the only way to delay one analog output
from another by a digital delay is that the analog outputs will have
different clocks
Yes, that's the only way that I can think of (not to say its the only 100% possible way)
but I think that they all have the same clock hence the
delay between them can be done only with their clocks (1M or less). Am I
correct?
This is why I suggested you put your analog outputs in a case structure in a separate loop than your digital clock loop. That way the digital clock can use the Single Cycle Timed Loop (SCTL) resolutation, and trigger the analog output at the right time. That said, I'm not sure it that will improve the precision. I think a while loop with no other output has a 3 tick overhead (so running a while loop with an empty case structure should take 3 ticks per iteration), but that's better than a 1 us overhead of using a while loop with the analog output case active
Also, there is a VI called "Descrete delay function" which is
supposed to do exactly what I need - what is the difference between that
and using a single-clock loop and counting clocks?
Don't know.. never seen this. Maybe its something new in 2010
NI Hardware: PXI-7853R, PCI-5122, PCI-6733, PXI-1036, PCI-MIO-16E-4, PCI-6110
Computer Hardware: Xeon Quad Core - 2.33 Ghz, 8 GB RAM
Software: Labview 2009, Labview FPGA 2009, Vista 64-bit, MAX 4.6, DAQmx 9.0, NI-SCOPE 3.5