Jump to content

Timing Problem with PCI 6033e


physiker

Recommended Posts

Hello everybody,

we are having timing problems with our DAQ card. We are using the digital output to control a shutter in our pulsed laser setup. We are then using the analog input which is triggered (or rather clocked) over the PFI0 port by our laser system (1kHz) to measure each shot of the laser. The problem we have is that there is a timing jitter of up to 2-3 ms in the start up of the data aquisition. We are using the traditional NIDAQ drivers to do this. So finally my question: Does anybody know if the new NIDAQmx drivers solves these timing jitter problems?

Another related question is: Does somebody know a nice way to synchronize ones program to an external trigger? (Just taking an data point doesn't work for us since as I said the start up has a timing jitter larger than our repetition rate.)

Thanks for your help in advance.

PS: If somebody just could point me in the right direction where I will find the information I am looking for that would also be fine.

Link to comment

What are you measuring? Unless you need to act on each and every data point, you should be able to do buffered acquisition that is triggered by your pulse; then there shouldn't be any dependence on the OS. One can do lots of precisely-timed DAQ with E-Series cards without needing any real-time OS!!

The daqmx drivers do happen to be more lightweight than the traditional ones. If you can afford the time, switch to daqmx would somewhat future-proof your program.

If you're working under Windows, 2-3 ms might be as good as you can expect. To get real accurate real-time timing, you may need to go to LabView Real Time.

Agreed. And LabView Real-Time 7.1 introduced a fantastic VI for use with daqmx: "Wait for Next Sample Clock". This puts your hardware in the driver's seat, and jitter goes down to nearly zero. If you must use software timing in Labview Real Time, then you have to live with jitter in the microsecond range.

Link to comment
What are you measuring? Unless you need to act on each and every data point, you should be able to do buffered acquisition that is triggered by your pulse; then there shouldn't be any dependence on the OS. One can do lots of precisely-timed DAQ with E-Series cards without needing any real-time OS!!

The daqmx drivers do happen to be more lightweight than the traditional ones. If you can afford the time, switch to daqmx would somewhat future-proof your program.

Agreed. And LabView Real-Time 7.1 introduced a fantastic VI for use with daqmx: "Wait for Next Sample Clock". This puts your hardware in the driver's seat, and jitter goes down to nearly zero. If you must use software timing in Labview Real Time, then you have to live with jitter in the microsecond range.

A pathway to fully implementing this and a very versitile option to try before going for Labview Real Time is to use the Counter/Timers on your PCI-6033E card. Once configured by the software, they operate autonomously and don't need to "lean" on the software during their operation. At that point, your jitter specifications fall to the clock used to run the counter/timer and become completely independant of the software.

You can also trigger your AI sampling off of the counter/timer as well. In fact, if you need some form of delay between trigger and acquisition, you could have the laser trigger off of the rising edge and the AI sample trigger off the falling edge, and vary your pusle width to change the time alignment. Your limitation is that the maximum clock rate for the counter timer is 20 MHz.

I will admit that programming the counter timers takes a little getting used to, but the following pictures show examples provided by NI that should get you started.

Using DAQmx (more recomended)

post-2931-1150286446.jpg?width=400

Using Traditional DAQ (less recommended)

post-2931-1150286553.jpg?width=400

Just to give you fair warning, some of the more advanced counter/timer tricks will require the use of both counter/timers on the card.

BTW, what kind of shutter are you using to modulate at 1 kHz, if you don't mind me asking?

-Pete Liiva

Link to comment
A pathway to fully implementing this and a very versitile option to try before going for Labview Real Time is to use the Counter/Timers on your PCI-6033E card. .....

...I will admit that programming the counter timers takes a little getting used to, but the following pictures show examples provided by NI that should get you started.

-Pete Liiva

Pete's absolutely right on both counts. One recent project, rather than trying to synch the A/D process to the external event, turned out to be easier to use the A/D CTC to trigger a spare ctc on my 6036 card, which in turn triggered the external event-- so I synched the external event to the A/D rather than vice-versa. In that case, it was OK for the external event to occur without real-time reference, as long as it and A/D remained in synch.

Took a while to figure out how to program the CTCs, but not the worst thing I've ever done & ended up as a nice executable that the client could install on any laptop running Windows. (As I recall, never did fully understand the manual, :blink: but some of the example VI's in the LV help system made things clear enough that I was able to do what needed to be done. definitely need to hook a scope up to the counter outputs to see what happens as you learn what you are doing...)

Best Luck, :thumbup: Louis

Link to comment

Thanks a lot for the feedback everybody.

BTW, what kind of shutter are you using to modulate at 1 kHz, if you don't mind me asking?

A Pockels cell in the laser cavity. So we are not chopping a cw laser, but have a pulsed laser system with a repetition rate of 1 kHz. The shutter we are using is a slow one which blocks the pulse train.

So I think I am going to have a look into the counter programming. Thanks again.

Link to comment
Thanks a lot for the feedback everybody.

A Pockels cell in the laser cavity. So we are not chopping a cw laser, but have a pulsed laser system with a repetition rate of 1 kHz. The shutter we are using is a slow one which blocks the pulse train.

So I think I am going to have a look into the counter programming. Thanks again.

Ah, an active Q-switch. I was just curious if it were some form of modulation we don't tend to use in the labs I work in here.

Thanks for answering my query! :thumbup:

If you get stuck with the counter/timer programming, feel free to post what you have in the forum here, and we'll see if we can help out.

Good Luck!

-Pete Liiva

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.