Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

2 finite pulse generation by a counter triggered by one counter

Solved!
Go to solution

Hi guys,

I am using NI USB-X 6353 and 6343 for a test system. I need two sequential pulses from a counter after triggering it with another counter on the same board. I would like to start the trigger counter once and then generate 2 sequential signals from other counter on the same board. I tried to explain it on a graph below. I am able to generate one counter signal after the first one, however, I need one more without starting the first counter again. Is it possible to do it with these devices? I also added a code that I was using to generate just one counter after triggering other one without any problem. Is it possible to modify this code to work in this manner as I explained? Thanks in advance guys.

explanation.png

 

 

 

Egemen
0 Kudos
Message 1 of 8
(3,752 Views)

I'm still on LV 2016 and can't open your code unless you backsave to an earlier version...

 

Your timing diagram seems feasible with a retriggerable finite pulse train.

 

1. Configure a finite pulse train to generate 2 pulses.  Define the high and low times as needed.  (By eye, if your sketch is to scale you might want roughly 24 msec high time, 16 msec low time.)

2. Configure the "initial delay" parameter for 100 msec.

3. Configure it to use the rising edge of your blue pulse signal as a Start Trigger.

4. Configure the Start Trigger to be retriggerable

5. Configure the channel to keep using the "initial delay" parameter on retriggers.  (The default behavior is to use it only on the very first trigger as described here.)

 

That oughta do it.  Here's an example that illustrates this stuff.

 

 

-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).
Message 2 of 8
(3,706 Views)

Hi Kevin,

Thank you very much for your reply. I added the previous version of VI, you can open it via LV 2016. This vi generates only one signal after it is triggered. In this VI, I use "CO Pulse Time" to generate this signal. I think I have to use "CO Pulse Freq" mode to generate 2 signals as I explained previously. I was trying to get it via pulse time function...

So I use "CO Pulse Time" for the first trigger signal, blue one, and I need to use "CO Pulse Frequency" for 2 finite signals, red ones. To configure it right, I think I set the frequency 25 Hz (fre=1/period -> fre=1/0.04=25, 40 ms between two peaks) and I want 1 ms for high time for both signals. To configure it, I have to change the duty cycle. So, it is 1/40=2.5%. Am I right on these calculations? I am not sure that I get 2 peak signals with this configuration. I added the modified VI also. Thanks again 🙂

Egemen
Download All
0 Kudos
Message 3 of 8
(3,703 Views)

I tried to modify the VI as you suggested previously and attached it. Do I understand your suggestion correctly? Could you check it please? 

Egemen
0 Kudos
Message 4 of 8
(3,692 Views)
Solution
Accepted by topic author newbieeng

The latest v4 code looks like a correct interpretation of the steps I outlined for the "INJ" task.

 

I didn't try to confirm calcs for time parameters (low time, high time, init delay) on either pulse task.

 

The "IGN" task might need a little tweak.

1. If you want just 1 pulse, the way you get it is by not calling DAQmx Timing at all.  Just leave it out.

2. If you want more than 1 pulse, you need to wire in the correct number.

3. Either way, after you start the task you should call DAQmx Wait Until Done *before* you stop the task.  Otherwise you risk stopping it too soon.

 

The AI triggering looks sensible, sharing the same trigger as the INJ counter task.  The AI loop looks nice and lean, good use of the queue to offload further processing work and prevent the DAQ task from lagging and possibly overflowing its buffer.

 

I didn't really investigate the PCV and VCV counter tasks.  They appear free running and unsynced to the other 2.  Hopefully that's intentional.

 

 

 

-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 8
(3,687 Views)

The calculations that I asked are just for the previous "Modified VI", not important in the v4 code. In the code v4, the PCV and VCV counter tasks are left unsynchronized intentionally. You are right about adding a "DAQmx wait until" function to assure its timing. Actually, I added the trigger option for AI task just in case, normally, I am not using. You are right about getting one signal does not require a sample clock as I am using it in my very first VI before opening this thread.

I added sample clock the INJ task like in the examples that you suggested. For the code, I have doubt about getting 2 finite signals from INJ task. If I set the number of sample 2 for INJ task clock, will I get 2 pulses?

Thank you very much.

Egemen
0 Kudos
Message 6 of 8
(3,682 Views)

(going by memory b/c I'm not at a LV machine to look at code now)

 

2 pulses: yeah, calling DAQmx Timing for a pulse generation task and wiring in "2" and "Finite Samples" will make the task generate exactly 2 pulses, no more no less.

 

Note: older boards before the X-series that you're using would have needed to "secretly" use a 2nd counter to manage finite pulse train generation.  Just letting you know in case you try to run the code on a different board and get unexpected errors.

 

 

-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 7 of 8
(3,677 Views)

Thank you very much Kevin 🙂

Egemen
0 Kudos
Message 8 of 8
(3,670 Views)