LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

synchronized pulsegeneration

Solved!
Go to solution

Hi All,

Please refer the VI snippet – I am using PXIe-6358 on PXIe-1082 chassis to generate two synchronised pulses. First pulse is continuous and falling edge of that is a re-triggerable start, for second pulse train which outputs 360 pulses per first pulse. Falling edge of the two signals are in synch.

My next goal is to vary the frequency at run-time. I have managed to get first pulse frequency changed but labVIEW alerts an error as the second pulse is set to finite samples on timing. This restricts me to continuously generate two pulse trains while giving the flexibility to change frequency on the fly.

I really appreciate if someone can help with some tips to overcome this barrier.

Many thanks in advance  

0 Kudos
Message 1 of 5
(2,855 Views)

What comes to mind isn't exactly simple and will be constrained in that it will support only discrete frequency steps.

 

The essence of it is to add a 3rd continuous pulse train counter that serves as a timebase for the 2nd counter that's doing a retriggerable finite pulse train.  Let's start with something like maybe 1 MHz -- using a power of 10 makes some of the calcs a little easier to think about.  Define the pulse train in terms of Ticks of the 3rd counter's output instead of Seconds (calculated from the known internal clock).

 

Here, instead of a 0.001 sec low time and high time, you'd have 1000 Ticks for both low and high ticks.   You're allowed to change the freq of the 3rd counter on-the-fly and when you do, the 2nd counter will naturally follow. 

 

The catch is that when the 3rd counter is at 1 MHz, it's internally using 50 high and low ticks off the internal 100 MHz timebase.  The smallest available adjustment will be to use 49 or 51 ticks instead, representing a 2% incremental change.  If that's too big a step size, let's consider setting the 3rd counter at 100 kHz.  Now you'll have counter 3 using 500 ticks low and high and a change by 1 is only a 0.2% change.  Better.

 

It may turn out that your 1st counter should also use this variable freq 3rd counter as its own timebase, I'm not sure I know your timing requirements enough to say one way or the other.  Maintaining sync between 1st and 2nd as 3rd varies will likely require both 1st and 2nd to use the 3rd as timebase, and both 1st and 2nd should be defined in units of Ticks.

 

 

-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 5
(2,833 Views)

Hi Kevin,

Many thanks for your tip.

With further investigation what I found was, changing parameters of a Finite pulse output task is impossible. It has to be stopped and start again.

 

In fact, I am already using a 3rd counter which is internal timebase of 100kHz. The challenge here is to generate exactly 360 pulses at slave counter between 2 falling edges of the master pulse.

Basically, to generate pulse train as shown below.

Intended_Pulse train.PNG

0 Kudos
Message 3 of 5
(2,819 Views)
Solution
Accepted by topic author London

Correct, you can't change the specs of the finite pulse train on your 2nd counter on-the-fly.  The purpose of the 3rd counter at 100 kHz is that you *can* change its freq on-the-fly, which would then *result* in changing the timing of the 2nd counter's pulse train in hardware rather than via programming, where it isn't allowed.

 

To keep 1st and 2nd counter synced, you *will* need both the 1st and 2nd counters to use the 3rd counter as a timebase and define their pulse specs in units of Ticks.  The 1st counter should have specs for low and high ticks such that their sum is 360 * (the sum of low and high ticks on the 2nd counter).   Once you get this set up right, you don't need the 2nd counter to be a retriggerable finite pulse train.  Now it can be a once-triggerable continuous pulse train.   Because the 1st and 2nd counters will derive their timing from the same timebase, you only need to get them synced at the start and they'll maintain hardware-timed sync as long as you want after that.   And because the timebase is a counter whose freq you can control on-the-fly, you can vary the simulated rotation speed any way you want and know that the 1st and 2nd counters will stay locked in sync.

 

 

 

-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 4 of 5
(2,804 Views)

Many thanks for your tips. that method works for me

0 Kudos
Message 5 of 5
(2,794 Views)