Count edges on rtsi0

Hi all,
I have a PCI 7831-R and a PCI 6143 card running on my computer. Both
are synchronized with a RTSi cable. The PCI7831 delivers via RTSI 0 a
clock signal for Trigger my analog signals. My problem is now that i
want count the edges on rtsi0 because I want to know what  the
values  of my analog signal are refered to my triggersignal. For
example, Trigger edge 1 - analog value x,  trigger 
edge  2 - analog value x. Is that possible. I don't found nothing
on ni examples. Thank you for your help.
Grüße aus Deutschland
Manuel

Manuel,
you want to count edges from a RTSI line with the PCI 6143, right?
Have a look on the following post:
http://forums.ni.com/ni/board/message?board.id=250&message.id=4715&requireLogin=False
Regards,
ThSa
Message Edited by ThSa on 04-05-2006 09:42 AM
http://www.newgistics.com

Similar Messages

  • Counting edges

    I am using a PCI-MIO-16E1 DAQ board. I want to generate pulses using the STC
    counter on the board and count the pulses using the second counter available.
    There is a vi available specifically for counting the no of rising edges
    in the examples/daq/counter/STC. This requires the source information to
    be specified. The information is in terms of the PFI/RTSI lines.
    There is also a vi specifically for generating a pulse train using the STC
    counter.This generates pulses at the outpinof the counter used for generating
    the pulses.
    I am not able to relate the source information on the counting vi to the
    outpin of the generating counter.
    Please let me know
    Thanks
    Vijay

    Hi Vijay,
    You are correct in using those two examples. To re-iterate, you will use the VI called Count Edges (DAQ-STC).vi and the one called Generate Pulse Train (DAQ-STC).vi. Now if you scroll over to left on both of these VIs you will see Gate Specifications and Source Specifications. You will notice that the control beside PFI line has the value "default". You will notice on the pinout for that card that counter 1's source is PFI3/GPCTR1_SOURCE, and counter 0's output is GPCTR0_OUT. So when you specifiy defaults it uses the appropiate labeled pin, which in this case defaults to PFI 3 and GPCTR0_OUT.
    In other words, open the Count Edges (DAQ-STC).vi and enter counter 1 in the counter control. Then open the Generate Pulse Train (DAQ-STC).vi and enter count
    er 2 in the counter control. Leave the slide control on PFI Line (default). Connect pins 2 and 42 together. Run the Generate Pulse Train (DAQ-STC).vi and then the Count Edges (DAQ-STC).vi. This should work. Hope this helps.

  • Is it possible to use "Delay Values" to create a frequency signal from digital "Count Edges" -task? (= are the results I'm getting correct?)

    Hello.
    I have a digital encoder from which I need freaquency information (to ultimately get rpm -infromation). The problem is that this task is inside a loop with 2 other DAQmx -tasks that are using "one sample on demand"-aquisition mode and if I configure this new counter task to be a freaquency task, it only updates once in ~ second which makes the whole loop lag.
    I thus created an "artificial" freaquency signal by using "Count Edges" -aquicition mode and the "Delay Values" -block so that I substract the delayed signal from original "Count Edges" -signal. There is a 0,01s delay in the loop and I figured out that if the history of the "Delay Values" -block is 100 samples I would thus get the real edge-freaquency.
    I tested this configuration and the results seem to be at least really close to correct but I have no idea if this idea is in any way correct...
    This explanation was probably quite confusing so please see the picture attached.
    Thanks a lot in advance! 
    Attachments:
    are_the_results_correct.jpg ‏200 KB

    First of all, thank you for quick reply. Unfortunately I don't have the acces to the vi. until tomorrow.
    And yes, I think you understood correctly: essentially this arragement measures how many edges have been counted during one iteration. This is how I figured out that this could then be used as a frequency measurement:
    1. From the "Edges - Delayed Edges" I get the information on how many edges have been counted during last iteration.
    2. I "know" (really I don't?) that one iteration lasts ~0,01s because of the delay in the loop.
    3. There is 2048 edges in one round of the encoder so I get the rpm as follows: rpm = (edges - delayed edges)/204,8*60(s)
    (If I was using history size of one as you suggested it would be: rpm = (edges-delayed edges)/2048 * 60) However using history size of 10 and taking it account in the multiplication smoothens the response nicely.
    But doesn't this arragement count on the fact that the vi runs smoothly and there is no additional lag?
    I quess using another loop and notifiers for a dedicated freaquency measurement as you suggested could be worth trying. I just have to first learn how to use them. 
    If I do use them will the main loop run smoothly and not wait for every update of the notifier? This would be essential since the freaquency output refresses only about once in a second if I use the continious aquisition mode.
    Attachments:
    are_the_results_correct.jpg ‏198 KB

  • Timing problem with counting edges

    Hello!
    I use a NI PCI-6221 DAQ card with NI-DAQmx to count edges of TTL pulses for a spectrometric application.
    It is extremely important that I count the pulses for a well-defined period of time. Typically, I want to count the edges that reach the counter in the period of 400 milliseconds.
    Normally, this works quite well, when I use a WHILE loop that reads and restarts the counter every 400 milliseconds. Things change when the PC I run the VI on has other programs running in the background. Expecially computing-time intensive programs delay the 400 milliseconds of the WHILE loop for up to several 100 percent, resulting in an wrong counter read.
    I tried to use a timed WHILE loop but this din't change anything, regardless of the timimg source (onboard clock or PCI-6221 counter) I applied.
    Has anyone encountered similar problems and found a solution? Isn't there a possibility to control the counting time by hardware?
    Thanks in advance!
    EresthorMessage Edited by Eresthor on 04-07-2005 08:17 AM

    Hej Lynn,
    of course your idea works, thank you. It works extremely well this way, too.
    My problem with this approach is that I need both counters on the PCI-6221 to count data from my spectrometer simultaneously on two channels. That's why I would like to trigger the counter in a different way, for example with a clock.
    Is there no way to trigger the counter with the timebase of a hardware clock on the card? Or ist there another possibility without wasting a counter?
    Eresthor

  • Counting edges with dynapar encoder

    Hello,
    I am very new to Labview. To kick off some experience, I am trying to count edges on a Dynapar encoder, Model E14020000303. Here is the data sheet:
     https://ecatalog.dynapar.com/downloads/E14_DS_702489_2_.pdf
    I am using LabVIEW 2011, with a NI USB-6210 DAQ. My white wire on the encoder is connected to PFI0. The red and black wires are connected to my 5V voltage source. I am rotating my encoder to count the revolutions. Supposedly my encoder is a 200 PPR, and it is also quadrature. 
    However, I am not understanding what I am getting when counting edges using DAQ Assistant. I am using the Edge Count on ctr0. I can set the DAQ assistant to run on 1 sample acquisition mode and count the rising edge. When I turn the encoder 100 times, the measured value on the DAQ Assistant is usually around 76500, which would mean 765 edges counted per revolution. I can also change things around and go to continuous acquisition mode. I set up PFI2 as the external clock source with a rising edge and put the green wire in PFI2. I set it to read 1 sample at 1k Hz. This usually results in counting around 820 edges.
    I don't understand why I am getting these readings. The DAQ Assistant should only be counting rising edges because that is what it is set at. Why am I getting numbers so high? 
    Thanks!
     

    Hey guys,
    Sorry for the late reply, I have been put on other tasks. You all were right about the ground, that indeed was the problem. With the daq grounded, the encoder measures 200 edges per revolution.
    Thanks!

  • Count edges of AI signal with NI 9221

    Hi,
    I'm trying to count edges of an AI signal that are acquired with an NI-9221 on a cDAQ. The average frequency is about 1kHz.
    I'm acquiring the signal with 10kHz but don't get the right amount of edges. 
    Is
    there any solution for this problem. I know, of course it would be
    easier to use a CTR-modul but my signals doesn't fit with the specs.
    Thanks for any help
    Yves

    Yes, I know. I wanted it to be posted in the Labview forum and hadn't realized my mistake.
    But I still don't have any solution....
    Yves

  • Setting output pin to high while counter counts edges - 660x

    Traditional DAQ allowed you to set the output of a counter while it counted, is there an equivalent for daqmx?  The counter output for our current setup spins a motor until the counter reaches the proper number of counted edges from another pulse generator on the board. Perhaps I need to reconsider the setup, but there should be a method to do this action.  I was only able to find an indicator of the output state in the Channel property nodes. Any ideas? Thanks.

    Hello Roth,
    An event is thrown whenever a counter reaches its terminal count, and you should be able to use that to your advantage here.  Once that terminal count is reached, you can use DAQmx properties to set the counter to output a pulse or toggle the line.  If you use this property in conjunction with the initial count property, you can have the counter cound X number of edges and then toggle the output line:
    I hope this helps!
    Thanks,
    Justin M.
    National Instruments
    Message Edited by Justin M. on 06-12-2006 01:05 PM
    Attachments:
    Terminal Count Toggle.JPG ‏11 KB

  • Alazar count edges synchronization

    Hello,
    We have an Alazar AT9350 of which the acquisition has to be synchronised with the acquisition of a Count-Edges channel on an NI-6259 DAQ board. Running them synchronously is easy, for we run the Alazar board with a trigger signal (50KHz) that we can route to the NI board as well. However, starting them synchronously poses more of a challenge. The original solution was to input the trigger on the NI-board and reroute it when the count edges VI starts. However, the board needs one counter to create the sample clock (or receive the trigger signal), and one counter to output the signal. This leaves no counter for the Count-Edges channel (our NI board has only two counters). 
    I have come up with a possible solution for synchronisation, but it is a bit ugly. I output the task just after the start task VI to an indicator, and create a local variable. I connect a read version of the local variable to the acquisition while loop of my alazar board. My assumption: because the while loop has to wait till all data flows have presented data to him, the while loop must start synchronously with the start task. The actual program is much bigger, that's why I'm using a local variable here. A direct wire is also possible, but it would look even uglier. 
    I have put a snapshot of a simplified version of my program as an attachment. I realise I am not actually saving any data or outputting what the Count-Edges reads, of course this is different in my real version. 
    Is my method viable or should I use a different method? (or perhaps it is viable, but I should still use a different method).  
    Solved!
    Go to Solution.
    Attachments:
    labview program.JPG ‏114 KB

    Dear GerdW,
    Thanks for your suggestions.
    [quote]Probably not "real time"… When you use DAQmx to read your input data you can synchronize input channels. Have you looked in the example VIs for that case? [\quote] I use an NI board with DAQmx drivers to acquire the Count Edges. I use an Alazar board with their own SubVI's for the other acquisition. Therefore I cannot use the DAQmx synchronisation (which would've been quite easy indeed). And indeed, by "real-time", I of course mean that the amount of data I process per second is the same as the amount of data that I acquire per second .
    I changed my example, hope I finally understood you well. I added a wait function to the loop that sends the notification. Otherwise the notification is sent on the same time, but there is still no synchronisation because the notifier is retrieved upon reaching the loop (and it essentially does nothing). To make sure I know when I start the two loops synchronously, I will add a high-resolution relative seconds to both loops and subtract them in another loop. If there is a better way to test synchronisation I'd happily take any suggestions. (Though perfect synchronisation is the best, one or two ticks off won't do much harm). 
    Attachments:
    MinimalExampleWhileLoopSynchronisation.PNG ‏14 KB

  • NI 5124 count edges

    Hi,
    Im using distance sensor ELGO EMIX3 (10-30 VDC square wave output). Max resolution is 0.01 mm while using 4 edge triggering.
    Current principle is to count rising edges from the signal (attachment)
    Problem is that I'm not able to count pulses as fast as needed. maximum speed for the sensor is 4 m/s and I'm nowhere near! I Would be happy for 0.1 m/s speed
    Is there a better way to count signal edges using NI 5124
    regards,
    Asmo
    Attachments:
    countedges.jpg ‏55 KB

    Thanks HSD,
    Code you provided does the trick and the system is able to count edges very fast.
    First I had to upgrade SCOPE driver software, because I got several errors about memory overload and one like this:
    > Component Name: nimxslu proxy
    > File Name: This is NOT an error in nimxslu. See nimxsl/tStatus2KernelProxyWrapper.cpp for information
    > Line Number: 290
    > Status Code: -218802
    Further, i tried to modify your code to count rising edges from two sensor signals with no success.(attachment)
    I added input channels 0,1 and get waveform array size 2. I also ensured that waveform array consist different signals from channels 0 and 1. Anyway, total records still show pulses from only one channel. I guess this has something to do with fetch records property node?
    and further..
    I need to count both rising and falling edges from two channel input. Sorry, Im not familiar using scope property nodes. Is it possible to modify this code you suggested earlier to count rising and falling edges?
    Attachments:
    countedges2.jpg ‏68 KB

  • Count edges with hardware reset

    Hello all,
    I have a PCI-6220 and I would like to configure a counter to count edges with a hardware reset or use my counter to measure linear position without the B input, after words, only with the A input to count edges and the Z input to make the initial position.
    Somebody knows how?
    Thanks in advance, best regards,
    Paulo Carmo

    Duplicate Post
    John Passiak

  • Counting edges @ 90MHz

    Hi
    I'm looking for a solution to count edges from an external source without prescaler* @ 50 (90) MHz and read the counter (>=32bit) with a sampleclock of 100kHz.
    The M/X series Daq have counters  but the external sources routings limit the counter source to about 25MHz
    * I want every edge!
    Greetings from Germany
    Henrik
    LV since v3.1
    “ground” is a convenient fantasy
    '˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'
    Solved!
    Go to Solution.

    John P wrote:
    Hi Henrik,
    I think you're talking about the TB-2715, which is a screw terminal block that mounts directly to the PXI-6602.  I'd want to actually set this up before giving a recommendation--the TB-2715 might work out but I haven't tried it before at high frequencies.  I'm hesitant on recommending a screw terminal connector block because I have had issues with the SCB-68 passing through high frequency signals cleanly, but perhaps the 2715 doesn't have the same problems since it connects directly to the 6602.
    Close I was thinking about that housing with the connector and a matching PCB core in Ultiboard for custom designs
    In the past I have used the BNC-2121 cabled directly into the SMB clock out connector of a PXIe-6545.  Both the output impedance of the 6545 and the characteristic impedance of the SMB to BNC cable were 50 Ohms.  I actually did not terminate at the BNC-2121 as I found it wasn't necesary with the cable lengths that I was using (I don't recall exactly what they were).
    The spec claims a 75Ohm input impedance for the 6602, well the mismatch probably don't hurt that much if you have short cables.
    The spec for the max external source for the 6602 only goes up to 80 MHz, so anything above that would not be a guarantee.  From past experience I believe it should work under the right circumstances, but it's probably something that would have to be set up to know for sure.  Do you have the contact info for your Field Sales Engineer who might be able to arrange for a loaner 6602 for you to try out?  Or, perhaps you can simply order one and return it if it does not suit your needs (check with your sales representative to confirm NI's return policy).
    I'm in close contact with NI here in Germany and a PXI-6602 was already offered for a test * 
    Best Regards,
    A maybe root idea, but how about using a PXIbus breakout board and feed the 90MHz to one of the internal triggerlines? Would that drill a hole through the f-max limited input?
    Spoiler (Highlight to read)
    The PTB seems to be a good value customer
    The PTB seems to be a good value customer
    Greetings from Germany
    Henrik
    LV since v3.1
    “ground” is a convenient fantasy
    '˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'

  • NI PCIe-6351 Count Edges Channel error on fast TTL - Multiple Sample Clock pulses were detected

    Hello,
    I am trying to use a PCIe-6351 to record the arrival times of a fast TTL pulse stream (generated by an Excilitas/Elmer Perkin APD). The TTL pulses are 2.5 volt amplitude, 20 ns duration, with a gauranteed dead time of 50 ns between pulses. I am trying to use the the Count Edges function, with the  100MhzTimebase as the input terminal and the input to counter 0 (PFI8) as the sample clock. After a few seconds of acquiring data at 100 Mhz, the application throws the following error (-201314):
    "Multiple Sample Clock pulses were detected within one period of the input signal"
    I had thought that because there is 50 ns dead time between pulses, multiple pulses would never arrive within a single clock cycle of the 100 Mhz timebase. Is there any way this might not be the case? Alternatively, is it possible that the counter is triggering on some jitter around the edges of the pulses? If so, is there any way to filter such high frequencies without losing the 20 ns pulses?
    I have read through the forums for similar problems with photon detectors, but have not been able to resolve this issue. Thank you for the help.
    Matthew Bakalar

    It sounds like the input signal is being detected as multiple edges.
    The PFI filtering feature on the X Series card likely isn't going to be suitable for you.  The minimum setting is actually exactly 20 ns, which should in theory guarantee a 20 ns pulse passing through.  However, if the signal is high for anything less than that there wouldn't be a guarantee (depending on the phase of the timebase relative to the rising edge of the signal)--considering rise times and that there is evidently a glitch in the signal itself, it probably isn't actually a continuous 20 ns high time by the time the DAQ card sees it.
    What you should do instead:
    Configure a second counter as a retriggerable counter output (single pulse).
    Use your external signal as the start trigger for this counter output task.
    Set the initial delay, high time, and low time for the counter output task all to 20 ns (the minimum).
    Use the internal output of the counter output task as the sample clock source for the original edge count task.
    The counter output will be triggered when it sees the external signal, wait 10-20 ns, then generate a 20 ns pulse.  If there is a glitch on the trigger line during this 30-40 ns that the output is generating, it will be ignored.  The counter output will be re-armed in time for the next pulse given the minimum dead time of 50 ns between pulses.
    Best Regards,
    John Passiak

  • Count edges with 6036e

    Hello !
    I am currently trying to count photons with a PCMIA 6036e. 
    I have to detect a TTL signal ; each photon correspond to a pulse. So I tried to count rising edges, since one rising edge = one photon. I want to use either digital line or counter. Moreover, I have to count the rising edges for a limited time (typically 1s).
    I have tried several VIs, but none of them work. I either don't have an error message, but only 0 as a result, or an error message saying data were overwritten before they could be read.
    The problem does not come from the card, since it can count the rising edges in MAX. I have also tried examples such as "count digital events", but they give me the same error.
    I would appreciate any help !
    thanks,
    Camille

    Hello,
    Check carefully the wiring of your signal to the DAQ board; there is to main input for counter application, the source and the gate. Depending on the measurement you do, you have to wire your signal to the gate or to the source. In your case, the acquisition type should be a simple event counting. Using CTR0, the input signal should be wired to PFI8 (PFI3 for CTR1).
    The specification of the PCMCIA-6036E mention that the minimal pulse duration you can handle is 10ns in edge detect mode. If the pulse you measure  are shorter, you will not be able to see it.
    Regards, 
    .mrLeft{float:left} .mrInfo{border-left:solid 1px #989898;font-size:x-small;color:#989898}
    Mathieu R.  
      CTD - Certified TestStand Developer / Développeur TestStand Certifié  
      CLAD - Certified LabVIEW Associate Developer  

  • USB 6008 Count Edges

    I am trying to count the edges on a signal with a period of 50us using the counter on a usb 6008.  Is this possible or is the period to small?

    Hi there!
    From the specifications listed at http://sine.ni.com/nips/cds/view/p/lang/en/nid/201986 and http://www.ni.com/pdf/manuals/371303l.pdf the minimum input pulse width is 100ns. Seeing that the period you are trying to measure is 50us, considerably bigger, then it should be fine.
    I hope this clarifies,
    Liam A.
    National Instruments
    Applications Engineer

  • Why can't it count edges-Error -200141

    I'm using a very precise shaft quadrature encoder with 400 pulses per revolution. I'm simply trying to test it before I incorporate it into my VI. I've been using the DAQassistant to try and configure it. I've got a PCI-6036E with a BNC-2120 accessory. To start I hav been just trying to read an edge count of one of the channels. In this case I'm reading from CTR 0 Gate. When I try to run the edge count test as soon as I move the shaft at all I get an error(Error -200141).
    It says I should try using DMA. I've looked into this and everything I have found appears to indicate that the  PCI-6036E has "dma", however I have been unable to identity if it is being used or not.
    Is my DAQ simply not capable of reading this fast of a signal?

    Hi Erik!
    How quickly are the counter events occurring? The counter source frequency of that card is 20MHz which should be able to keep up with a quick signal. 
    I see you found the knowledgebase article that references this particular error code (found here). The solutions mentioned there are worth looking at.
    The PCI-6036E only has one DMA channel available to it. So if you are only using one channel, DMA is being used by default. Any other channel that is being used at the same time is then defaulted to interrupts. 
    If you would like to be sure that your task is using DMA, you can include a property node to force the channel to use DMA (still, only 1 channel can use it at a time).  See the attached image on how to access that property.
    Also, be sure that you are not doing too many operations within the loop that is reading this data. That way the software can pull the data off the buffer as fast as possible.
    Peter E
    Applications Engineer
    National Instruments
    Attachments:
    DMA Counter.png ‏17 KB

Maybe you are looking for