02-27-2009 02:41 PM
Sure, so we're a quantum optics group trying to store pulses of light onto a group of atoms, and to do this, we need to activate 4 other lasers at precise times before and after the creation of our light pulse so that we can store it properly... And then we need to do this 200000 times in a row in the space of a few minutes.
So we have a laser beam chopper which creates the light pulse and provides the TTL trigger, and we then use this TTL to signal that a pulse has been created. Then we can wait a set number of us to send the 4 other TTL output pulses which will turn on and off the 4 other lasers.
If there's still space left on the FPGA, we'll end up putting control loops on there too to lock a few optical cavities at resonance, and do both tasks simultaneously.
Thanks again for all of your help!
02-27-2009 02:49 PM
Ah.. Just one more clarification.. do we need to Real-Time Module for this to work? Our neighbors had it already, but i'd rather not buy it if we don't need it... and on the reference page, you only state that we need the FPGA module
03-02-2009 10:03 AM
That application sounds amazing! I wish I could see it in action!
The LabVIEW Real-Time Module is only required if you have a Real Time controller like cRIO or an embedded PXI controller running a NI Real-Time OS. NI RIO boards & LabVIEW FPGA work in both Windows and Real-Time. If all the control is happening on the RIO board, there is no need for LabVIEW Real-Time. I would recommend getting a Real-Time PXI controller and LabVIEW Real-Time if you start moving any control into the host program. Windows just isn't deterministic enough for control.
I hope this helps!
03-27-2009 11:00 AM
I found a bug in one of the helper VIs, Host_Calc Ticks.vi. The array input and output (Delay/Channel (s) and Delay/Channel (ticks) respectively) had been set to a fixed size of 16 elements. This means any array over 16 elements was clipped to 16 elements. This VI has been fixed on the tutorial page. Also, here is the VI if you have already downloaded this example.
11-09-2010 06:03 AM
I hope that this post is still alive...
I am trying to transmit a signal on 5 analog outputs (with a DMA FIFO) while 4 of them should start simultaniously and #5 should be delayed by ~800ns. I am using 7852R with LabView 2010.
I tried 2 methods:
1. The method that you used in the example (with the single clock loop) - it did the delay almost fine (the actual delay wasn't according to the number of clocks) but the output signal was distorted.
2. I used a descrete delay - the output signal was fine but minimal delay was a few usec which seems strange to me since I'm working with a 40MHz clock so every clock should result in a 25nsec delay.
I'm attaching my code. Please tell me what am I doing wrong.
Also, what is the difference between both methods?
Thanks in advance.
11-09-2010 08:19 AM
You can't do that with analog outputs... the 25 ns resolution is for digital outputs only. Analog outputs have an overhead of abround 1 us, so you can't use them in a single cycled time loop. (Don't have labview on my comp, so I can't look at your code thouugh, can you post a png?)
11-09-2010 08:31 AM
I understand that the 25ns is for digital signals only. Is it possible to count a certain amount of 40MHz clocks and then start the analog output? So that one analog output starts at a certain time and the other analog output starts after x 40MHz clocks?
11-09-2010 08:39 AM
Ah.. now you're being complicated
Technically, I suppose you could do that... I can think of two possible ways (though i'm not sure if either will work.. you'll have to try)
Use two loops, a SCTL to count your cycles at 25ns, and a second loop which has your analog output (AO) in case structure. Start the AO loop in the disabled cases, then after the number have cycles has elapsed and the SCTL, send a signal of some sort (Quere, local variable, etc..) to the second loop to change the case and activate the AO. It might not be exactly precise down the to tick, but it might get you close
Maybe you don't need a SCTL loop to count the ticks. There's a timer that you can configure to count either by ticks, or based on time. Perhaps you can stick that timer in the AO loop directly, and and start the loop with the AO disabled. Once a certain time has elapsed, it can send a true signal to activate the case containing the AO output. Again, I don't know how precise the tick counting timer will be in a non-SCTL, but you have to see..
You see more or less what I mean?
11-10-2010 10:27 AM
Any update Dvido?
11-11-2010 01:24 AM
Well, I played with the delay a little. As I mentioned earlier, my project includes both analog inputs and analog outputs.
First of all the analog signal acquisition and generation takes a certain amount of time, which can't be trimmed by a digital delay. 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.
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 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?
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?