LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Digital Out Sample Clock Sources

Hey guys,

I am putting together an application <attached>.

Currently I have the ai/sampleclock wired to its timing VI.  When I run this with highlighting on, it just goes to the read for the digital in task and waits there like it has not yet acquired enough samples.  Am I right in thinking that this should result in an array of integers 2000 elements long with 1's where the line is high and 0's where the line is low?

When I swapped the clock source to being di/sampleclock I get something about my device not supporting it.

This is my first adventure into digital in, anybody have a quick hint?

Thanks,
~milq

p.s. LV 8.2 - PCI 6289 🙂
0 Kudos
Message 1 of 10
(3,064 Views)
Do I use a "Pipelined Sample Clock"?

~milq
0 Kudos
Message 2 of 10
(3,065 Views)
I am an idiot, I meant Digital In, ugh, long week.

*bumpity bump*
0 Kudos
Message 3 of 10
(3,057 Views)

Hi again.  While the M-series boards can do hardware-timed buffered digital input acquisition, there is no internal clock that can be directly assigned as a DI sample clock.  The sample clock either needs to be generated by one of the on-board counters, *shared from an AI or AO task, or wired from an external clock source.

Other tidbit: in your loop, both DAQmx Read calls request -1 samples, meaning "read all available samples."  Since the calls happen in sequence, there's no guarantee that they will have the same # available.  A better idea, IMO, is to set your 1st call to "read all available" then request your 2nd call to read a number == the size of the 1st call's output array.

-Kevin P.

"share from" -- a nice way to phrase freeloading, as in, "Here, let me share some fries from you..."

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 4 of 10
(3,050 Views)
Hey Kevin,

1: My "-1"s are hooked up to my timeouts, not my "samples to read" (silly Kevin 😉 )

2: When I tried to hook up my sample clocks to ai/sample clock the DI just sat there and waited (as if it was not receiving any clock signal).  My counter input seems to be ok with using the ai/sampleclock.  I was hoping I could use it on the DI too.  When you say that I need to share it, are you implying that I have to create another task (AI) just to validate the clock's existance and share it from there (despite the fact that I do not need any AI for this app)?

3: I want to try an avoid using another counter as that will force me to go from X4 on my encoder to X1 (lack of resolution makes milq a sad panda).

4: I am using the speed control as a way to keep one "cycle" of data on the chart at all times.  (engine remember?)  This is the best way I can think to do it, since LV is not accepting the noise coming from my encoders as a valid clock source.  Right now, I input the speed in RPM and it dictates the number of samples I need to read at this freq to get one cycle of data.

5: The point of the DI is to see the encoder as it sweeps by so I can determine where in the cycle the data cooresponds to.  I am half inclined to just make it an AI at this point, that seems silly but it might avoid the clock problem and I should see high vs low just the same.

Any thoughts?
~milq
0 Kudos
Message 5 of 10
(3,042 Views)
Hi Milqman,

With regards to using the AI sample clock, if you do not have an ai task running then there is no AI sample clock for the DI to see.  Normally I would recommend using a counter to clock your DI, but if are already using the counters, then you could create an AI task, for the purpose of sharing its clock with the DI task.  You don't have to have an AI signal you care about, but starting the task and reading from it as long as you want to do the DI will allow the AI sample clock to be used by the DI  task.  Let me know if you need any further information about how to provide timing for your DI task.

Have a great day,

Michael D
Applications Engineering
National Instruments
0 Kudos
Message 6 of 10
(3,039 Views)
I think I am just going to turn the DI into an AI.  It will unnecessarily employ the use of the A/D but a voltage is a voltage and I am just looking for the presence of a pulse, not it's size, shape, period, duty cycle, or birthday.

Thanks for the help,
~milq

Is there somewhere I can find a DAQmx manual, knowing which polymorphic VIs play nice together would be great to know BEFORE I get errors.
0 Kudos
Message 7 of 10
(3,038 Views)
I made a bunch of mods to the file, then realized way too late that I probably made several wrong assumptions.  Smiley Sad

Hate to let it all go completely to waste though -- maybe some of it will prove useful sometime?  Here's the stuff I did:

1. Created AI task solely for purpose of sharing its sampling clock for the encoder sampling.

2. Instead of acquiring a digital pulse, I used it as an "arm start" trigger for the encoder task.  (I was still thinking about your earlier app where you wanted to sync up to the encoder's z-index).  So encoder measurements start from 0 degrees when this edge occurs.

3. Acquisition data is written to a queue.  It now reads about 1/2 second at a time (15 revs).

4. File storage and display are put into an independent loop that's fed by the queue.  Some searching is done on the position data so that only the most recent full rev is displayed.  However, ALL data is stored to file for future examination.

5. About that time I looked at the front panel more, and based on graph axis label of "angle of deviation", I started doubting that my earlier assumptions were relevant.  Anyway, FWIW, I've attached what I did.  Some of the stuff (like using a queue to separate file writes from data acq) should at least be good reference.

-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 8 of 10
(3,026 Views)
Thanks Kevin!

You can see the round about way that I did my file saving/queuing.  The method does not seem to slow anything down, which is cool, but yeah, I am pretty clear on the fact that it is not the best way to do it.  I had considered the arm start, but I opted against it because of the nature of the data I am taking (this is not one encoder, it is two and their quadrature is subtracted).  The index from the first line still comes through, but the comparative position of the two encoders is not necessarily an absolute so it does me little good.

I will scope out your VI here (and of course cannibalize the stuff I like).  I appreciate the time and effort you put in to help me, thanks!

~milq

P.S. Did you get the audacity thing to work?
0 Kudos
Message 9 of 10
(3,017 Views)

First - how are you doing a difference of 2 quad encoders?  Are you taking the A channel from each of 2 different encoders running at the same nominal pulse rate?  I'm away from my LV PC and can't go back and look now.  I've done that kind of thing before, where you configure for up/down counting and you get a measure of relative lead and lag. 

Second - all the stuff I did was at home while procrastinating and is fully untested.  Don't trust it to do what I said it should without testing.

Third - does it make sense to save data continuously like I tried to do for you?  I've developed a rule of thumb that says, "when in doubt, store to file and defer the decision-making."  The reason I goofed with the # of samples acquired & displayed was that I pictured you updating a graph representing <something> through exactly 1 engine cycle.  Seemed like updating it a couple times a second would be enough. 

Since this is your thread and you asked, here's the scoop on Audacity:  I actually grunted through that stuff several months back.  I probably did use the envelope tool, but I think I ended up applying it piecewise in several little pieces through the fade region.  I couldn't make the envelope curves apply just the right shape to keep the volume constant across the fade.

It was interesting in a weird way.  I'd have thought going in that nothing could be easier to mix imperceptibly than noise.  It turned out that the clicks you get with no fade and the volume artifacts coming from linear fade make noise especially *difficult* to mix.

At some stage I think I mixed in some pure noise and then applied some filtering to cut out high freq hiss.  I also added some low freq amplitude modulation and some low freq Left<-->Right panning.  In the order of <0.1 Hz, with the two effects at frequencies without common multiples.  Overall the effect isn't very noticeable (especially the panning on a boombox), but I think the slight variation works better than 100% solid repetition.  Anyway, they were effects sitting there in Audacity and I figured they'd be fun to goof with.

Finally, a couple months after the first cd I found an old "Nature Sounds" tape of crashing waves on a beach.  So I mixed that in with the original cd to make a version 2.  The nightly scoreboard is now Fans - 2, Boomboxes - 2.  I'm getting there... Smiley Wink

-Kevin P.

Edit: put back a sentence I accidentally deleted

Message Edited by Kevin Price on 03-30-2007 03:16 PM

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 10 of 10
(3,013 Views)