Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

simultaneously generation and measurement of pulse

Solved!
Go to solution

hello every one,

i am generating a pulse for specific time.Now I want to measure it within same daq card.I have made Vi for it but it has some error.I have USB daq-6343.I am attaching my Vi here.

The problem is i am able to get generated pulse on PFI 6 pin but reading Vi is showing Time out error.

I have connected wire between PFI 1 pin and PFI 6 pin on DAQ card.

So plz suggest me what to do for eliminating this errors.

 

thanks & regards,

0 Kudos
Message 1 of 6
(5,218 Views)

hello folks,

I think i have solved this problem.I am uploading my Vi here.If someone has any suggestions regarding more improve method plz tell me.

I am wondering that weather it is right or wrong to use delay method which i have used here.

0 Kudos
Message 2 of 6
(5,212 Views)

generate and measure pulse.png

The delay method doesn't make a lot of sense to me.  All the config steps leading up to the delay will produce their own indeterminate delay that's likely of the same order of magnitude.   If you have precise timing requirements, this approach isn't gonna cut it.  If you don't, the 7 msec delay serves little purpose.  (Perhaps the original purpose was to let the pulse measurement task get started before the pulse was generated.  The sequencing I added in the snippet below is a better way to enforce the functional sequence.)

 

Below is a snippet of some quick mods I made with a couple brief comments:

 

 

-Kevin P

 

 

P.S.  For unknown reasons, my attempts to embed a png snippet are being ignored.  I'm including it as an attachement instead.  It should still act like a snippet if you drag the file into a blank block diagram. 

 

 

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 3 of 6
(5,192 Views)

hello Kevin_Price,

thanks for replying and giving nice code with comments.right now i am not able to test this code,but when i do i will post its results here.

Now i have added this delay because initially as i posted earlier it gave error that it is not receiving any error.So possible plz give sme brief about it.And i like to ask you why u have suggested that DON"T use Timing Vi....

 

thanks....

0 Kudos
Message 4 of 6
(5,183 Views)
Solution
Accepted by topic author d_2014

I just looked at your original vi, I had only looked at the later (corrected) one previously.  I don't immediately see a good reason for the read timeout error you were having.  Registering a timeout error at your attempted read suggests that code had executed without error up to that point, including the start of pulse generation.  That would leave me to wonder about the physical wire connection or possibly some undesired side effects from your cleanup code where you tri-state one of the PFI lines.

 

Your other question was about my suggestion to leave DAQmx Timing.vi out of the config chain entirely for cases like this where you only want to generate a single pulse.  To be honest, it's a habit & practice I adopted many many years ago.  I thought one of the reasons was that Finite pulse trains required a minimum of 2 samples.  A little bit of test code showed me that's not actually true, though my memory tells me there was a time when it *used* to be true.  I don't recall whether I got errors or whether the task chose to generate 2 pulses with just a warning or something.  I just remember that while working on a module that was supposed to be able to generate any # of pulses from 1 to N I found that I wasn't actually able to support the 1 pulse case by simply requesting 1 sample in Finite sampling mode.

 

*Anyway*, the other reason to avoid Finite sampling mode for a single pulse is that in the past, this would actually consume 2 counters on DAQ boards.  One generated the pulse(s) while the other was a helper that gated the first to control the # of pulses generated.  This was wasteful because you could *also* generate a single pulse by leaving the DAQmx Timing.vi out of the config, a method that only used 1 of the counters.

 

X-series boards (like yours) no longer consume 2 user programmable counters to generate finite pulse trains, so the lesson I learned long ago and tried to pass along is maybe not so crucial in your case.  I'd still recommend it if you know you'll always be generating a single pulse, just because it's considered the standard way to generate a single pulse (as seen in shipping examples).

 

 

-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 6
(5,173 Views)

hello again,

thanks for wonderful information.I have just started work on LV and DAQ few months before.So it would be very helpfull.

i have a little request for you Kevin_Price... could you upload your Vi agian for LV10..?

 

thanks in advance..

0 Kudos
Message 6 of 6
(5,140 Views)