05-23-2006 08:53 AM - edited 05-23-2006 08:53 AM
Message Edited by 280Z28 on 05-23-2006 08:53 AM
05-23-2006 09:24 AM
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.
05-23-2006 09:51 AM - edited 05-23-2006 09:51 AM
Message Edited by 280Z28 on 05-23-2006 09:54 AM
05-23-2006 10:18 AM
05-23-2006 04:41 PM
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.
05-23-2006 11:20 PM - edited 05-23-2006 11:20 PM
Message Edited by 280Z28 on 05-23-2006 11:21 PM
05-24-2006 12:27 AM
05-24-2006 09:34 AM
05-24-2006 11:15 AM
Use hardware timed updates to force the counter output to go low at 11, 48, 101, 138, 191, 228, 281, and 318*
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?