Retriggerable pulse task

Hi all.
I am looking for this file.
1. Retriggerable Pulse Task
2. SCXI Analog Input Task
For your information, I was given a task to do some enhancement for my project.
However, I can't these two sub.vi from the file neither in the example.
The original program was programmed using LabVIEW 7.1. However, I am now using LabVIEW 8.6.
Those who has / found these two files, kindly share it here.
Thank you!
with regards,
Fird

Hi Fird,
I don't think the 2 VIs you are looking for are in-built NI VIs.
Do you have the old codes in LabVIEW 7.1? You should be able to open them in LabVIEW 8.6 without any problems. Or are these 2 VIs missing from the LabVIEW 7.1 codes too?
I have searched for these 2 file names in my LabVIEW 7.1 (with both the DAQmx and Traditional DAQ driver installed) and they cannot be found so I'm pretty sure they are customized subVIs, not NI shipping examples.
Regards,
Boon Chen

Similar Messages

Two retriggerable pulse generations after a pulse train generation

I am trying to generate 3 pulse trains (ABCABCABC...) one after another.
The program currently I am using generates 2 pulse trains (ABABAB.....).
I am using the Traditional NI-DAQ and PCI-6602.
I am thinking about using pulse train generation first and then retriggerable pulse generation after that.
I understand that the retriggerable pulse generation can generate a pulse train triggered (or gated) by other counter output.
I have attached a test vi.
It uses the pulse train generation code when the counter number is 0 and when the counter number is not 0, then it uses the retriggerable pulse generation code, which I tried to modify from the pulse train generation code.
First of all, I am not sure if I wrote the retriggerable pulse generation code correctly.
Secondly, I don't know if the whole code will generate ABCABCABC...
I would really appreciate your help.
pchemjjang

pchemjjang,
I believe I may have misunderstood your original concern. It sounds like you want to output this finite pulse train on three different counters. You will output these pulse trains for 10 minutes and cease your program. The Finite Pulse Train.vi will output a pulse train from only one counter. With this Traditional DAQ example you would need to have three of these Finite Pulse Train.vi programs running simultaneously in parallel to output from 3 counters. I would strongly recommend using DAQmx for this application because you will only need to utilize 4 VIs. The rest of the work is done behind the scenes. There is an example in DAQmx which should accomplish exactly what you are looking for in one program. You must make sure to make the number of pulses 2000000, the duty cycle as 1/3 and the frequency as 1/(300us). The DAQmx driver can found here. In terms of the counters, I believe that each task requiring two counters will use the counter adjacent to it. If you would like to output on counter 0 using finite generation then counter 1 will be used as the gating counter. When you have the DAQmx driver then you can find this example by selecting Help>>Find Examples and then expanding Hardware Input and Output>>DAQmx>>Generating Digital Pulses>>Gen Dig Pulse Train-Finite.vi. I have included an image to show how the front panel of this example should be configured to work. The major note to make is that you will need to configure all of the counters in the channel names list. In Traditional DAQ this did not seem possible. In Traditional DAQ you would need to create a subvi out of the Finite Pulse Train.vi run three copies of it, in parallel, in a larger program. Please let me know if you will be able to utilize DAQmx in this application.
Thanks,
Gio L.
Digital Support - Product Manager
National Instruments
Attachments:
Counteroutput.jpg ‏49 KB

Define the number of single retriggerable pulses

Hi everybody!
I generate single retriggerable pulses using a PCI-6602 and BNC-2121 Box (sent to my spectrometer) for my data aquisition.
For every trigger signal one spectra is aquired by our spec. It is very important to have a defined number of spectra, therefore I have to define the number of pulses in a retriggerable single pulse task.
Unfortunatly it isn't possible to use a pulse train instead because the jitter of my source is to high so that each pulse has to be retriggered.
Is there a way to do this?
Thank you very much for your help!

Hi Konradeo,
it is a little bit difficult to understand, what du you want to accomplish. It would much more easier for me and the other forum user, if you could provide use your LabVIEW-Code and a sketch, what du you want to output with your PCI-6602.

How to generate a delayed retriggerable pulse using only one counter with PXI 6070E card

Hi
I have a problem in generating a retriggerable delayed pulse with a single counter(triggered through a signal at gate) using PXI 6070E card. VI was developed in NI LabVIEW traditional DAQ Ver.7.1. I have used the "delayed pulse generator config" VI and a "Start counter" & "Stop counter" VIs for the purpose. But there is no output seen at the out terminal of counter. So I introduced a "wait" VI and set it to 1 sec. Now the pulse output appears but some pulses are missing mometarily after every 1 sec interval. (any solution for this)
I have gone through a few similar requests in the forum but they suggest either to use two counters or to generate a finite pulse train which does'nt fit my application. Moreover PXI 6070E has only 2 counter timers. I am already using one counter to measure the frequency of a pulse train(signal 1). The application requires to generate a delayed retriggerable pulse for every pulse in signal 1. So I have only one counter left.
Can I measure the frequency of signal 1 by analog means.? so that I can use two counters for pulse generation. (Signal 1 is a TTL signal).
Request some help.
Thanks in Advance
Regards

A finite pulse train (N_Pulses >= 2) does require the use of 2 counters on most of our older hardware including your 6070E. If you're just talking about generating a single retriggerable pulse, you would only need one counter.
Here's an example in Traditional DAQ that shows you how to set a retriggerable pulse generation (it also allows you to adjust the characteristics of the pulse on-the-fly).
If you're writing a new program, you might consider switching to DAQmx as it supports NI's latest hardware and recent OSes should you ever need to upgrade. Traditional NI DAQ is no longer in active development. Here's an example of how to implement a retriggerable pulse generation in DAQmx. You should take note that you can't use the two drivers to simultaneously talk to the same piece of hardware, although you should be able to go back and forth by resetting the Traditional DAQ driver before switching to DAQmx.
Best Regards,
John Passiak

Deterministic updating of retriggerable pulses, part 2.

Re: Question posted by Vern on 6/27/01 on ?Deterministic updating of retriggerable pulses?.
I?m using LABVIEW in a very similar application to Vern, namely fuel injection control of an engine. I've managed to combine the Pulse Width Modulation VI and Retriggerable Pulse Generation VI, such that a pulse is generated on each occurrence of a pulse at the counter?s gate (which comes from an encoder on the engine). However, the VI executes only once, and the gives ?Error ?10609 occurred at Counter Control?, which is called a ?transferInProgError?. The only way to change the pulse width is to restart the VI, which runs once and then gives the same error. I am using a PCI-6071E DAQ board. Why is this happening?

That is precisely what I tried, prior to posting my question here. I still get the "10609 transfer in progress error".
For testing of the VIs, I am using an electric motor to drive my encoder, whose pulses are routed to the gate pin of a counter. The pulses come every 24msec, and I've set my phase 1 to 1msec (delay), and my phase 2 to be 5msec (pulse). I've modified the sub-vi "calculate pulse specs" found in the PWM vi to accept phase 1 and 2 time duration directly, rather than frequency and duty-cycle inputs.
As you can see, the pulse generation (6msec total) should be finished by the time the new gate pulse arrives. Therefore, switching cycles while a pulse is in progress should not be a problem.
The oscilloscope shows a 5msec h
igh pulse, followed by a 19msec low pulse. The low pulse becomes longer if the motor speed is decreased slightly, proving that the operation is gated. The VI runs once, and as long as the motor is driving the encoder, the pulses appear. However, their duration cannot be changed without re-starting the vi.
I'm attaching the relevant VIs for reference.
Thank you for your help Geneva.
Regards,
John
Attachments:
Pulse_Width_Modulator2.vi ‏129 KB
New_Calculate_Pulse_Specs.vi ‏102 KB

PXI 6602 - Retriggerable Finite Pulse Train Generation

Hi,
I have a VI in LV7.1 where I configure PXI 6602 to generate finite pulses whenever a trigger is received. And the Retriggerable Property is set to TRUE. I look for the task to complete in order to proceed with the other operations.. This actually works. As soon as the pulses are generated DAQmx Task Done becomes TRUE.
The same VI I upgraded to LV 2011but this time the 'DAQmx Task Done?' never becomes TRUE even after the trigger is received and pulses are generated.
Does anyone know if the 'DAQmx Task Done?' functionality is changed in higher version of LabVIEW so that it no more works as it was in LV 7.1?
Is yes, then do you know what property to use to know that the operation is done?
Any help is highly appreciated.
Thanks.

CORRECTION TO PREVIOUS POSTING THERE WAS AN ERROR IN HOW I DESCRIBED THE PROBLEM:
I have a problem using a retriggerable finite pulse train as in the NI example Retriggerable_Finite_Pulse_Train. I use ACTOUT to gate the first re-triggerable pulse control and the second pulse control generates the continuous pulse train which is gated by the first retriggerable pulse control. The ACTOUT signal is generated by an AI control which senses a crank trigger (Hall Sensor). The re-triggerable pulse train is used to modulate a fuel injector in sync with ignition timing and RPM. If the period of the ACTOUT signal changes due to a change in RPM, the pulse train is recalculated. It works OK with one hitch. Even at constant RPM, after about 15 re-triggerer pulse trains the final pulse of the train does not complete. This leaves the signal high in-between successive re-triggerer pulse trains. This incorrect high signal between re-triggerer pulse trains means that the fuel injector is incorrectly left on in-between pulse trains. This incorrect high signal goes on for about 10 pulse train events and then returns to normal. This pattern repeats. I use the ActualPeriod of the second control's continuous pulse train to ensure the pulse train ends correctly within window of the first re-triggerable pulse. This work but with time this pulse train seem to shift slightly. Is there another way to create a different type of re-triggerable pulse train that overcomes this problem?

Retriggerable gated counter or analog pulse trains

Hi all,
I have a problem I could not resolve in the last days. It might be even a question of creativity of how to come up with a solution.
I have an external pulse train 1 at ca. 8 kHz (frequency not fully stable). With this pulse train, I want to trigger with each pulse an analog waveform. Using X-series boards, this works perfectly.
But now I want to gate this analog signal with another pulse train 2 that is much slower than the other one (pausetrig option). Theoretically, this works nicely, too. But in reality, the analog signal simply ends at the point where it is stopped by the pause trigger, whereas I want it to stop at the end point of the waveform.
Please have a look at the drawing attached
I would be really glad about any ideas on how to solve this problem.
Best regards,
Peter

I don't think I've ever defined both a start trigger and a pause trigger defined for the same task. Good to know it's allowed.
Given what you've already found, the solution is to control the timing of the end of the pause trigger pulse's active state (shown here as high).
Here's one approach:
1. Create the pause trigger pulse with a retriggerable single pulse task. Use a minimal "low time" and "initial delay". Set the high (active) time to be approximately (N+1) periods of your AO sample clock.  Technically, N+1 periods is a bit more than necessary, but it's sure to be enough and doesn't require research into deep details of AO timing.
2. Configure the AO task to use the pulse as *both* its start trigger (rising edge) and its pause trigger (pause when low).
Comments: this makes for a different timing diagram than you've drawn. Each external 8 kHz pulse causes a minimally-delayed pause trigger pulse which lasts long enough to generate the full AO waveform but ends before the next 8 kHz pulse. The choice of when to start and stop this trigger pulse will be up to your own logic and will be governed by software timing.
   Oh dang! That still leaves you susceptible to a partial waveform since you can't sync the software timing to occur during the desired small fraction of the 8 kHz interval with no AO waveform.
Second approach:
1. Similar to #1 above, but set the high (active) time to cover multiple 8 kHz periods and *don't* make the task retriggerable. To get the timing right in hardware, you'll need to generate a pulse that's *approximately* the requested length, but you'll reserve the right to tweak it so the edges fall in the right place.   You'll also define your pulse in terms of the external 8 kHz signal rather than in terms of internal board time.
     Specifically, configure to generate a pulse based on units of "Ticks" using the rising edges of the external 8 kHz signal as the "source of ticks." Set a minimal value (probably 2) for both the "low ticks" and "initial delay" inputs. The "high ticks" setting is where you do your tweaking.
    Suppose the desired pause trigger time is 10.3 msec. Nominally, that's 82.4 intervals of the 8 kHz external signal. Well, just round up or down as you see fit and wire this integer # into the "high ticks" input.
2. AO task is configured to retrigger off the external 8 kHz signal and be pause triggered by #1's counter pulse.
Comments: When you start the pause trigger pulse task, it will remain in its low idle state for the first two 8 kHz pulses. It will go high on the 3rd pulse and then revert low on the 82nd subsequent pulse.
   Because this pulse *also* acts as a pause trigger for the AO task, you're now synced such that the AO task is paused exactly as it is being retriggered, meaning that the previous waveform must have been allowed to complete. (The deep details of timing will prevent the AO task from generating 1 sample at this instant.)
-Kevin P

Retriggerable finite pulse train

I have a problem using a retriggerable finite pulse train as in the NI example Retriggerable_Finite_Pulse_Train. I use ACTOUT to gate the first re-triggerable pulse control and the second pulse control generates the continueous pulse train which is gated by the first retriggerable pulse control. The ACTOUT signal is generated by an AI control which senses a crank trigger (Hall Sensor). The re-triggerable pulse train is used to modulate a fuel injector in sync with ignition timing and RPM. If the period of the ACTOUT signal changes due to a change in RPM, the pulse train is recalculated. It works OK with one hitch. Even at constant RPM, after about 15 re-triggerer pulse trains the final pulse of the train does not complete. This leaves the signal high in-between successive re-triggerer pulse trains. This incorrect high signal between re-triggerer pulse trains means that the fuel injector is incorrectly left on between pulse trains, when it should be turned off. This incorrect high signal goes on for about 10 pulse train events and then returns to normal. I use the ActualPeriod of the first re-triggerable pulse to ensure the pulse train ends correctly within window of the first re-triggerable pulse, but it seem to wander. Is there another way to create a different type of re-triggerable pulse train that overcomes this problem. I may have to use a single re-triggerable pulse instead of a re-triggerable pulse train as this work correctly every time. However, multiple pulses creates a finer mist from a fuel injector and is the correct why to modulate a fuel injector. The

CORRECTION TO PREVIOUS POSTING THERE WAS AN ERROR IN HOW I DESCRIBED THE PROBLEM:
I have a problem using a retriggerable finite pulse train as in the NI example Retriggerable_Finite_Pulse_Train. I use ACTOUT to gate the first re-triggerable pulse control and the second pulse control generates the continuous pulse train which is gated by the first retriggerable pulse control. The ACTOUT signal is generated by an AI control which senses a crank trigger (Hall Sensor). The re-triggerable pulse train is used to modulate a fuel injector in sync with ignition timing and RPM. If the period of the ACTOUT signal changes due to a change in RPM, the pulse train is recalculated. It works OK with one hitch. Even at constant RPM, after about 15 re-triggerer pulse trains the final pulse of the train does not complete. This leaves the signal high in-between successive re-triggerer pulse trains. This incorrect high signal between re-triggerer pulse trains means that the fuel injector is incorrectly left on in-between pulse trains. This incorrect high signal goes on for about 10 pulse train events and then returns to normal. This pattern repeats. I use the ActualPeriod of the second control's continuous pulse train to ensure the pulse train ends correctly within window of the first re-triggerable pulse. This work but with time this pulse train seem to shift slightly. Is there another way to create a different type of re-triggerable pulse train that overcomes this problem?

Pulse train generation fails with certain values for "number of samples"

I'm generating a retriggerable analog output signal, and so I'm using a counter as the sample clock (see: Retriggerable AI Using Retriggerable Counter). I am finding that, above a certain number of samples, and only for certain values of the number of samples, the counter task gives me error -200305, "Desired finite pulse train generation is not possibe." The error crops up only when actually starting the task.
The analog signal that I'm trying to generate will be about 800 kHz, so my counter is set to run at the same frequency. I find that the counter task works fine if the number of samples to generate is anywhere between zero and 671,088 samples. Setting the number of samples to 671,089 gives the error above, as does 671,090 samples and so on. However, using 671,096, the counter task works fine. After that, the counter seems to output fine only if the number of samples is divisible by 8.
The only thing I can think of is that (617088 samples) / (800000 Hz) = 0.839 s. At the internal clock rate of 20 MHz, 0.839 s is 2^24 samples, and it is a 24-bit counter on this hardware. So if it's this internal counter rolling over, that's fine and I can work around that. But if that's the case, what I don't understand is why increasing the number of samples in increments of 8 samples still works.
The hardware is a PXI-6733 board, running with LabView 7.1.1 and NI-DAQmx 8.1.

Hmmm, multiples of 50 & 100? Now I'm puzzled again.
Here's how to make sense of the 100 kHz timebase idea though, even if it turns out not to be the right explanation. For a retriggerable finite pulse train, you actually use a pair of counters. If you were to program it manually, you could set your output counter to generate a continuous pulsetrain at 800 kHz using the internal 20 MHz timebase. This output counter would also be configured to use the other counter's output as a digital level-based pause trigger. So the 800 kHz pulsetrain is only output while the other counter's output is, say, high.
The other counter is configured for retriggerable pulse generation. The pulse duration or high time should be set for (# pulses) / (800e3 pulses/sec). This other counter can be configured to use the 100 kHz timebase, so its high time would then have to be an integer multiple of 10 usec.
So let's see... An 800 kHz pulsetrain is possible with a 20 MHz timebase (exactly 25 cycles). A 700 kHz (28 + 4/7 cycles) or 900 kHz (22 + 2/9 cycles) is not. So when you request those other frequencies, you actually get a near approximation. I dunno if DAQmx can be queried for the actual value correctly or not -- I recall an early version that reported back whatever freq you had asked for rather than what it actually used. Queries based on ticks (rather than time or freq) did return what was actually used, as I recall.
Let's suppose a request for 700 kHz gets truncated to 28 cycles of the 20 MHz timebase making a 1.4 usec period. Then 50 of those periods becomes 70 usec, which is evenly divisible by the 100 kHz timebase. Bingo! (Note: 70 is the least common multiple of 10 and 1.4)
Now suppose the request for 900 kHz turns into 22 cycles of the 20 MHz timebase, or a 1.1 usec period. Now it takes 100 of those periods to get to 110 usec, which is also evenly divisible by the 100 kHz timebase. Bingo again! (Note: 110 is the lcm of 10 and 1.1).
Did you follow the method here? It should help you figure out expected results for various output freqs and #'s of samples.
-Kevin P.

Single shot analog output: How to pulse this. Probably easy, I'm at a loss.

Hello.
I have a piece of machinery that my system is connected to. Every time it reaches a proximity sensor (It's a reciprocating unit), I need to do a single pulse of 5v out of my analog output. It has to be fast, it has to stop until the sensor is reached again, and it can't stay 'on' for long.
I've attached my VI. I'm using a voltage input via DAQ assistant, routed through some logic to produce a 'true' boolean every time that sensor is reached, and that boolean is connected to a case structure with voltage out tasks created in DAQmx.
My problem is that the machine won't reverse while the case is still true and there's still the 5v being called by the true case on the case structure. It has to pulse, then stop, then be allowed to come back when the proximity sensor is reached again. As it is now, the machine reaches the prox and then the whole system stops, as the 'true' condition on the case structure, and subsequent voltage output, remain high.
I've attached the VI and heirarchy as well.
I've tried a few different things here, as well as just using a DAQ assistant with N samples, but that would just retrigger when the loop repeats anyway.
I'd love to sit and bang my head against this til I get it, but I'm under a time constraint. Help!
Still confused after 8 years.
Solved!
Go to Solution.
Attachments:
using create channel.vi ‏94 KB
logicsub.vi ‏32 KB

Ralph, without knowing the exact DAQ card that you are using, it is difficult to give you the best solution. If you want to continue with the solution that you currently have, try adding a shift register to the outer while loop to track the previous value of the boolean. In this way, we can keep multiple values that are above the threshold from causing multiple pulses. Next add a time delay after the DAQmx Write, then add another DAQmx Write to set the output back to your low value. Remove all code from your "false" case. See attached VIs. Please let us know what model of DAQ card you have as we may be able to do something clever like a retriggerable pulse train if your card can support it.
Charles Chickering
Charles Chickering
Architecture is art with rules.
...and the rules are more like guidelines
Attachments:
using create channel.vi ‏98 KB
logicsub.vi ‏29 KB

Generate a delayed counter pulse

I am posting this to see if anyone can shed any light on various DAQmx operations with counters. I appear to have found a solution for the project but various counter operations are certainly not well documented and the notes I am posting may help anyone trying to do something similar.
The project is to monitor an analog input channel and when a certain criterion is met generate a pulse with a specified width at a specified delay from the event. It is being done in a LV Real Time system. Initially I tried to start a counter task within a loop, wait until done and stop the task. What I have found is that it takes a long time (of the order of 10-100's of ms) for the start task to return and the wait until done doesn't reliably return at the time the counter pulse is finished being generated. Other people seem to have found the same problem. This is described in the part 1 attachment and the attached vi.
The other way to do it is with a retriggerable counter task and using a digital line on the same card to trigger the counter. Then the way the counter works if there is a single pulse or multiple pulses is different. The way low time and high time are interpreted is odd. This is described in the part 2 attachment with screenshots from Scope captures. I have a proposed solution but I'm not sure if it is the best way to do it.
Any suggestions appreciated.
Attachments:
Generate delayed Counter Pulse problem part 2.doc ‏108 KB
Generate delayed Counter Pulse Problem part 1.doc ‏25 KB
Generate Counter Pulse.vi ‏153 KB

Andrew,
If you want to start a counter output task based on an analog input you should use an analog trigger (if your device supports analog triggering). Take a look at the example Cont Acq Sample-Timed Loop-Analog Start.vi (in the example finder - search for "trigger") for how to set up an analog trigger in DAQmx. Also, you can use the Start.Delay property in the DAQmx Trigger property node to specify an amount of time to wait after the Start Trigger is received before generating the first sample
Michael P
National Instruments

Frequency divider + narrow pulse output

Hello all,
I need to divide the frequency of an incoming digital pulse by a factor of N (typically 10-50) but I would like the output signal to be 200ns wide. I'm able to divide the incoming pulse by using CO pulse ticks with the incoming pulse as the tick source and specifying the low and high ticks (low + high ticks = N). The problem is that the narrowest pulse I can generate is 2/f_in (or in my case 2/75kHz~ 26 us).
Is there any other way to divide a pulse and control the width of the output pulse?
I can use the "wide" pulse to trigger a narrow pulse on a different channel but I rather not use so many channels for this application. Is it possible to use just 1 input channel and 1 output channel?
Any advise will be greatly appreciated.
I'm using Labview 8 and pci 6251
Eyal

Hello Eyal,
Let me rephrase what it is I think you want to do:
1. You have a digital input with a frequency at or approximately 75 kHz.
2. You want to divide down this input frequency by N, where N is between 10 and 50 or so.
3. On every Nth pulse you want to generate a pulse with a 200ns high time and then return to a low state until the next 200ns pulse is generated.
If this is what you want to do then you would need 1 CO task to generate a pulse ever Nth rising edge of your input. Then you would use this pulse to trigger a retriggerable pulse train to output your 200ns pulse. All of this routing can be done internally so you would only physically connect one input and one output, however this setup would require three counters. One counter for the CO task and two counters for retriggerable pulse generation. Unfortunately your PCI-6251 only has two counters so to do this you would need to get a board with at least 3 counters.
If I didn't describe what you are trying to do accurately please reply back with further clarification incase what you are actually trying to do can be accomplished on your board.
If you would like to contact National Instruments directly to speak with a technical representative about getting a counter board you can find contact information at www.ni.com/contact.
Have a good weekend!
Brooks

Error 200140 and 200278 in Finite Retriggerable Encoder Triggered Sampling

Hello,
I have been using a rotary encoder to trigger a retriggerable sampling task. The encoder will give a pulse once per revolution and this will cause Labview to generate a finite pulse train which will be used to sample an analogue channel. The program will also return the pulse width of the encoder signal once per rev.
A problem arises if the encoder is run at speed, I receive error 200140. But if I run the program at a lower speed I eventually receive error 200278.
I am not sure why this is occuring as I am sampling continuously.
Thanks,
Ingram
Attachments:
Retriggerable_Finite_AI.vi ‏55 KB

Hi Ingram,
Thanks for your response regarding this issue.
Just to clarify, you are using the PCI 6250 to measure pulses from an encoder which is generating one pulse per revolution and turning at 1000 rpm and you are sampling this at 50kHz.
You are then taking these pulses and using them to trigger an input on the PCI 6220 which then reads the temperature. Does this mean you are taking 1000 temperature reading per minute?
Without seeing how you are implementing this in your code it is very hard for me to tell if the crash is as a result of this. Just to confirm, are you still getting the same error message?
Both the cards you are using don’t have simultaneous sampling; this means that the sampling speed is shared between your tasks.
If you believe the issue is with your code then please do attach this to your next post.
Many thanks,
Aaron. E
Applications Engineer Team Lead
National Instruments
ni.com/support

How to synchronize two timer/counter tasks?

Hi,
I'm programming DAQmx through the nicaiu.dll with Matlab. I'm trying to start two different tasks, each controlling ctr0 and ctr1, respectively. Both timer/counter tasks should start on a common trigger, in my case /Dev/PFI0. Having searched the forum, I do understand that both tasks can't be triggered off PFI0. Instead, I probably need to trigger one of my tasks on a signal that turns on whenever the first task starts. My question is; What signal can inform my ctr1 task that my ctr0 has started? I basically want these two tasks synchronized, but not pulse by pulse since the pulse trains are quite different.
Trying to trigger both off PFI0 results in a resource conflict. Triggering ctr1 on ctr0gate doesnt work either.
Also, I need ctr1 to trigger on when the ctr0 tasks starts, i.e. not when the first ctr0 pulse appaers!
Thanks,
Per

Thanks Ryan.
I made some changes to my code now and it appears I CAN trigger both counters off PFIO (on an E-Series board). I only recently converted all my Traditional code into DAQmx, and got lost in my tracks. I was trying to generate finite pulse trains on both counters, and had used Finite timing on the counters to generate finite retriggerable pulse trains, without knowing that tied up the second counter. I solved this now using Pause Triggers instead. In the case where I generate single retriggerable pulses I still use a Start Trigger, and I can now Start BOTH counters using DAQmxCfgDigEdgeStartTrig and listening to PFIO with both counters (each counter running off a separate task).
Sorry, I got things confused, and your solution isnt required anymore. Similarly to your solution, though, I have always used a (real) analog output routed externally to the PFI0 pin on my E-Series board as the synchronizing trigger. However, if I could avoid the external wiring it would be nice, so I will explore your solution a bit more
I am not familiar with the concept of a 'dummy' task/channel. Can you point me to more documentation on this?
I already use the analog inputs on this board from another app. Will creating a dummy AI tie up all analog inputs, so I can't then access my physical analog inputs from other applications (on the same board)?
- Per

Multiple pulse generation off master, 6602

I would like to generate 4 pulse trains phased with respect to the master pulse train. The example vi I am working with shows phasing relative to the preceeding pulse train (counter), so changing the phase of only one channel on the fly requires rephasing all subsequent channels. I would prefer not to do this. This example uses a "counter group" of 2 and sets the nth gate to the n-1 output ("other counter output"). Can I use a larger counter group and refer all channel gates back to the master pulse train? In doing so would this alleviate the need to use the Route Signal vi in going from one counter group to the next? I am using an 8 channel, NI 6602 card.

I'd like to try to give you an answer, but I might first need to ask some questions:
A. Is the "Master" pulse train an external signal or something you are going to generate from the 6602?
B. You talk about phasing, so I assume that the other 4 pulse trains need to have the same frequency as the master -- is this correct?
C. Do you need both rising and falling edges to be phased to the Master, or only one of the edges?
Here's an outline for how to handle an external Master, where the other 4 pulse trains are at the same frequency but only the rising edges have the desired phasing relationship. (You could also do it this way for an internally-generated Master.) They will be directly referenced to the Master, so you can change the phasing on any one of them without affecting the others.
1. Physically wire the Master pulse train to a legal Gate input. (If your Master is internally generated you could use RTSI and save the screwdriver work.)
2. Program the other 4 counters to be in "retriggerable pulse" mode, using max internal timebase as a Source, and the pin from step (1) as a Gate. Program Gate polarity to be sensitive to rising edges. Output polarity can probably left as default (low state during delay or when inactive, high state during pulse). Each one has to be configured separately, using a unique group #
3. Program the pulse parameters to use for delay, and a minimal pulse duration. The short duration allows the counter to be ready to be re-triggered as soon as possible after the needed delay, allowing you to approach 360 degree lag.
4. It sounds like you already know how to pass in a new delay parameter "Pulse Spec 1" and issue the "Switch Cycle" command when you need to change the phase on the fly.
(If you have an internally generated Master where you can know the exact period, you could also have passed in the new pulse duration parameter "Pulse Spec 2" such that the sum is always == Master pulse train period. This way you can maintain phasing relationships on both rising *and* falling edges.)
However, if you have an external Master and need phasing on both rising and falling edges, I'm afraid I'm stumped.
Regarding "grouping" the counters: I don't think it can be done yet. But you can set up 4 individual counters with each one mapped to use the same physical signal for its programmed Gate (used here for retriggering).
Since all 4 will be programmed similarly, you might clean up your block diagram a bit by carrying the task id's through as an array, over which you auto-index a For loop. Also think about whether to pass the error cluster through as an array (individual error chain for each counter) or a shift register (shared for all slave counters).
Regarding "other counter output." This is more restricted than it might sound. You don't get to choose which "other" counter you want. You get what NI has predetermined as each counter's "other." Specifically, they are paired on the 6602 as follows:
(0,1), (2,3), (4,5), (6,7) so that Counter #3 is the "other" counter for Counter #2, vice versa, and likewise for each other pair.

Retriggerable pulse task

Similar Messages

Maybe you are looking for