Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Timing the 6259 digital outputs

I want to use a line digital output on my PCIe-6259 to generate a known-width pulse about 500 times/sec max and 50-300times/sec typical using 1 line output, or those numbers divided by 8 on each of 8 output lines (application dependent). It seems like it would be easy if the on/off were the same length of time, just set a 10101010 stream to output at the given rate. Unfortunately, the pulse might occur for only 100us out of every 4ms. Is there any way to get offset timing without having to set my output frequency very high and sending giant blocks of 0's followed by giant blocks of 1's? On a larger scale of the application it seems like block moves could take an excessive amount of time.

The detailed application is as follows:

I have a rotating wheel that generates a tick every 1/4 turn. My output needs to turn the signal on when the wheels reaches a certain location, and off when it reaches another position. By interpolating between the measured pulsewidths, I was hoping for an output resolution of 1 degree or better (say pulse on for -14* through 27*) with the wheel spinning at a constant speed of up to 6500rpm, with 500-3000 more typical (engine).

Message Edited by 280Z28 on 05-23-2006 08:53 AM

0 Kudos
Message 1 of 9
(3,454 Views)

Just a couple of musings:

1. When others have posted about engine timing apps, it's typical that there'd be a angular encoder that can resolve a lot more precisely than 4 counts per rev.  Any chance you can add a higher-resolution sensor?

2. This sounds like a counter / timer application.  While an M-series board can certainly generate hw-timed DIO signals, it sounds like you would be using software in the decision loop to detect a 1/4 turn position, then counting on constant rotational speed as you determine the pulses to generate.  You'll get better timing behavior wherever you can use a counter / timer instead of software-based reactions.

3. Unfortunately, generating a long duration digital pattern with high resolution in timing will require sending the board huge blocks of 0's and 1's.  For such circumstances, I've often recommended a board put out by one of NI's "Alliance Partners".  Here's a link to the board, and if you search the forums for the words "viewpoint" and "kevin", you'll find more info from prior posts I've made.

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 9
(3,447 Views)
I'm looking at the counter output now. By setting the high time and low time for (27+14=41) "degrees" high and (in us based on my calculated speed) and (90-41=49) low, could I set 8 outputs to all use that counter, but have each one have enough 0's to be low for the cycles that shouldn't be triggered by that timer, and then a 1 for the specific pulse it's supposed to do?

With hardware timed updates to the counter high/low times and clever calculations for the number of 0's and 1's on a channel, this seems like it might be the ideal solution for my problem. I can certainly calculate the number of us between all the events combined for my output channels.

Message Edited by 280Z28 on 05-23-2006 09:54 AM

0 Kudos
Message 3 of 9
(3,442 Views)
What is RTSI0? Can I route the 10MHz sample clock to RTSI0, then use RTSI0 to time my counter output, without using both counters? I think I need one counter for input.
0 Kudos
Message 4 of 9
(3,436 Views)

I think there's reason to optimistic for your app, but I am still not understanding quite how it all fits together.

1. Re: RTSI0 and 10 MHz sample clock.  I'm not sure you need to concern yourself with any RTSI configuration.  What is the 10 MHz sample clock?   Are you referring to the maximum speed for hw-timed DIO?

2. You say you get a "tick" every 1/4 turn.  Is each tick a short pulse?  Or do you get a square wave with 4 full cycles per rev?  Or something else?

3. I would presume that you'll need to know which 1/4 turn you're in, right?   How do you plan to distinguish this?

4. The basic idea for combining counters and DIO would probably go roughly like this:

A. Determine the timing resolution you need on the 8 DIO pulses you'll generate.  More precise timing will require you to define much larger blocks of 1's and 0's.  Note that the choice you make may need to be related to the rotational speed.

B. Configure a DO task that uses the output of Counter 0 as the sampling clock.  Set it up for "Continuous Sampling."  Write your buffer of 1's and 0's to it and start it.

C. Configure Counter 0 to generate a Retriggerable Finite Pulse Train (search forums and rest of ni.com for examples) with an output frequency equal to the timing resolution you're using from step A.  The # of samples should be equal to the buffer size you defined in step B.  (Note that a finite pulse train will also use up counter 1, though you won't be configuring it explicitly).

D. Configure Counter 0 to be triggered by the correct 1/4 tick.

5. A more advanced approach might briefly use a counter to measure the frequency of the 1/4 turn ticks and automatically calculate the engine speed before continuing on with the rest of the app.

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 9
(3,427 Views)
My reference is a short square wave a few degrees wide with a falling edge 10* before each 90* mark.

With a single coil output like I have set up now, I don't need to know which pulse is the one before 0*. With multiple coils like I have in my closet but aren't hooked up yet, I will need to know, but that's fairly easy to determine through trial and error, and once you know any one point you can keep track of all the following ones by count.

I was suggesting using an uneven output from the counter to drive my DIO, like this:

output line 1: high from 11-48*, low for the rest

output line 2: high from 101-138*, low for the rest

output line 3: high from 191-228*

output line 4: high from 281-318*

Use hardware timed updates to force the counter output to go low at 11, 48, 101, 138, 191, 228, 281, and 318*

Start with all DIO in 0 state.

buffered output line1: 1 0 0 0 0 0 0 0
buffered output line2: 0 0 1 0 0 0 0 0
buffered output line3: 0 0 0 0 1 0 0 0
buffered output line4: 0 0 0 0 0 0 1 0

That gives a very small block of 0's and 1's, with as much resolution as I can give the counter output through hardware timed updates.

Edit: Of course all this assumes that I know where each degree is, but I'm not as worried about figuring that part out.

Message Edited by 280Z28 on 05-23-2006 11:21 PM

0 Kudos
Message 6 of 9
(3,420 Views)
I'm looking at the StartTrigger class in DAQmx now. I see there is a Delay property and a DelayUnits property. From my experience with the 6008 and 6009, it's pretty clear by now that not everything in DAQmx is available for each system. Do you know if these two properties are supported by a StartTrigger for the 6259 digital outputs?
0 Kudos
Message 7 of 9
(3,413 Views)
In regards to number 3 from above (buying another specialized board), I'm afraid that's out of the question. I'm just a student and I've spent this YTD working to setup a computer with the best hardware I can afford in order to work on some "neat ideas" I've had for a long, long time. When I found out my 6008 and 6009 weren't up to the task (I was unaware of their latency issues when I ordered them), I picked up the 6259 two months later. It was already wayyy outside of my "real" target price range, but if I ever want to work on this project I really didn't have much choice.
0 Kudos
Message 8 of 9
(3,408 Views)
Use hardware timed updates to force the counter output to go low at 11, 48, 101, 138, 191, 228, 281, and 318*
This is the part that's difficult to do with pure hw timing.  You need to generate clock edges at a variable rate so that the intervals alternate between 37 deg and 53 deg.  Unfortunately, counters can't be configured to do this type of operation in hardware.  It's been on my wishlist since about 1998, so I don't hold out a lot of hope anymore.
 
However, since you seem to only need 1 degree resolution, it shouldn't be too burdensome to define your digital output buffer to have 37 entries with "Bit A" high, then 53 with all low, then 37 with "Bit B" high, the 53 with all low, etc.  Then you can use a constant frequency counter output (1 pulse per degree) to generate that kind of timing.
 
 
I'm looking at the StartTrigger class in DAQmx now. I see there is a Delay property and a DelayUnits property. From my experience with the 6008 and 6009, it's pretty clear by now that not everything in DAQmx is available for each system. Do you know if these two properties are supported by a StartTrigger for the 6259 digital outputs?
No I don't know for sure about that.  The counter pulsetrain can be triggered though and has an available property called "initial delay" which should help provide the functionality it sounds like you need.  Also, when it comes to syntax, I'm solely a LabVIEW guy.  Your reference to the StartTrigger "class" makes me think you're using an object-oriented text-based language to make direct calls to the DAQmx dll's.  I'm afraid I'm of no help in those details.
 
-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 9
(3,400 Views)