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

Similar Messages

Buffered event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

At irregular occasions I need to grab counts from several counters, and buffering the counts must be done simultaneously for all counters. I'm modeling my approach after zone.ni.com/devzone/cda/tut/p/id/5404 which someone kindly pointed out in an earlier thread. However, that example only uses one counter, and you can't test the synchronization with only one counter, so I am using two counters configured the same way, and they're wired to a single benchtop signal generator (for example at 300 kHz).
What I want to do, I can test in a loop with a somewhat random wait in it. I want to drive a hardware digital output line high for a few ms and then low again. The hardware line is physically connected to terminals for my timing vi's Sample Clock Source and so will cause them to buffer their counts for later reading. After I pulse this line, when I know new good buffered counts await me, I want to read both my counters. If their bufferings are simultaneous, then each counter will have counted the same number of additional counts since the last loop iteration, which I can check by subtracting the last value sitting in a shift register and then subtracting the two "additional counts" values and displaying this difference as "Diff". It should always be 0, or occasionally +1 followed immediately by -1, or else the reverse, because buffering and a count could happen practically at the same moment.
When I do this using a flat sequence to control the relative timing of these steps, so the read happens after the pulse, the counters often time out and everything dies. The lengths of time before, during, and after the pulse, and the timeout value for the read vi, and the size of the buffer and various other things, don't seem to change this, even if I make things so long I could do the counting myself holding a clipboard as my buffer. I've attached AfterPulse.vi to illustrate this. If I get 3 or 10 or so iterations before it dies, I observe Diff = 0; at least that much is good.
When I use two flat sequences running in parallel inside my test loop, one to control the pulse timing, and the other to read the counters and do things with their results, it seems to work. In fact, Diff is always 0 or very occasionally the +/- 1 sequence. But in this case there is nothing controlling the relative timing such that the counters only get read after the pulse fires, though the results seem to show that this is true. I think the reads should be indeterminate with respect to the pulses, which would be unreliable. I don't know why it's working and can't expect it to work in other environments, can I? Moreover, if I set some of the pulse timing numbers to 1 or 2 or 5 ms, timeouts start happening again, too. So I think I have a workaround that I don't understand, shouldn't work, and shouldn't be trusted. See SeparateSequence.vi for this one.
I also tried other versions of the well-defined, single sequence vi, moving the counter reads to different sequence frames so that they occur with the Sample Clock Source's rising edge, or while it is high, or with the falling edge, and they also often time out. I'll post these if anyone likes but can't post now due to the attachment limit.
Here's an odd, unexpected observation: I have to sequence the reads of the counters to occur before I use the results I read, or else many of the cycles of this combine a new count from one counter with the one-back count from the other counter, and Diff takes on values like the number of counts in a loop. I though the dataflow principle would dictate that current values would get used, but apparently not so. Sequencing the calculations to happen after the reads fixes this. Any idea why?
So, why am I not succeeding in taking proper control of the sequence of these events?
Thanks!!!
Attachments:
AfterPulse.vi ‏51 KB
InSeparateSequence.vi ‏49 KB

Kevin, thanks for all the work.
>Have you run with the little execution highlighting lightbulb on? -Yes. In versions of this where there is no enforced timing between the counter and the digital line, and there's a delay inserted before the digital line, it works. There are nearly simultaneous starts on two tracks. Execution proceeds directly along the task wire to the counter. Meanwhile, the execution along the task wire to the digital high gets delayed. Then, when the digital high fires, the counter completes its task, and execution proceeds downstream from the counter. Note, I do have to set the timeout on the counter longer, because the vi runs so slowly when it's painting its progress along the wires. If there is any timing relationship enforced between the counter and the digital transition, it doesn't work. It appears to me that to read a counter, you have to ask it for a result, then drive the line high, and then receive the result, and execution inside the counter has to be ongoing during the rising line edge.
>from what I remember, there isn't much to it. There really aren't many candidate places for trouble. A pulse is generated with DIO, then a single sample is read from each counter. -Yup, you got it. This should be trivial.
>A timeout means either that the pulse isn't generated or that the counter tasks don't receive it. - Or it could mean that the counter task must be in the middle of executing when the rising edge of the pulse arrives. Certainly the highlighted execution indicates that. Making a broken vi run by cutting the error wires that sequence the counter read relative to the pulse also seems to support that.
>Have you verified that the digital pulse happens using a scope? -Verified in some versions by running another loop watching a digital input, and lighting an indicator, or recording how many times the line goes high, etc. Also, in your vi, with highlighting, if I delete the error wire from the last digital output to the first counter to allow parallel execution, I see the counter execution start before the rising edge, and complete when the line high vi executes. Also, if I use separate loops to drive the line high and to read the counter, it works (see TwoLoops.vi or see the screenshot of the block diagram attached below so you don't need a LV box). I could go sign out a scope, but think it's obvious the line is pulsing given that all these things work.
>Wait! I think that's it! If I recall correctly, you're generating the digital pulse on port0/line0... On a 6259, the lines of port 0 are only for correlated DIO and do not map to PFI. -But I'm not using internal connections, I actually physically wired P0L1 (pin 66) to PFI0 (pin 73). It was port0/line1, by the way. And when running some of these vi's, I also physically jumper this connection to port0/line2 as an analog input to watch it. And, again, the pulse does cause the counter to operate, so it clearly connects - it just doesn't operate the way I think it is described operating.
For what it's worth, there's another mystery. Some of the docs seem to say that the pulse has to be applied to the counter gate terminal, rather than to the line associated with the sample clock source on the timing vi. I have tried combinations of counter gate and or sample clock source and concluded it seems like the sample clock source is the terminal that matters, and it's what I'm using lately, but for example the document I cited, "Buffered Event Counting", from last September, says "It uses both the source and gate of a counter for its operation. The active edges on the gate of a counter is used to latch the current count register value in a hardware register which is then transferred via Direct Memory Access...". I may go a round of trying those combinations with the latest vi's we've discussed.
Attachments:
NestedSequences.png ‏26 KB

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.

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

PCI-6220 COUNTER (Labview): Does "Sample Source" = "Gate Source"?

Hello,
I'm using Labview, DAQmx, PCI-6220 (Counter0). I connected an incremental encoder signal to the source input of CTR0. In Labview, the "DAQmx Timing" vi requires that the "source" input be wired. Does this "source" actually mean the source of the sample clock vs. the "Source" input to the counter?
Thanks for your assistance,
Chris

Chris,
When you talk about using a DAQmx Timing vi, I assume that you are performing
buffered event counting or any other task that performs buffered acquistion.
You can see an example that performs buffered event counting in NI Example
Finder called Count Digital Events Buffered - Continuous. The DAQmx
Timing vi in this example is used to read the current state of the counter
into memory at a constant rate. The source input of the Timing vi in this
case means the source of the sample clock. This clock is what determines
when the counter state is read and stored into a buffer.
If you are performing event counting, and do not need buffered acquisition (no
sample clock), you can look at example Count Digital Events.vi in Example
Finder. In this example no DAQmx timing vi is used.
Regards,
Jesse O.
Application Engineering
National Instruments
Jesse O. | National Instruments R&D

Using AI Sample Clock to Trigger Counter Samples

My basic question is: Is the ai\SampleClock signal only active while an analog input task is running?
The details are:
I have an X-series PCIe-6321 multifunction DAQ card. It is controlling a SCXI chassis and has a SCXI-1180 and SCXI-1302 so I can control analog inputs of the chassis as well as access the 4 counter on the card. My application requires that I use all 4 counters to measure a frequency input signal and synchronize the samples to the analog input signals. I have created 5 tasks, 1 for the AI and 1 for each counter.
I am using LabVIEW 8.6.1 with the latest NI-DAQ drivers on and 64-bit Vista OS
1. Are there any driver or hardware restrictions that would cause this solution not to work?
2. Can I use the ai\SampleClock as in input sample clock for each of the frequency tasks? If I do this will the sampling start be syncronized? I.e. if I start each of the frequency tasks first, will they wait until the AI task is started before they start sampling?
3. If that doesn't work, do I need to route the sample clock from the AI task to a PFI line (PFI1) and then use that as input to the frequency task sample clock?
I usually do option 3 when synchronizing two cards in PXI chassis and only use the software task start in stead of of synchronizing on a digital start, since the sample clock will control the samples anyway. I need to know if the same behaviour works with the scenario above.
Thanks,
Bob
Prolucid Technolgies Inc.
Solved!
Go to Solution.

Hi Bob,
I can confirm that the ai/SampleClock will only be active while the AI task is running. As far as the other questions go:
1. You'd have to provide more information about what you looking to do exactly, but there is no problem with routing the sample clock of the Analog Input task to be used with the Counters. I would read through the section of the X Series User Manual that discusses sample-clocked frequency measurements (starting on page 7-16) for some more information about what is actually going on during this configuration to make sure it suits your requirements.
The frequency of the signal to be measured should be at least twice as fast as the sample clock of your AI task.
2. You can indeed route the signal to all four tasks at the same time (you can refer to the Device Routes page in MAX to double-check routing restrictions). The sampling will be synchronized provided the four counters are started before the AI task, but the counters will be armed at different times unless you configure an Arm Start Trigger (see page 7-45 of the X Series User Manual). I would consider using the ai/StartTrigger if you wish to do this.
The effect of not arming the counters at the same time would be a different number of periods to average on each counter for the very first sample (assuming averaging is enabled). This might not be a big concern but I just wanted to point it out.
3. The routes are available internal to the board so external routing isn't necessary, you can just specify to use the AI Sample clock for the clock of each counter and the routes will be made for you. If you prefer to export the signal on a PFI line and route it back in on a different PFI line this option is also available to you but shouldn't be necessary.
I hope this helps you get started. I'd make sure to take a look at chapter 7 of the X Series User Manual if you get a chance since it describes how all of the counter configurations work in more detail. If you have any related questions don't hesitate to post back.
Best Regards,
John
Message Edited by John P on 12-01-2009 07:52 PM
John Passiak

How to use external timebase for Two Edge Separation measurement with PCIe 6351

Hi
I am working with PCIe 6351 x series DAQ card.
counter measurements.
Here i need to measure the time/no edges between two edges. Falling to Raising of two signals.
I got the measurement with internal time base.
here i need to synchronize the measurements with external clock from the external setup.
so i need to use that external clock,timebase for the counters.
Any solution please..
Regards,
Hari

First, the VI you mention is NOT for STC timer/counters. Therefore, it won't work.
If you want to get the time interval between two edges, you want to use the Functions -> Data Acquisition -> Counter -> Count Events or Time VI. This will do the function you are looking for.
Mark

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

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

Using a Counter to error-check External Sample Clock

Hi all,
I am newish to labview and am working on a data acquisition project. I've managed to get the basics under control, but here's my situation and question...
-- I am using the S-6123 card to capture and record data on two or more AI channels. I am using a rotary encoder to generate a pulsetrain that I am using via PFI0 as the sample clock for recording the AI data.
-- This rotary encoder gives 720 pulses per revolution and an index pulse once per revolution.
-- In my data acquisition, I am pulling 1440 samples at a time with the DAQmx "read" function.
I have been experimenting with counters and can get the RPM out of the pulse trains well enough, however I was wondering...
Is there some way to use the 2 counters on the card (and signal routing of the two pulse trains) to double-check that the 1440 samples I take correspond to two exact revolutions, and that I'm not getting ahead of or behind the rotation of the encoder due to missing clock pulses or reading false pulses. I have a couple of ideas on how to attempt to do it, but to me they don't seem very reliable or efficient, so I thought I'd put it to the experts to point out of there is a more obvious way of doing it.
I have attached a pdf of the specifications of the encoder family, the pulses that will be output are on the right hand side of page 2.
With many thanks in advance,
Peter
Message Edited by mumech on 07-22-2008 01:05 AM
Attachments:
REncoder Specs.pdf ‏312 KB

Thanks very much for your reply. I had come across the use of counters with angular encoders but hadn't quite thought of the concept in this way.
I will have to experiment a bit over the next day or to see what this is capable of, the examples seem quite comprehensive, however I'm not sure if I will run into issues due to the fact that I am using the rotary encoder as the sample clock for my analogue data.
Would I indeed be able to compare these values (ideally check the position of the encoder after each set of data acquisition) without a "third party" sample clock common to both? (which isn't appropriate for this application)
If I was only running at low speeds, I might be able to implement this by simply checking the position of the encoder after each read of the data. However, at higher speeds there might be synchronization issues due to the buffering of the analogue data. So when getting the measurement from the encoder counter chances are the analogue data was acquired at an earlier time.
I know I haven't worded this very well, but how might I synchronise this error checking method?

X series PCIe-6351 encoder reset

Hi,
I am working on the X series PCIe-6351 encoder input by using an example gpctex4.cpp from X series DDK. It seems counting fine. However, it doesn't reset the counter even it is setup as follow:
counter->Gi_Mode_Register.setGi_Loading_On_Gate(nCounter::kReloadOnStopGate, &status);
counter->Gi_Mode_Register.setGi_Trigger_Mode_For_Edge_Gate(nCounter::kGateLoads, &status);
and
counter->Gi_Counting_Mode_Register.setGi_Index_Mode(indexMode, &status); //indexMode = nCounter::kIndexModeSet;
Can anyone tell me what is wrong? Do I miss something?
Thanks,
Larry

LarryL wrote:
I am working on the X series PCIe-6351 encoder input by using an example gpctex4.cpp from X series DDK. It seems counting fine. However, it doesn't reset the counter even it is setup as follow:
counter->Gi_Mode_Register.setGi_Loading_On_Gate(nCounter::kReloadOnStopGate, &status);
counter->Gi_Mode_Register.setGi_Trigger_Mode_For_Edge_Gate(nCounter::kGateLoads, &status);
counter->Gi_Counting_Mode_Register.setGi_Index_Mode(indexMode, &status); // indexMode = nCounter::kIndexModeSet;
Can anyone tell me what is wrong? Do I miss something?
Just closing the loop in case others search and find this post later. Larry shared his resolution in another thread:
X series PCIe-6351 encoder reset
http://forums.ni.com/t5/Counter-Timer/X-series-PCIe-6351-encoder-reset/m-p/1996057#M10458
Joe Friedchicken
NI VirtualBench Application Software
Get with your fellow hardware users :: [ NI's VirtualBench User Group ]
Get with your fellow OS users :: [ NI's Linux User Group ] [ NI's OS X User Group ]
Get with your fellow developers :: [ NI's DAQmx Base User Group ] [ NI's DDK User Group ]
Senior Software Engineer :: Multifunction Instruments Applications Group
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)

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

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

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

NFS Commnication channel errors for deleting and placing

Hi All,
I was trying File to file scenario.
I am picking the file from App server(AL11) using NFS Adapter and the processing Mode is Delete
In comm channel monitor it showing an error as
Sender channel error:
Error: File '/staging/INTERFACE/SAP/ca/kar370.txt' - deleting after processing failed
Same way while placing the file
Receiver channel error:
Error: Message processing failed: FileNotFoundException: /staging/INTERFACE/SAP/ca/test120110906-122051-980.txt (Permission denied)
Whether i dont have the permission to delete and place the file from and to the App server(AL11)?
What is the procedure in order to make it possible.
Thanks
Sai

Hi All,
Thanks to every one.
The problem is solved ,
Basis Guy has given the permissions, and i am able to place and delete the files .
Thanks
Sai

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

Similar Messages

Maybe you are looking for