Multiple sample clock pulses were detected within one period of the input signal error

[randomguy77]

What do you mean? I want to count the rising edges, of CH A, between one period of the index. I don't need to count the index. The encoder I am using is 4PPR, and there are 4 Ch A rising edges during a period of the index.

CH A is yellow, and the index is blue.

[aeastet]

Is the blue line measured or calculated?

[randomguy77]

That image was from a scope. I measured both signals, to ensure they were correct, and just screen grabbed the scope screen to post it here.

[Alexander_Sobolev]

This one https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8g1SAC&l=en-US says

2. Also there cannot be two sample clock pulses within one cycle of the input signal. To avoid this you can set the sample clock frequency to half of the input signal frequency.

I think it means timeout waiting for clock pulse. Try to reduce the frequency you set in Timing VI

Also check if this applies

https://forums.ni.com/t5/Counter-Timer/PFI-channel-crosstalk-Error-Code-201314/td-p/3043909 

Solution there was to add a digital filter because sometimes it registered a short noise clock pulse.

[Kevin_Price]

Oops, queued this up for a reply, then came back to it a couple hours later without refreshing to see that there's been a lot of conversation in the meantime.  Oh well, here it is anyway...

----------------------------------------

The error you're getting is happening at the hardware level and isn't *caused* by your code.  My guess is that the index pulse signal isn't clean and a single clock edge manages to register as multiple edges in rapid succession.

Dunno your device, but you may be able to use DAQmx property nodes to do digital filtering on that signal.  So you may be able to *resolve* your problem using additional code.

-Kevin P

[aeastet]

Try this and see if you get a different answer.

[Kevin_Price]

Let me recommend some changes for the sake of diagnosing and troubleshooting this issue.

Try capturing samples for dozens of revolutions.  Find the count differences for every successive pair of samples and post the result here.  Let's start getting a better sense of how regular or irregular things look.  I see no obvious reason why you'd get count differences of 1 or 2.

-Kevin P

[randomguy77]

aeastet:

The snipped you posted appears to count the A edges precisely, but does not have a stop for the rising edges of the index.

Kevin:

I had the loop run 25 times, and captured a few runs results shown below.

[Kevin_Price]

Ok, that data is *nothing* at all like what it should be.  You don't have a small intermittent problem, you have a deeply systematic problem.

Given the scope trace and your description, you *should* see count values that increment by 4 with each sample.  Given the lack of sync between encoder and "index" pulse, I wouldn't be alarmed by an occasional increment of 3 or 5.

The runs of 0 values are almost certainly caused by getting a task error (perhaps the one you started the thread with), so those "make sense" even while helping to indicate trouble.

All the other values and increments do *not* make sense.

I kinda suspect you may not have your digital signal grounds referenced together.  Or there's some other signal incompatibility between your encoder, motor, and DAQ device.  Your USB-6341 will want single-ended digital logic.  TTL will be supported, perhaps also CMOS.  You can run into weird problems if you directly wire differential sensor outputs to a single-ended digital DAQ device.

-Kevin P