Rotary Encoder + ni usb 6009

[Kevin_Price]

Honestly, the code was awfully hard to read with all the long, crossed boolean wires.  I really can't say with any confidence whether it's fully correct, but I did enough deciphering to say that it *appears* that you attempted to put together correct logic up through the results of the multi-input OR functions.   Whether or not every single wire connection is correct I'm not so sure, but I see the intent and it looks generally right. 

What you do after the multi-input OR functions needs some work though.  First, you're only retaining the result of a possible increment in your shift register, ignoring any need for decrement.  Second, I'd really recommend that you track your count with an integer shift register, and only apply the 0.72 scaling factor after the fact.   Third, the False cases where you explicitly add or subtract a 0 don't make any sense.  Just pass through the original value with no addition or subtraction operation!.

-Kevin P

[RavensFan]

All of those comparisons, with 0, 1, 2, 3, should all be blue integer wires.

When get the dynamic data type blue wire out of the DAQ Assistant, you should immediately convert that to a double.  Then do the comparison and work with integers.

DDT wires just hide what is going on making it uncertain if you are dealing with scalars or arrays, numbers or booleans.  Converting it to a known datatype early eliminates the confusion.

[valiora]

Hi guys,

Thank you so much. I appreciated your help, I really do.

I precisely followed your tips about my problem and now looks something is chanced.

I convert into integer the values, I take into account the decrement condition, and I re-wire the false condition (as I mentioned, I'm just beginner in LabView so thanks again to correct my mistakes).

Now, I noticed something a bit weird. My encoder has 500 ppr (https://uk.rs-online.com/web/p/rotary-encoders/7951081/), so doing simple math the resolution should be 0.72° (360°/500ppr). But, in my Front panel, I see values that look like multiply for a 4 factor. For instance, I get 1440° instead of 360°, or 360° instead of 90°.

How is it possible? Could those condition in multiple OR GATE that maybe affect the conditions? Could be that they send 1 for each input value as output, so sending 4 values each cycle? Because my idea is that multiple OR GATE should provide me with just one value each iteration.

If you have any suggestions, please they would be appreciated.

Thank you again.

Anyway, you'll find attached my VI in 2016 version.

[Kevin_Price]

The factor of 4 is entirely normal for quadrature.  Have you still not done more general reading on the topic?

500 ppr describes each channel A&B individually.   Together, they are a quadrature pair that exhibit 4 quadrature states per full cycle.   Thus, 500*4 = 2000 states per rev.

Your other results suggest a pretty likely verification of your decoding process once you account for the additional factor of 4.  Once you're sure, challenge yourself to "clean it up".  Make it easier to follow the wiring and logic, add comments.

Or consider my attached modification, that uses the method I referenced up in msg #18.  See how much cleaner the code can be?   This makes it easier to understand, debug, and modify.

-Kevin P

[Kevin_Price]

Oops, on closer inspection, I had a typo or whatever you call the wiring version of one.  Attached is a fix.  I also changed over from shift registers to feedback nodes, to help illustrate another option.

(Note that either way there's an possibly-wrong assumption about the initial quadrature state.  Robust code would need to handle initialization in a more correct, but more complicated way.)

-Kevin P

[RavensFan]

Set the feedback nodes to globally initialize and feed the same wire into the initializer that you do into the FBN.  That way you aren't assuming any state to exist prior to the first call.  The first call will have the same value as the initialized value and you aren't making an increment or decrement based on an incorrect assumption of state being 0.

[valiora]

Wow! 

This implementation looks very nice! Thank you! I think I'll go for that one.

But I have two questions regarded your implementation:

1) In the lookup table, based on #18 comments that one attached should be the real one, is it?  (see lookuptable screenshot)

2) In the calculation part at the end (when the wire goes to graph and indicator), if I use (as on screenshot) "new" calculation works correctly, using "old" it does'not. (see calculate screenshot)

So I think, still, I have not understood how is it possible that ppr 500 means 2000cycles (so the resolution will be 0.18° and not 0.72°). I have definitively not clear this point. May you explain again? Sorry about that.

---

@Kevin_Price wrote:

(Note that either way there's an possibly-wrong assumption about the initial quadrature state.  Robust code would need to handle initialization in a more correct, but more complicated way.)

---

And with this, what do you exactly mean?

Thank you again, your help is again really appreciated.

[RavensFan]

---

@valiora wrote:

---

@Kevin_Price wrote:

(Note that either way there's an possibly-wrong assumption about the initial quadrature state.  Robust code would need to handle initialization in a more correct, but more complicated way.)

---

And with this, what do you exactly mean?

---

Here it is cleaned up with the feedback node so that the it is initialized with the first call of the node so you won't have an incorrect state transition on first call.

[valiora]

Ok, thank you.

What did exactly mean? In this way I have properly 0 when I run the code for the initial iteration, is it?

And still, why has the factor to be 0.18° and not 0.72°, given my 500 ppr encoder?

[Kevin_Price]

I wasn't careful enough (again).  RavensFan corrected my scaling calc and also eliminated the feedback node initialization issue I mentioned.

(For scaling, I meant to invert the input for the "4" constant, but forgot.  Inverting the input would mean "divide by 4" instead of "multiply by 4".  I kept it separate to try to better illustrate the distinction between the 0.72 deg per full cycle of channel A and the 4x finer resolution available when decoding quadrature.   But I carelessly forgot to invert the corresponding input terminal.)

Msg #24 has more summary on why a 500 ppr encoder yields a *quadrature* resolution of 2000 increments per rev, or 0.18 deg each.

-Kevin P