Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Accurately controlling 3 pulses from 3 counters from hardware using PCI-6601

Solved!
Go to solution

Hi,

 

This is a follow up to a previous post

http://forums.ni.com/ni/board/message?board.id=40&message.id=7914#M7914

regarding controlling a PIV rig from LabVIEW using a PCI-6601.

 

The task requires generating pulses on three counter outputs. For the laser Q-switch, a double pulse is required (which is solved in the previous post), whilst the other two are single pulses. It is important to be able to accurately control the pulse width and time difference between the pulses.

 

As far as I understand, I need to configure the timers to start, and then make them run from the hardware without further software input

 

I have tried using the 'initial delay' option when creating the counter channels, but it is very innaccurate (presumably this uses the software?). Similarly, using the offset option in timed loops does not produce a consistent delay (and requires the use of a counter as a timing source, leaving me without enough counters)


Below is a basic timing diagram for a single iteration, bearing in mind this needs to be repeated in the range 100-1000Hz, approximate pulse widths (PW) would be 2 microseconds and the delays in the region of 500 microseconds.

 

 timing.JPG

 

 

 

I need to be able to define

cam delay and laser delay accurately (and the pulse widths should be easy in theory)

 

Sorry if I've forgotten anything important and thanks for your help

 

Kind regards

Joe

0 Kudos
Message 1 of 11
(7,236 Views)

Hi Joe,

 

So you are trying to use hardware timing to control your application.

 

What DAQ card are you currently using?

 

Yes if you were to using the initial delay this would be software timed and so would only be accurate to milisecond precision. To get your application to be hardware timed you will need to use the clock in the card you are using.

 

Another alternative would be to use Real time. Are you familiar with this?

 

Thanks,

Owen.S
Applications Engineer
National Instruments
0 Kudos
Message 2 of 11
(7,209 Views)

Hi Owen,

 

I am not using a DAQ card, all of the data will be stored on the camera, an IDT MotionPro X3, which I am controlling from LabVIEW, which just requires a trigger input.

With regards to the clock in the card, is this the 20MHz Timebase? I have tried to use this to run timed loops with an offset, but this does not seem accurate either.

Furthermore, a post on the previous thread suggested that 'you can simply place a "DAQmx Task Name" on the block diagram, select the clock you want from the drop down list and wire it straight into the Source Name of the Timed Loop'

however,the "DAQmx Task Name" does not have anyoptios in the dropdown list other than to create a task using MAX.

 

Is there something clever I could do with triggers?

I am not familiar with the NI Real Time options, but would ideally like to avoid any further purchases if possible.

 

Thanks for your help

 

Regards

Joe

0 Kudos
Message 3 of 11
(7,204 Views)

Hi Joe,

 

I assume you are using the PCI-6601 like the previous post?

 

Yes what you will need to do is create 3 counter channels and link them all to the 20MHz timebase. Do you have any digital PFI lines for a start trigger?

 

You need to make sure you are using everything hardware timed. This problem crops up alot because it can be hard to distinguish which is which. Any software triggering or timing that is run by Windows will not be accurate to less than 1 milisecond so you need to make sure this is all tied to the hardware clock.

 

There are a few examples in the find examples palette in the help section of LabVIEW.

 

Could you perhaps tell me a bit more about your actual application? This way I can get a better understanding of what your overall goal is.

 

Thanks alot,

 

 

Owen.S
Applications Engineer
National Instruments
0 Kudos
Message 4 of 11
(7,198 Views)

Hi Owen,

 

I am using a PCI-6601 (as mentioned in the title).

I don't have access to any of the digital lines with my current connector block. Are you suggesting that these could be used to trigger the start of each of the pulse trains?

I have looked through the examples in LabVIEW and on the website, but have not found any that match the problem. If you could suggest specific examples, that would be useful.

 

The application is Particle Image Velocimetry, which allows for a flow field to be visualised by illuminating a seeded flow using a laser. A double-pulse mode camera is used (IDT MotionPro X3), which takes two images in rapid succession per cycle (e.g at 500Hz with 100ns between exposures for the two images). This needs to be synchronised with two laser pulses. The FPS pulse is used to ensure that the power in the two laser pulses is equal.

 

Thus per cycle, I need a camera trigger, an FPS trigger and two laser triggers, thus using all four counters, as in the timing diagram. The timing is very important as we will be working with very small scale channels (in the region of 50-150 microns diameter) and thus it is important to use hardware timing. If this is not possible without the digital lines for triggers, then I could probably run to a CB-68LP connector box. What do you think?

 

Thanks

 

Joe

 

0 Kudos
Message 5 of 11
(7,183 Views)
Solution
Accepted by JSherwood

Hi again Joe,

 

We could just trigger everything off of counter 2 (the FPS pulse that seems to start the whole acquisition).

CTR 2 would be a continuous pulse generation (at the rate we want to re-trigger the whole process).

 

CTR 3 would be a single, retriggeralbe pulse generation with an initial delay.

 

CTR 0 and 1 are a bit tricky in the context of the rest of the application. 

I think that the suggestion I posted in the previous thread should work properly by making CTR 0 re-triggerable with an initial delay.  

Alternatively, we could do a finite retriggerable counter output, but if I remember correctly there is a specific behavior with the initial delay of finite retriggerable counter outputs that might give us unexpected results (I would find the link but ni.com appears to be down at the moment). 

 

 

I won't be back in the office until next week so I don't have any hardware to try this on, but I think this should get you started down the right path for now.  The behavior you want should be achievable but it might take some clever programming to get everything to line up properly.

 

Using an external trigger or not shouldn't affect the programming of the double-pulse line which is the most difficult aspect of the application.

 

-John

John Passiak
Message 6 of 11
(7,170 Views)

Hi John,

 

That did the job. Thankyou again for your help

 

Regards

Joe

0 Kudos
Message 7 of 11
(7,150 Views)

Hi John,

 

I have been using the attached vi to control the laser as discussed n the post using a PCI 6601 for a few months now.

I have just changed to a PCI 6353 so that I can also control a heating system.

Running the same vi, I do not get the same result. The double pulse is working, so the counters seem to be communicating ok, however,

in triggering each other there is a problem.

When the main trigger channel ( which was previously the FPS but then I realised the cam trigger must go first) triggers the others, they start on the high time, then the low time (rather than the other way round which used to occur) meaning that all pulses occur at the same time.

Do you have any idea why this might be and how to solve it?

 

Regards

Joe 

0 Kudos
Message 8 of 11
(6,687 Views)

Hi Joe,

 

There was a default behavior change in X Series DAQ boards which I think might be causing the problem.  Try adding the following channel property node to your tasks:

2010-05-04_111623.png

 

On the older hardware, the "low time" is actually generated after every trigger (there is no other option).  The X Series boards default to generating "initial delay" after every trigger (which should be more intuitive in theory) but you should be able to switch to the old behavior with the above property node.

 

An alternative would be to wire the initial delay values to be equal to the low time values (this way you would also get the correct initial delay on your first cycle).

 

 

Best Regards,

John Passiak
Message 9 of 11
(6,678 Views)

Hi John,

 

This solves that problem, however, in  sorting this out, i identified another issue with my vi.

I need the start of the two pulses to start exactly at the beginning of the low time set by the auxilary counter.

However, if I try to trigger the main counter to start with the auxiliary counter or another counter, there is an error stating that you cannot both start and pause a channel...

Any thoughts?

 

Thanks again for the help

 

Kind regards

Joe 

0 Kudos
Message 10 of 11
(6,673 Views)