NI-9361 X2 Encoding without a second channel

[elibarber]

I have VR sensor with a diode and a tooth count of 60. "Configure Edge Counting Simple" Gets me 1 pulse per tooth pass, but want to configure as X2 encoding to get double the resolution--that is, to double my resolution.

"Configure Quadrature Encoder Position" seems promising, but requires B terminal to be wired in. I  am using all my channels independently. How can I count the rise and falls on a single channel? Surely it can be done without have having to have a hard wired B terminal as on or off?  

https://www.ni.com/docs/en-US/bundle/ni-9361-getting-started/page/inc-encoder-measurement.html?srslt...

[Xonmyth]

Hello elibarber,

---

@elibarber wrote:

How can I count the rise and falls on a single channel? Surely it can be done without have having to have a hard wired B terminal as on or off?  

---

With only one channel (A), you can only keep track of the edge change i.e., rising edge do something, falling edge do something. You will have no way to tell if you are going clockwise or counterclockwise. 

Last value is false & New is value true = Rising Edge = Count up or down (choose one).

Last value is true & New is value false = Falling Edge = Count up or down (choose one).

Edit: Use FPGA, if you can for best results and do some googling to find tons of examples on how to do this in LabVIEW. 

Channel/ Track B is used identify the direction of the rotation. For example, leading with a rising edge on B, followed by a rising edge on A increment the count. If opposite, decrement the count.

Some quadrature/ incremental encoders have a Z channel, this helps you set a reliable 0 position.  You would typically use Z to reset your counting. 

With one channel, you will only know you are going somewhere but you will not know where.

[elibarber]

Xonmyth,

Yes, I only care about the pulse count. Not about the direction. Right now if i have a low speed i can bounce between 10-11 pulses per measurement which shows up on my gauges and charts. If I measure Rising and falling then divide by 2, I "think" the result should be 10.5. Measuring rising and falling seems to be to be an easy way to increase resolution, especially since with my gear its on 50% of the time regardless of speed.

I thought about using FPGA instead of the counter. this limits me to the 40MHz clock instead of the 100Mhz clock internal to the card. But would still work? Something like this?

[Xonmyth · Accepted solution]

It will look something like this:

You will use single cycle timed loop. I have only seen a default clock of 40Mhz for these. If you right click on the "Source name" terminal of the SCTL, you will be able to see the default clock your system has. If you do not see 100Mhz, use can use a derived clock. 

Personally, I do think it would be a bit of overkill. But if your application requires it, sure, use it.

[elibarber]

Genius!

Yes I think i will do that. + I will add a 2nd loop for safely writing to a user defined variable without violating any timing restraints. Luckily the NI-9361 has a digital filter built in.

[Xonmyth]

Sweet! Good luck!

[GerdW]

Hi elibarber,

---

@elibarber wrote:

I thought about using FPGA instead of the counter. this limits me to the 40MHz clock instead of the 100Mhz clock internal to the card. 

---

Is that limit so crucial?

• You have a tooth wheel of 60 tooth/rev, this gives 120 edges/rev.
• At 10000rpm you get 120*10000/60 = 20'000 edges per second, or 50µs per edge.
• The 40MHz clock of the FPGA allows you to read the DI each 25ns - or 2000 times between each edge.

So why do you think the FPGA system clock will be limiting your speed measurement?