High speed variable width pulse generation

I searched NI's website the best I could but could not find anything relating specifically to my question.
I want to produce a pulse of variable width every 10 ms.  It seems
the ideal way to do this is to specify a counter to count a certain
number of ticks and then go negative when it's reached that
number.  It's pretty easy to get the counter to do that, however
the speed is an issue.  Is there any way to have the counter
generate a different width pulse specified by an input number of ticks
that can update every 10 ms.  Any resources to help me figure this
out that you can suggest would help greatly.
I have PCI 6229 card and if I can figure this out, I'll submit a real nice stepper motor control VI as an example.
Thanks,
Phil
Message Edited by flip518 on 07-19-2005 12:10 PM

Phil,
It isn't possible to do deterministic pulse width modulation with you
board, however, I can think of a couple ways to try to get close. 
If you set your board up to do a continous pulse train generation, you
have the ability through a DAQmx Channel Property Node to
programmatically set the count registers to a different value.  In
the loop that waits for the Stop button, you can set the Wait For Next
Millisecond Multiple to be 10, and thus approximately every 10 ms you
would change the count register.  You can change the frequency of
the pulse three ways, by frequency and duty cycle, actual pulse high
time and low time, or actual clock ticks for the high and low parts of
the cycle.  The problem with this method is that since Windows
isn't deterministic, plus you are writing over the PCI bus to the
hardware, you are not guaranteed the accuracy of the 10ms loop.
Attached is a VI that shows this -- it is modified from the Gen Dig
Pulse Train-Continuous.vi example that ships with the NI-DAQmx driver.
Doug M
Applications Engineer
National Instruments
For those unfamiliar with NBC's The Office, my icon is NOT a picture of me
Attachments:
Software timed Pulse Width Modulation .vi ‏65 KB

Similar Messages

  • In Delayed Pulse Generation vi,Problem With THE PULSE WIDTH??

    In Delayed Pulse Generation vi, I want to input a very low number for the Pulse Width while using an external timebase source. But the minimum pulse width has to be 2. Does anyone know how can I solve this problem??

    Hey 45,
    Unfortunately, there is no way to generate a pulse width smaller than 2x your external timebase.
    There is an option to create a pulse of arbitrary width of your external source if you can afford some software processing in between. What you can do is use 1 counter to measure how many source edges of your card's internal timebase (80 MHz for TIO only, 20MHz or 100kHz for TIO and STC) your external signal is. This uses pulse width measurement as the counter application. Once you know how many source edges it takes to represent your pulse, then you can use triggered pulse generation and use the internal timebase with the pulse specs set to create the exact pulse width you want (and delay) and you can use your external pulse as the trigger. Th
    is works well if your pulse is always the same width and you can measure it before hand. As an example, let's say your pulse is 20 internal timebase pulses when measured. This means you can use the pulse specs to specify a pulse width of 0.75 your pulse width by using only 15 internal timebase edges for your pulse width.
    I don't know if I was clear above or not but if you give me your exact application you are looking to achieve, I might be able to help you out. Hope that helps.
    Ron

  • Counting TTL pulses at high speed

    Hi all,
    I am using PCI-6221 board with DAQmx to count the number of TTL pulses (which varies in its frequency between 0Hz to 10MHz) at a high speed (200,000 samples/sec.) and I am having a problem when the TTL pulse frequency drops below a certain level.
    I am using CTR0 to generate continuous pulse train at 200kHz frequency to feed to CTR1 Gate input. I verified that the pulse train is being generated fine.
    I am using CRT1 with buffered counting to collect the count for 200,000 samples at a time (duration of 1 sec.). I got the example code (Cnt-Buf-Cont-ExtClk) and pretty much used it as is.
    CTR1 Gate is coming from CTR0 Out, which is 200kHz pulse train with 50% duty cycle, and CTR1 Source is the TTL signal that I am trying to count. At first, I thought that everything was working fine with the Source signal being at around 5MHz. Then, when I had the Source signal down below about 300kHz, I noticed that the program is taking longer than 1 sec. to collect the same 200k samples. Then, when I got the Source signal down to 0Hz, the program timed out.
    I am guessing that somehow the counter is not reading for the next sample when there has been no change to the count, but I cannot figure out why and how.
    Any information on this and a way to get around would be greatly appreciated.
    Kwang

    One thing you can try is to set the counter input CI.DupCounterPrevention property, this setting will filter the input, it is possible that when the ctr 0 is slow then many of the values you are counting become zero as well and are filtered out, since they are nolonger points, the counter will not collect enough points before the time-out occurs and the counter input read times out.  I am not sure if this is your issue but I found out the hard way that this occurs when I switched to daqMX where this feature was added.  Let me know if it worked,
    Paul
    Paul Falkenstein
    Coleman Technologies Inc.
    CLA, CPI, AIA-Vision
    Labview 4.0- 2013, RT, Vision, FPGA

  • I need to count intermitte​nt high speed pulses from an outside source with cFP-CTR-50​2 and labview.

    I need to count intermittent high speed pulses from an outside source with cFP-CTR-502 and Labview 8.2 . I've found example code for generating pulses and creating intricate count setups but no straightforward examples of a simple counter. Any suggestions?

    Hello tinfish,
    I could not find a simple example that implements simple counting either, but it should be straightforward enough for us to try. Do you have the CTR module configured properly in MAX? If so, can you monitor the channels on your CTR 502 for input? Try connecting a square wave or some other digital pulse to the terminal to test the functionality of the counter module first (before programming). If you monitor the input channels with somethign connected you should see the count increment each time it sees a rising edge (assuming default configuration).
    Once you've verified that everything works in MAX, you can set up your CTR module in a LV 8.2 project. If you need help with this, refer to the help document (look in the "Configuring FieldPoint in LabVIEW" section):
    C:\Program Files\National Instruments\FieldPoint\documentation\Online Help\fplv.chm
    You should be able to just read a channel tag from your CTR 502 using an FP Read VI. (Simply drag the channel from your project onto the block diagram). Since counting is the default behavior of the 502, there is no special programming involved to make it work.
    I hope this helps -- if it's too high-level we can talk details about specific questions you have.  Have a good one!
    Charlie S.
    Visit ni.com/gettingstarted for step-by-step help in setting up your system

  • How to use PCI-6534 High speed DIO to count the no.of pulses aquired

    HI All
    I have PCI-6534 high speed DIO card. My requirement is to count the no.of pulses coming. Here i have an energy meter which generates pulses with frequency of around 8MHz. i need to cunt the no. of pulses coming in, here i am attaching the VI i am using. I could not really count all pulses coming in. right now i am using single line, but the requirement is to develop for 7 lines. I do not know where i am going wrong. Can any of you help me in this regards.
    Thanks
    Anil Punnam
    Attachments:
    Read Dig Chan-Change Detection_stop.vi ‏120 KB

    Sorry, not near a LV PC so can't look at your vi now.  Are you limited to using only the 6534?  If all you need to know is the count of pulses from each of the 7 ~8MHz sources, it seems like the amount of data storage required with a 6534 is terribly inefficient.  Since the 7 sources are unlikely to be synchronized in any way and they are each at ~8MHz, you're looking at about 100+ million transitions per second with change detection.  I don't think the hw can keep up with that.  Even using a constant sampling rate of 20 MHz (which just barely satisfies the Nyquist minimum of 2x 8MHz), it's questionable whether you can keep up with that rate for several minutes.  Even supposing the hw and your PCI bus and software can keep up, there's still a TON of processing to do.  20 MB/sec for 20 minutes = 24 GB! 
    On the other hand, consider the 6602 counter timer board.  Here you would simply set up 7 edge counting tasks, probably without any buffering at all.  At any leisurely pace you want, you can software query the counts of the # of pulses on each of the 7 channels and have an instant answer.  The only issue to deal with is that the counts will rollover when you reach 2**32.  At 8 MHz, this will happen about every 9 minutes.  However, DAQmx provides a nice way to handle this.  There's a property you can query that will tell you if a rollover has occurred.  It automatically resets itself to False after you read it so it's ready to detect the next rollover 9 minutes later.  See my first post in this thread for example.  (Last I knew, only DAQmx does the automatic reset, not traditional NI-DAQ).
    If you can possibly buy a 6602, I'd highly recommend it.
    -Kevin P.

  • Pulse generation PCI-6220

    Hi there,
    I´m an absolutely newbie to labview and hope to get some advices as I´m completely stuck at the moment.
    I´d like to generate variable TTL pulses to 3 different lines. Since the PCI6220 card only has two counters I´ve to go for the normal hardware correlated DIO lines.
    For now I´d be happy to see it working just for one line as follows:
    __|   |________|           |_ ...
    I´ve to be able to set the pulse width of the high time for the first and the second pulse as well as the two different low times. This scheme should furthermore than be repeated n times. Thus having 5 variables, the length of the pulses in ms: 'Low1','High1','Low2','High2', and the number of repetitions: 'n'.
    I may be horribly wrong with this, but I think working with the duty cycle doesn´t work for that application, does it?
    Assuming I use the frequency generation of a counter as a sample clock to my pulse generation, it seems rather simple taking for instance 'High1' corresponding pulses of the counter clock to generate the 1st pulse then 'Low2' pulses for the subsequent low pulse and so forth. Could anyone give me a hint to do so, or are there better/other ways how to achieve this? Are there eventually vi's available I could start with (haven´t found proper one´s in this forum nor in the Labview implemented library)?
    Many, many thanks in advance for any help!!
    Robert

    Rob:  I looked at your example earlier when I was near my LV machine.  From memory:
    1. I think I recall that you specified PFI 2 as the sample clock source for the digital task while using CTR 0 to generate the clock.  According to this doc, the default output pin for CTR 0 is "terminal" 2.  However, that does NOT turn out to be another name for PFI 2.  Rather, terminal 2 is designated as PFI 12 as can be seen here.   (This stuff is also visible in MAX when you select your device, right-click and choose "device pinouts").
    2. I recall you used a U32 array version of DAQmx Write. You may need to use the U8 version on your 6220 board.  Also, the init values you wrote before the loop alternate between 255 (all bits high) and 0 (all bits low).  The values you write inside the loop alterate between 1 (LSB high, all other bits low) and 0 (all bits low).
    3. You defined the digital task for finite generation, filled its buffer before the loop, then attempted to keep overwriting it inside the loop.  These are not mutually consistent.  If you want finite generation, fill once only.  If you want continuous generation, it'll take some care not to overwrite too soon.
    4. Minor nit: It may not matter in your app, but often its best to start up the digital task before starting the counter task that generates its clock.  You can accomplish this by simply routing the error cluster from the digital task's DAQmx Start up to the counter task's Create Virtual Channel.
    I'm not near LV now to look at the recent example from Christian M.  Hope it suits your needs...
    -Kevin P.

  • Pulse Generation application with DAQmx and a PXI-6624 module?

    What is the best implementation method for the following pulse generation application
    using LabVIEW, DAQmx and a PXI-6624 counter\timer module?
    I have two rising edge trigger signals (Trigger-1 and Trigger-2).
    There is ample spacing between each trigger. They never occur at the same time.
    I need to generate a single pulse (fixed width, variable delay) whenever Trigger-1 occurs and
    a finite pulse train (fixed width, variable delay, N-pulses) whenever Trigger-2 occurs.
    However, the output must appear on one counter output because this composite signal
    will be used as a trigger source for another PXI module in the rack.
    With DAQmx and a TIO counter\timer can I use both the GATE (for Trigger-1) and
    AUX (for Trigger-2) at the same time on the same counter to gate out the desired pulses?
    Trigger-1 would be wired to the GATE of CTR0. One Trigger-1 event would generate one pulse on the output of CTR0.
    Trigger-2 would be wired to the GATE of CTR1 and the output of CTR1 would be routed to the AUX input of CTR0.
    One Trigger-2 event at the GATE of CTR1 would generate multiple pulses on output of CTR0.
    Would DAQmx and the PXI-6624 TIO support this implementation?
    What is the best way to accomplish the task at hand.
    Thank You.
    Best Regards,
    Scooby

    Hi Scooby,
    I have looked into the application you have described and I see a potential problem with what you describe.  In DAQmx, it is not possible to call the counters of the same DAQ device in the same task, so you cannot have the finite pulse train generation and the single pulse generation tasks running at the same time.  What you can do, since you mention the triggers will not occur at the same time, is to stop one counter task while you are triggering another.  The way I would suggest you merge the outputs is with a two input Or logic gate to avoid damaging your counters.  Your signals will effectively be added together by this logic gate.   I do not see any way to merge the outputs internal to the DAQ device. 
    Please let me know if I can be of additional assistance.
    Laura

  • Frequency divider/ pulse generation from 1 to n

    Hi,
    I have a sample pulse which in some cases needs to be divided. I tried to use the pulse train generation function, which works fine (giving me a pulse every n sample pulses), but only starting at 2 input pulses. I need to be able to use this function from a division of 1 and up.
    Put in another way, can a counter be configured in such a way that it outputs a pulse every rising edge of the source signal?
    I'm using a PXI 6602 counter card and am programming it through calls to NIDAQ32.DLL under Labview 7.

    Hi Walter,
    In short, no. You can't output a pulse on every input pulse. You can however configure the degree of division. Here are the rules for division:
    When set to pulse train generation, you will have a register for the low value of the pulse train and a register for the high value. What happens in typical pulse generation is that these registers are loaded with count values such as 2 and 2 for each register respectively. In default operation, the first register will count 2 pulses on the source and then toggle the output. The second register will then count to pulses and toggle the output again. The operation then cycles back to the first register. This toggling effectively creates a pulse train that is divided by 4 and a duty cycle of 50%.
    You can however change the output mode to pulse instead of toggling upon completion of counting on a register. In the above example, you would count 2 source edges and then pulse for the first register and the count 2 more edges and pulse again for the second register. You will of course repeat this in pulse train generation mode. This mode allows you to obtain greater resolution since you are now dividing by 2 but your duty cycle will be different. Each pulsed output will be equivalent in size to the source pulse width.
    Finally, the two registers can be populated with integer values of 2 or greater. Therefore, the smallest frequency division is 2.
    You will have to work with these three elements to obtain the pulse train of your desired frequency. Hope that helps. Have a good day.
    Ron
    Applications Engineering
    National Instruments

  • Simple pulse generation toggle

    Below is an excerpt from the 6602 manual.  The figure may not show so I've attached a word document showing it.  I want to do exactly what this says but am not sure how to make it happen.  I need to generate a quadrature signal and I think this would work wonderfully.  I want to setup one counter as my source and have two others toggle appropriately (keeping 90 degree phase shift). 
    How do I get into "Toggle" mode???
    Thanks!
    In toggled mode, the counter output changes state on the SOURCE edge
    that follows the assertion of the TC pulse. Figure 3-6 illustrates the two
    output modes for a pulse generation with a delay of two and a pulse width
    of four.
    Figure 3-6. Output Modes
    Attachments:
    6602 manual excerpt.doc ‏28 KB

    Howdy,
    You can use any of three DAQmx Create Channel VI's (CO Pulse Freq, Time or Ticks) to accomplish this generation. For this particular application, CO Pulse Ticks would probably be easiest since it allows us to input an initial delay, number of high ticks, and number of low ticks. For example, looking at Figure 3-6, to generate the bottom waveform, we would have something like the following config:
    the top waveform (SOURCE) would be connected to the source of ticks input on the DAQmx Create Channel (CO Pulse Ticks).vi
    initial delay: 3
    high ticks: 4
    low ticks: 2
    The DAQmx help for DAQmx Create Virtual Channel goes into more detail about these three Create Channel VI's if needed.
    (Just in case anyone references this thread in the future, this discussion is referring to Figure 3-6 of the January 1999 version of the 6601/6602 User Manual available here.)
    Warm regards,
    pBerg

  • High speed event counting

    I am looking to count events where an event is defined by 1 ttl pulse of 30ns (A newer device allows for 3V 9ns)  I prevoiusly used the6602 but am looking to make a standalone singleboard rio application.  When talking to some engineers this I was told that this was possible, but looking at the spect there needs to be a 100ns min pulse width.  Are there any work arounds?  Is it possible to add sme chip as a prescalar to the input (divide by 10 highspeed counter?)  I am stuck and am ready to meke some hardware decisions.
    Paul Falkenstein
    Coleman Technologies Inc.
    CLA, CPI, AIA-Vision
    Labview 4.0- 2013, RT, Vision, FPGA

    falkpl,
    As I am not certain if a moderator can move a post, the best way would probably be to re-post the question on your desired board. Be sure to post a link here to the new discussion. You generally want to avoid double-posting, but as long as it is clear that this discussion was moved to another place, most people will forgive you. 
    Now, assuming you have not posted elsewhere, I will comment on your issue. The sbRIO's have IO pins that allow you to connect right into the FPGA. As you have found, the manual guarantees a 10 MHz rate and states you can get a bit faster if you are acquiring a single 3.3 V signal.
    To get even faster, you may have a few options.
    Use a deserializer to break up one high speed signal into multiple slower signals.
    A similar idea which will not require external hardware, but maybe a bit more programming is to read the same channel on several inputs with slightly staggered start times. This post discusses the idea a bit more.
    Good luck, let us know your thoughts and how it turns out.
    Peter Flores
    Applications Engineer

  • I have one application that has requirement to do low and high speed acquisition. I want to change sample rate while running. BUT... I have E series Device

    I am writing control software for a process that is usually dull and
    requires only 10 Hz acquisition rate.  At particular times during
    the sequence, however, we are interested in looking at a couple of
    channels at 1000 Hz.  My approach so far is to configure my
    Buffered DAQ to run at the higher rate at all times.  When we are
    in the 'high-speed DAQ' mode, the program logs every point to
    disk.  In the 'low-speed' mode, I am picking off every nth (in
    this case, 10th) point to log to disk.  At all times, I update my
    GUI indicators on the front panel at a maximum of 4 times per second (I
    find that anything faster results in an uncomfortable display), so I
    fill up a FIFO with data in my acquisition / logging loop, and read the
    FIFO in the display loop.  The data in my GUI display can be up to
    250 milliseconds off, but I find this acceptable . As a side note, I
    need buffered Daq with hardware timing, as software timing results in
    lost data at 1000 Hz.
    This all works fine and dandy, but I am convinced that it is not the
    most elegant solution in the world.  Has anyone developed a
    buffered DAQ loop where the scan rate can be adjusted during
    operation?  I would like to change the rate of the E-Series card
    rather than relying on down-sampling as I am now doing. 
    The reason I have concern is that at the moment I am simulating my AI
    using MAX and when running the down-sampling routine, I consistently
    miss a particular event on the simulated data becuase the event in
    question on the simulated data always occurs at the same 'time', and I
    always miss it.  Granted, while it is unlikely that my measured
    signal and my acquisition are perfectly synchronized in the real world,
    this particular situation points out the weakness in my approach.
    More than anything, I am looking for ideas from the community to see
    how other people have solved similar problems, and to have you guys
    either tear apart my approach or tell me it is 'ok'.  What do you
    think?
    Wes Ramm, Cyth UK
    CLD, CPLI

    Adding to Alan's answer:
    One of the problems that comes with these tricks for variable-rate acquisition is being able to match up sample data with the time that it was sampled. 
    If you weren't using either of E-series board's counters, there is a nifty solution to this!  You'll be using 1 of the counters to generate the variable-rate sampling clock.  You can then use the 2nd counter to perform a buffered period measurement on the output of the 1st counter.  This gives you a hw-timed measurement of every sampling interval.  You would need to keep track of a cumulative sum of these periods to generate a hw-accurate timestamp value for each sample.
    Note:  the very first buffered period measurement is the time from starting the 2nd counter until the first active edge from the 1st.  For your app, you should ignore it.
    -Kevin P.

  • Timeout errors when using high speed camera.

    Hi all.
    I'm currently trying to capture images using a Mikrotron EoSens MC1363 camera at high frame rates >500fps. The issue arises when the region of interest (ROI) is decreased in the microtron software (of which screenshots are attached). The ROI must be dropped in order to increase the fps. When MAX is opened and configured to match the camera settings, and grab is initiated, the timeout error occurs. I've attached screenshots of the mikrotron software, max settings, the error and PC used. The OS is windows 7 64 bit. We use the camera config file for the mono version of the camera which i've been informed will cross over to satisfy the colour version we use. Any questions feel free to ask. Thanks.
    Attachments:
    errors.docx ‏3016 KB
    997-EoSens 3CL-MC1362-Manual.pdf ‏1209 KB

    Hi Dom.
    As you said the maximum frame rate with the ROI set to 1280 x 1024 is 505fps but according to the general information for the camera series:
    The Mikrotron EoSens camera series features extremely sensitive high-speed
    CMOS sensors available in monochrome or in colour with a resolution of 1280 x
    1024 pixels and capture rates of 110 or 500 frames per second. Depending on
    the model the image data is transferred in 8 or 10 bits via either CameraLink
    (Base, Medium or Full) or Gigabit Ethernet.The region of interest (ROI) can be
    freely selected, and the cameras can achieve even higher capture rates up to
    120,000 fps when the ROI is reduced
    Therefore it was my thought that by reducing the width of the ROI increased frame rates may be reached. Realistically we're looking for as high frame rates as possible so that the camera has capability to pass between projects. Currently the moving object enters and leaves the ROI within a 4 frame window, so frame rates of up to 1000fps would generate more data. Naturally, a point will come where the data cannot be physically written as fast as it is generated (>600MBps). Therefore it would be useful to get a handle onto why the error occurs as well as methods to fix it. Hopefully the problem is being discussed between NI and Mikrotron and we may have some answers in the near future.

  • Monitoring pulse generation

    Hi all,
    I am using a USB-6210 card and
    measurement studio with VStudio2003. I would like to drive a stepper
    motor (which turns a miror in a spectrometer) by sending digital pulses
    to a motor driver. Using another channel on my card, i would also like
    to read a voltage (from an IR detector) every time i send 100 pulses to
    the stepper motor on the other channel. The purpose is to be able to
    log the voltage against the position of the motor.
    I am not sure what the correct method is... I can think of different options :
    Use
    \National
    Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Counter\Generate
    Pulse\GenDigPulse + incrementing a variable that counts each time i
    send a single pulse. When the variable reaches 100, i take a reading.
    This concept is simplistic, however with this method i am concerned
    about having to often start/stop the task.
    I have seen interesting examples in the following directories, using a continuous pulse train + counting digital events.
    \National Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Counter\Generate Pulse\GenDigPulseTrain_Continuous
    \National Instruments\MeasurementStudioVS2003\VCNET\Examples\DAQmx\Counter\CountDigEvents\
    How can i integrate these two examples to be able to count the pulses? Shall I just physically connect the counter pin and the pulse generation pin on the connector block of my card?
    To
    decide whether the motor has arrived to the aimed position I could use
    the a "counting" class to drive (=start/stop) a "pulse generation"
    class ?
    However the counting methods are driven by a Timing
    function (which runs every 50ms max), so i will always end up being
    slightly over positionned because of the lag time of the OnTime method?
    (i guess it doesnt really matters, as long as i know where i am)
    Use
    a finite pulse train. This imply using my two counters and then i would
    not be able to know where my motor is if the software was to end
    prematurely.
    Does anyone know what is the right way to do this?
    Thanks
    Laurent

    Duplicate thread:
    http://forums.ni.com/ni/board/message?board.id=250&message.id=37363

  • How can we generate a pulse train with variable inster pulse delays?

    I want to generate a pulse train with random inter pulse delays (100us-10000us) and the pulse width would be 50-100us. I programmed for single pulse generation using counter cfg,a for loop contaning set attribute parameters pulse spec 1 and pulse spec 2. I changed the pulse spec 1 value in every cycle
    This program is generating the pulses but not the exact values in the sense the some times the delays are more than 10 msec. As per the program the delay should be maximum 10 msec. please help me ASAP.
    thanks
    thota

    Hey Thota,
    I would suggest to take a look at the example program linked below. It shows how to change pulse specs on the fly. You have to be make sure you are ignoring a certain error when doing this.
    Pulse Train Generation with Changing Pulse Specs (PWM)
    http://sine.ni.com/apps/we/niepd_web_display.displ​ay_epd4?p_guid=B45EACE3E21756A4E034080020E74861&p_​node=DZ52328&p_source=External
    I hope this helps.
    Regards,
    Todd D.
    NI Applications Engineer

  • Urgent problem! please help. high speed digitizer, channel switch time too long!

    Dear all NI high speed digitizer experts:
     I post a question concerning the two-channel configuration using NI5154 digitizer (see Need help to configure a two-channel acquisition using NI5154 ).
     As we need to do some measurement using NI5154 very soon so purchase a DAQ board as suggested by Efrain is not a option for our coming experiment. So I try to configure the NI5154 a two channel acquisition. I configure the NI5154 to count pulse in two channels. Our experimental setup will send pulse to channel 0 for 400 ms and then stop. 100 ms later pulses from other source will be send to channel 1 for 2 s.  I thought the 100ms dead time in our setup would be long enough for the digitizer to switch from channel 0 to channel 1. But after some test I found the digitizer takes more time to switch between channels. 
    I made a test vi (NISCOPE-Timing.vi) just for count how many ms it takes for the digitizer to switch between channels. In the attached vi, if you run for only one channel one loop takes about 20 ms in my pc. If you run for two channels it takes about 130 ms for one loop. If you just run one channel twice the loop time is about 40 ms (I mean stop a channel and then restart the that channel).
    I don't understand why it takes so long to switch from channel 0 to channel 1.  As I tested the niScope Commit.vi consumes a lot of time for the second channel. Is there any way to avoid this? We can not extend the 100ms long dead time of out set up so I must get rid of this problem. 
    Solved!
    Go to Solution.
    Attachments:
    NiSCOPE-Timing.vi ‏34 KB

    Hi Lixin,
    There are a couple of different options that you may try. The first, which it sounds like you may not prefer, is to use the TRIG line on the 5154 and somehow find a way to route both sets of pulses to that line. You can either somehow connect both lines to the one input or use some sort of external switch since the signals will not come in at the same time.
    Unfortunately, what you re seeing in terms of the time it takes the board to reconfigure itself for a different trigger channel and re-inititiate is due to the settling time that is necessary for the board to be able to fully reach its specifications. The majority of settling usually occurs pretty quickly, but the board will wait for some time to get the best possible performance in terms of specs. If you are okay with reducing this settling time (and very slightly diminish the specified performance), then you can use an internal scope property to set the max settling time.
    I have attached a .rc file which must be placed in the LabVIEW directory for niScope to enable use of this property node. Please place the file in your ...\Program Files\National Instruments\<LabVIEW 2009>\instr.lib\niScope directory. Once the file is in that directory, restart LabVIEW, and you should be able to see a new category in the niScope Property Node tree titled "Internal". Under that category, you will have the Max Settling Time property, which gives the driver a maximum amount of time (in seconds) to wait for settling before beginning a new acquisition. Add this new property to your first property node at the beginning of your program. I tested this out with a value of 50 ms and found that my initiate went from ~125 ms to ~53 ms or so after reconfiguring the trigger channel and re-initiating.
    Hope this helps!
    Daniel S.
    National Instruments
    Attachments:
    niScopeMaxSettling.zip ‏1 KB

Maybe you are looking for