Now, digital logic isn't all that helpful without the ability to store any data, so let's work with some basic memory circuits.  There are a whole lot of variants, but we'll be starting with the D flip-flop.  This circuit is implemented with a single chip (the SN74HCT74N) which has four inputs (Set, Reset, Data, and >, the Clock) and two outputs($Q$ and $\overline{Q}$), as shown below. Note that there are two flip-flops per chip.

Pinout for the SN74HCT74N dual D flip-flop chip.  Note that each side of pins has an independent flip-flop circuit.	Original courtesy of https://commons.wikimedia.org/wiki/User:Inductiveload

In typical operation, the output $Q$ is the same as the last voltage seen at the data input $D$ when the clock signal > made a transition to high.  Typically the other output $\overline{Q}$ is the negation of $Q$ (i.e. if $Q$ is high, $\overline{Q}$ is low). The Set and Reset inputs are typically held high, but when they're pulled low (0V) S will set $Q$ high and $\overline{Q}$ low and R will do the opposite. This happens regardless of the clock or data inputs.

For our purposes, we're using this chip as a single bit of memory: the output $Q$ remembers the input $D$ when the clock > transitions to +5 V.

To start off, we'll want to rebuild our logic-level button similarly to the previous lab.

A circuit for saving the last clock state, controlled by a button. Note that Set and Reset should be connected to 5V for this to work at all.

With the function generator set up to produce a slow (1Hz) 0-5V square wave, let's try a few things

Verify that the output $Q$ only changes when you press the button AND the function generator signal is the opposite of $Q$, and that it otherwise saves its state. In other words, pushing the button should set $Q$ to the function generator's state (+5V or 0).
Use a wire to pull the $S$et input to ground, and verify that $Q$ behaves as it should

Last lab we made some discrete logic circuits that would tell us the exact state that our encoder circuit was in. Using a Flip-flop we can do something else useful: generate a signal whenever an encoder output changes. By doing this we can sync the information about changes in the state of the encoder with our clock, making the information much more usable by digital systems.

To start, let's consider the circuit shown below:

A D-flip-flop circuit (left) used as input for an XOR logic gate (right). The eXclusive OR operation outputs high if the inputs are different and low if they are the same.

Next, repeat the same for the other output of the encoder:

Now that we can detect if either A or B changes, we can take those to outputs together into another OR gate (or XOR, since we should never have both to change at once) to make a “change detected” output

So, if A is always changing state before B, then our encoder is turning clockwise. Likewise, if B is leading A, then we're turning counterclockwise. While this is simple to put into words, it will take a bit to put it into logic circuitry.

A visualization of a turning rotary encoder. Note that the outer ring represents A and the inner ring represents B.

Let's consider the following circuit:

Here, we are using an eXclusive OR (XOR) gate to check if exactly one of A or B is high, and if so to output a signal. If A is leading B, then this gate will change from low to high whenever A changes state.

Likewise, if B is leading A, then the gate will change from low to high whenever B changes state.

Now, we would like to make something that tells us both which signal is leading (for direction) at the instant that a change in state occurs. However, you may notice a problem here. Our direction indicator changes at the same time that our signal changes! If there's any delay in our circuit this could end up resulting in very unreliable behavior.

As a fix, let's consider a case where we save the state of B at a rate quick enough that it happens between changes in either B or A. We'll call the saved value B' here. Now the behavior is much more robust, resulting in the values we'd expect every time (i.e., A XOR B' is always 1 at times when a value is changing and A leads B, and always 0 at times when a value is changing and B leads A.)

Now consider the other direction:

Do they behave as expected?

By counting the state changes from our rotary encoder and noting the direction, we can record how far it has been displaced from its starting point. While we could chain multiple flip-flops together to make a counter with one bit per flip-flop, that would get cumbersome quite quickly. Furthermore, a basic flip-flop counter can only count upwards. Fortunately for us, there are already purpose-made chips that do what we need!  Here's the setup for a 4-bit counter, the 74HCT191:

Full pinout of our 4 bit counter.	Configuration to turn your chip into an up/down binary counter.  It isn't nearly as bad as you'd think!

While this chip has quite a few features, we'll configure it to do two: count up and down in binary.  Wire up the chip as shown above at right.

Instead of looking at each output on the scope, we can use LEDs as indicators here to show what's going on visually

In addition to just counting upwards endlessly like a flip-flop clock, we can also count downwards with the 74HCT191. Whenever the Up/Down pin is low the chip counts up, and when it is high it will count down.

In combination with our logic that we've created for our rotary encoder, we can now build a circuit that should count how many fractional turns we've made from when it is initialized.

Now, unless you're exceptionally lucky, it probably didn't work at all as intended. To see why, hook up your scope to the D/U and CLK (5 & 14) pins of your counter and zoom your scope in to a 500ns timescale. While some signal transitions will look nice, you'll see some here that others will have high frequency (10's of MHz) noise. Our rotary encoder does not provide as clean of a signal as our function generator, if you look at $V_{out,A}$ or B on the scope at around a 100 $\mu$s time scale you can find instances where the output changes multiple times in a row. This can be due to the mechanical contacts vibrating in the encoder, which is a hard thing to eliminate entirely. There are ways to “debounce” the signal (hello Schmitt trigger!) that could help here, but this is the end of today's lab.

While we could buy fancier chips or start chaining multiple ones together, implementing this in hardware can become tedious quickly. However, this is exactly the sort of problem that FPGAs are great at addressing, as it is straightforward to have it simulate numerous logic family chips all at once. Of course, you could also write software to read and interpret inputs to accomplish the same task. But if you either need speed (FPGAs can do some operations much quicker than an equivalently priced microcontroller) or capacity (FPGAs also tend to have many inputs that can receive data in parallel) then an FPGA might be the solution for you.