Hi all!

My name is Mike and this is my first post on All About Circuits! I am working on trying to bring an old industrial robot back to life and have come across a need to design a circuit. I am very hopeful that I can engage with everyone here to help me along the way.

In my day job I am an industrial controls engineer, designing large control systems using commercial products. I studied Mechanical and Electrical Engineering in college with a focus in control systems and manufacturing. Besides tinkering with electronics, my hobbies are machining, rock climbing, and kayaking. I am definitely out of my comfort zone on this one. I have designed maybe a dozen simple circuit boards, but never a discrete digital logic circuit. My college path mainly covered control theory and I never took a digital logic course. Anything I know has been self taught, so please forgive any glaring errors in my efforts into this so far.

Here is a link to the project log on the robot: https://www.hobby-machinist.com/threads/mikes-scara-robot.84001

Problem Description:
The motors in my robot use shaft angle measuring encoders that have many signals multiplexed into a digital channel. This was a proprietary design of the company that built them. I wish to use them with servo drives that I have access to, however I first need to decode the multiplexed signal to get back the original signals that created it. I have decoded the signal in its entirety, but now I need to design a circuit to do that in real time.

Here is an example of that signal. The A and B channels are traditional quadrature incremental encoder signals. The green trace (channel D) is the multiplexed signal which needs to be decoded into 4 outputs. Ignore the black trace, it was a signal internal to the encoder PCB.



This circuit needs to evaluate states and generate outputs at a frequency ranging from 0-683kHz. For this reason I ruled out micro-controllers with interrupts. This would probably be very easy to do with an FPGA, but I have no experience with them and the cost would make this circuit less attainable. Finally I came to designing a discrete digital circuit using sequential logic.

In my head the circuit would do two things. Identify the pattern present on the green trace (the "Pattern Detector") and produce four outputs based on the pattern detected (the "Output Generator").

To keep this post simple, I have kept most of the details omitted. I have attached a circuit specification (it is still a work in progress) and an appendix that shows the digital states of the circuit I want to design.

What I am looking for:
1) Is this a reasonable thing to try to design? Am I crazy in trying to attempt this?

2) Where would someone start designing a sequential digital circuit? I've watched some videos online about this process and have tried to include that information in the attached specification, however I have to admit I don't really know what I am doing.

3) Once I get some feedback on the first two questions, I have hoping I can find people here to mentor me through the design process. I am serious about completing this and will put in whatever effort is needed to learn this information. If I can design a circuit to do what I need, I will absolutely be building these and putting them to work.

Thanks so much!

 

Welcome to AAC!

I think it would be more straightforward if you just posted the timing diagrams for the conditions you want to detect.

Attached is your .docx file converted to smaller PDF. Don't know what you're trying to show us in the spreadsheet.

 

I would think that it may be easier to use the direct output of each quadrature encoder and use them independently, if this is possible.
What type of controller are you considering?
Robot design is no mean feat!
Do you have the original motor drives, or need to supply them?
The product that would probably operate it would be one of the Galil Motion cards.
Max..

 

Dennis and Max, thanks much for the replies!

I think it would be more straightforward if you just posted the timing diagrams for the conditions you want to detect.

OK. There are 6 patterns that I need to detect and create outputs for. Since this is an encoder, the signals could be reversed (channel A leading channel B instead of B leading A as shown below). The tricky part is handling the transitions between patterns appropriately. All the information is contained in the relative timing between the green channel (encoder channel C) and the incremental quadrature signals on channels A & B.

Pattern: NOT A


Pattern: NOT B


Pattern: A NOT B


Pattern: B NOT A


Pattern: NOR


Pattern: XOR


Pattern: XOR + Index Pulse (Ignore the black trace)


Again, simply identifying the pattern is only half the chore. The circuit needs to correctly handle transitions between patterns and the motor stopping and reversing in the middle of the pattern. I have not yet written state tables for these conditions. Wanted to make sure this was reasonable in the first place before continuing.

If this isn't conveying the information you are looking for, please let me know. If you have an example, I will try to match it.

I would think that it may be easier to use the direct output of each quadrature encoder and use them independently, if this is possible.
What type of controller are you considering?
Robot design is no mean feat!
Do you have the original motor drives, or need to supply them?
The product that would probably operate it would be one of the Galil Motion cards.
Max..

The quadrature data from these encoders is not multiplexed and each encoder conveys its information individually (meaning I have 4 sets of the signals above, one for each motor). The information that is in the multiplexed signal is the commutation and index signals. This tells the servo drive how to correctly fire the windings of the motor, much like the spark plugs in your car. Without these signals being accurately provided to the drive, the motor may not move or it could burn up from improperly applied current. Realistically, the drive would just fault and not allow me to run the motor. "Normal" encoders would have provided these signals as 5V logic signals same as the A and B channels, but the manufacturer of these motors had to make things difficult...

I might be able to set the servo drives to not use this info and try to self-sense the commutation angle, however this has issues and may not even be possible with the hardware I have - still looking into it.

I do not have the original motor drives, however I do have some Allen Bradley Kinetix 2000 servo drives. I can configure them to run these motors. The drives talk with an AB PLC that can handle the motion control and robot kinematics. I would have never ventured down this path with access to the equipment that I have.

 

The common way now is to include separate commutation tracks as well as the A/B quadrature outputs on the encoder..
In some cases where the commutation is missing, the motor is exercised at power up, and the rotor position is sensed via current feedback, from then on the commutation is done via syncing to to the encoder.
But I have never had experience doing it this way.
Max..
,

 

So you want to decode the D mux bitstream back into commutation signals. A fast 32-bit controller designed for motor control should be able to handle that and provide 32-bit Quadrature Encoder Interfaces with index, home and QEI index match interrupts. Not easy, but possible.
One example MC family: https://www.microchip.com/design-ce...ollers-for-motor-control-applications/pic32mk

Page 30 of the pdf.

 

OK. There are 6 patterns that I need to detect and create outputs for.

The labels on the timing diagrams give you the logic function necessary to decode:


I don't understand what the 6th 7th waveform means and didn't really check the circuit outputs (I just glanced at the waveforms enough to understand what they meant).

EDIT: The label for the 5th gate is wrong in the timing diagram. The waveform is correct.


The document has a strange way of describing the outputs. I had to look at the waveforms to understand what they were trying to say...

EDIT2: Here's the encoder going clockwise/forward if it matters:

 

Thanks again to everyone for the replies, I'll answer the best I can.

The common way now is to include separate commutation tracks as well as the A/B quadrature outputs on the encoder..
In some cases where the commutation is missing, the motor is exercised at power up, and the rotor position is sensed via current feedback, from then on the commutation is done via syncing to to the encoder.
But I have never had experience doing it this way.
Max..
,

Max you are exactly correct, and that is what I am used to working with. The manufacturer of these motors opted to take those commutation tracks, and the index signal, and cram them into a single wire (the "C" channel). That is the multiplexed signal I need to decode to get the commutation signals again.

The drives I have might be able to do that self-sensed commutation you described, but I am not 100% sure yet. Something I am looking into in parallel with this circuit design. There are some disadvantages to doing it this way that I'd like to avoid if possible.

So you want to decode the D mux bitstream back into commutation signals. A fast 32-bit controller designed for motor control should be able to handle that and provide 32-bit Quadrature Encoder Interfaces with index, home and QEI index match interrupts. Not easy, but possible.
One example MC family: https://www.microchip.com/design-ce...ollers-for-motor-control-applications/pic32mk

Page 30 of the pdf.
View attachment 207756

That is a great PDF! Page 30 is exactly the type of encoder on my motors but they took the UVW and Z signals (yellow and green traces in your picture) and crammed them into a single signal (Channel D of the O-Scope). This was done with a proprietary ASIC chip on the encoder PCB. I assume, but am not certain, that there would be a complementary ASIC on the servo drive from this manufacturer that would decode the signal, or it might be done directly in the servo drive processor. I am not sure.

I have done a lot of Arduino/STM32 Nucleo programming before, but would not know where to start with a microcontroller design like the chip you linked. Would you expect it to handle decoding the bitstream in some hardware acceleration on the chip, or would I be programming some kind of interrupt routine? This is at the fringe of my knowledge.

The labels on the timing diagrams give you the logic function necessary to decode:
View attachment 207758
View attachment 207759
I don't understand what the 6th waveform means and didn't really check the circuit outputs (I just glanced at the waveforms enough to understand what they meant).

EDIT: The label for the 5th gate is wrong in the timing diagram. The waveform is correct.
View attachment 207760

The document has a strange way of describing the outputs. I had to look at the waveforms to understand what they were trying to say...

EDIT2: Here's the encoder going clockwise/forward if it matters:
View attachment 207762

Sorry if I am not describing things in a conventional manner. Trying to learn what the correct ways are. I put the specification together as a compilation of the information I knew at this point, but it is definitely not complete.

Those diagrams are great and show all the different states that multiplexed signal can be in. What program did you use to generate those?

I will sketch a timing diagram knowing now what you are looking for. It will take me a little bit to make sure I get it right compared to the scope traces I have taken so far. Get back to you as soon as I can.

-Mike

 

Those diagrams are great and show all the different states that multiplexed signal can be in. What program did you use to generate those?

It's a program called Digital Works and is free. You can download here.

The program has some limitations (like that bug for the NOR waveform; clearly I had it labeled correctly), and is no longer being maintained.

The encoder component (macro in their terminology) is something I made when helping someone else with an encoder issue.

The waveforms were made using the "Logic History" tool. For most things, you need to add an LED to be able to put them on the list. There are exceptions for the clock and sequence objects. The waveform order in the tool is difficult to control.

 

Dennis and all,

Here is the timing diagram. I showed differential pairs for all the inputs (A, A*, B, B*, Z, Z*) shown at the top of the page, but omitted them for outputs (U, V, W, Z) on the bottom, because I ran out of room.

The breaks in the signals indicate a repeated pattern that was hidden due to restrictions in the size of paper I had. The width of each pattern is 85 periods of channel A or 341 quadrature counts. The width of the entire set of 6 patterns is 512 periods of channel A or 2048 quadrature counts. Within each hidden section, the pattern repeats continuously.

The red waveform is the special index pulse pattern. It only occurs one in every 4 sets of patterns and consists of an extra high count in the middle of the XOR pattern. Correspondingly, the Z output only rises high once in every 4 sets of patterns. For the 3 out of 4 sets without the special pattern, the waveform continues along as the normal XOR pattern and shown in pencil behind the red ink.

The encoder has 2048 lines (periods of A) or 8192 quadrature counts per revolution.



I carefully studied each transition condition based on oscilloscope data and did my very best to accurately record the state of each waveform at the moment of transition.

Unsure what the next step is towards turning this into a circuit. I have a feeling this is a lot more complicated than your typical circuit timing diagram...

-Mike

 

Hi all,

I have been working on this quietly in the background headed in two directions. First is to try to run the servo drives using self sensing commutation. On paper they appear to be able to do this, however this is no documentation or support for the feature so progress has been slow. The other path is getting the circuit described above to function. I have a lot of thoughts on this but let me share where I am at.

At a high level I see this circuit operating in several sequential stages.

1) Input buffering (Schmitt Triggers for noise immunity)
2) Input edge detection (Identify when inputs A or B transition states)
3) Input state memory (every input state change triggers essentially a shift register of bits to track the old input states)
4) Pattern detection (look at current and past inputs and determine which of 7 patterns are present)
5) Output generation (based on the identified pattern, switch on or off 4 outputs in particular combinations)

I have come up with a circuit to accomplish the first 3 stages. If you want to see the circuit or suggest simplifications or improvements, go here: https://www.falstad.com/circuit/

You can open the circuit in the web browser, but I like to download the offline one (link below the applet window). I have attached a circuit file below which can be opened in this applet. Alt-Click and drag allows you to pan.

Circuit Description: The circuit reads the 6 inputs (A, A*, B, B*, C, C*) which have been simplified down to 3 inputs with inverters so I can click on them to trigger the circuit. The circuit triggers on any change of A or B input detected by the logic gates at the very top of the drawing. The output of that circuit triggers the last (4th) memory block to copy the data from the 3rd memory block. Then the 3rd copies from the second, the second from the first, and finally the first from the encoder inputs. When the circuit is done with this "ripple memory" it sets the EnO bit (stands for enable out and is low when the memory is updating). Once this happens, the entire circuit ripples up from the bottom again resetting to accept new input changes. It is critical that this entire process happens faster than the encoder inputs can change state (about 1.46 us worst case). The low EnO bit would tell the next part of the circuit to ignore the outputs because they are actively changing state.

This is an asynchronous (not clocked) circuit, but the SR flip flops use a clock input as an enable. This input is high the entire time the circuit is updating and resets low once the EnO bit is set.

You can click on the H or L on the left to change the input state and trigger the circuit. Don't change another input until it is done with the whole switch/ripple/reset cycle or weird stuff happens. The change detection is NOT triggered by changes in the C input.

I have thoughts on the pattern detection part of this circuit as well as a pretty solid grasp of how to do the output logic.

I had planned on doing this with CMOS logic, however the slow propagation delays concern me (200ns per SR latch compared to 20 for TTL family)

Would love to hear your thoughts.

Mike

 

Here my thoughts on the pattern detector.

Initially I wanted to be able to identify every single input state and pair it to an output state. This led to a necessity of finding the minimum number of bits of input state memory without input collisions (cases were a given input condition mapped to two or more output conditions).

I think normally a timing diagram would be the most useful tool to help design the circuit, however you can see the timing diagram drawn above is very complicated and does not lend itself to design of a circuit easily.

Ideally a minimum number of bits of memory for each input would be used. A minimum number of states would require fewer encoder counts to detect the pattern and switch between outputs. It would also greatly decrease complexity of the circuit. With 2 bits (current value + last value), there is no need to handle direction changes and only 14 transition cases occur. With 3 bits of memory the complexity increases with the need to handle 56 direction change conditions and 28 transition conditions. With 4 bits of memory, there are 112 direction change conditions and 42 transition conditions. Finally for each additional bit of memory, the pattern detection circuit needs to handle an additional 3 inputs. It should be obvious why a minimum number of bits of memory is desirable.

I used MS excel to map these input to output conditions and was quick to realize that 2 and 3 bits of memory was not possible. There were many input collisions and these would lead to indeterminate states. I didn't even bother checking direction changes or pattern transitions. I found that 4 bits (current value + 3 previous values) did not have any collisions in the patterns, however, I did not fully investigate the direction changes or transition conditions. At this point I felt that this circuit was beyond my ability to design. With 12 inputs, there were 4096 input states to consider and map to 7 outputs.

Keyframes:

After taking some time to think about it, an idea dawned on me to greatly simplify the circuit. I didn't need to make sure every single input combination was unique (no collision), but rather that each pattern had at least one unique input combination that didn't show up in any other pattern. I coined the term "keyframe" to describe this input combination.

It turned out that 2 bits of memory was insufficient to identify all patterns since the NOR and XOR patterns had no unique input combinations, however 3 bits did! This meant that I could ignore all inputs with collisions and just wait to find a keyframe to detect the appropriate pattern. It turned out that each pattern did have at least one keyframe in each direction even when considering direction changes and transitions. There are only a couple dozen keyframes in total so the circuit to match a keyframe to the appropriate pattern output can be much simpler (compared to the 4096 input combinations of the 4 bit memory circuit)

The downside to this is that you must wait for a keyframe to appear in order to switch the detected pattern. The 3 bit circuit must always wait 3 input cycles to detect a pattern at minimum and the keyframe will appear between 1 (best case) to 4 input cycles (worst case). This means that even with only accepting a very limited number of input combinations, this circuit is equal to or faster than the 4 bit circuit I considered originally.

Finally, the circuit will only detect a pattern when a keyframe is found and it now needs to hold the last output state between keyframes, so an additional latch circuit is required on the outputs.

I will be developing this idea further and drawing up a circuit over the next few days.

-Mike

 

I gave my input circuit some more thought. I think I might have built 3 parallel 4-bit shift registers out of discrete components. To simplify things and hopefully make the circuit faster, I wanted to look into buying pre-built shift registers. I have a couple of questions:

Question 1: What logic family would you recommend for me to work with? I'll be the first to admit I don't know much about the ridiculous number of logic families out there. My first pass led me to the 74AC series for the fast switching speeds, rail-to-rail output, and wide noise margins.

Question 2: In my original design, I chose to make the circuit asynchronous. It only cycled data when there was new data to be entered into the memory. I used clocked circuitry, but only brought the clock line from low to high once and let the signal ripple up the circuit. These pre-made shift registers probably don't work like that. It seems like they want a very very narrow clock pulse. Would you recommend moving to a clocked circuit for this part of the project (I really don't understand clocked circuits) or should I try to create a narrow single shot pulse from the original signal that starts the memory shift?

Question 3: When I go looking for shift registers, many of them come with 3 state outputs. Do I want that if the outputs are going directly into more logic gates? When do you use 3 state outputs?

Question 4: How do I figure out what an acceptable fanout is from chip to chip. There are some cases when I might be going to 7 or 8 gates from one output.

EDIT: I like the TI CD74AC164 shift register. It looks pretty simple and does what I need. I would run it at 5V. If the whole thing shifts only on the rising clock edge, do you think I can treat it like an asynchronous circuit when the clock input is high whenever the data input and data output 0 do not match? That way, as soon as the input data changes, the clock line goes high and stays high until I see the new data on the output.

EDIT: With the pre-built part, the shift register delay is 11.4ns. This is much faster than the discrete components I was looking at before, but I might have been looking at a 7400 series.

 

Here is an updated circuit using the shift registers to simplify the logic.

If you want to see the circuit or suggest simplifications or improvements, go here: https://www.falstad.com/circuit/

You can open the circuit in the web browser, but I like to download the offline one (link below the applet window). I have attached a circuit file below which can be opened in this applet. Alt-Click and drag allows you to pan.

The currently selected chips are:

Differential Receiver (tried to match the driving AM26C31): AM26C32
Quad XOR: SN74AC86
Quad OR: CD74AC32
Hex Inverter: SN74AC04
8-Bit Shift Register: CD74AC164

One concern I have is that the AM26LS32A looks to have TTL outputs. I would need 10k pullup resistors on these wires to interface them to the CD74AC164 I think. Would appreciate verification.

This should be much simpler! Would love feedback on this design.

 

I have made some real progress here and wanted to share.

Where it stands right now, the circuit is able to load inputs into shift registers, read the current and previous two states of the inputs and decode them into 7 patterns. Invalid inputs (e.g. A and B rise or fall at the same time) and inputs with collisions (input signal maps to two different outputs) are ignored. I've checked the circuit against every input combination in my table and they all look good. I did a K map analysis and I am pretty sure there is not a more efficient circuit to do this logic (although I'd love to find one).

Everything is still asynchronous, however I have an ENABLE signal that propagates through the circuit to indicate when it is appropriate for the next part of the circuit to evaluate its inputs (feeds into the clock input on chips that have one). I haven't finalized this design, but the best case propagation delay of this ENABLE signal within each section of the circuit should be greater than the worst case propagation delay of the logic through any path in the circuit. This will allow the outputs to settle and any glitches / race conditions to be ignored. Don't fully understand clocked synchronous circuitry well enough to use it, and I don't see why it is needed for this.

If you want to see the circuit or suggest simplifications or improvements, go here: https://www.falstad.com/circuit/

You can open the circuit in the web browser, but I like to download the offline one (link below the applet window). I have attached a circuit file below which can be opened in this applet. Alt-Click and drag allows you to pan.

What is left here is to build a "radio button" circuit on the 7 output wires which latches each output ON when the corresponding input rises. If any other input rises then the first output unlatches. Only one input can ever be on at the same time, and only one output should be on at any given time. This is necessary because not every input combination will turn on an output. In fact, most will not. The detected pattern must stay active (output high) until another valid input combination changes the output pattern.

Finally there is an output stage that looks at the state of the 7 pattern outputs and decides how to turn on and off the physical outputs of this circuit (using a line driver). This should be dirt simple to build.

-Mike

 

Also looking at that fanout from the BCD decoder/demux chips, I can tell this is going to be awful to try to route on a 2 layer board... Will deal with that later.

 

Wanted to post an update. I have a college buddy, Simon, (also an Mech E.) who has been helping me out with this and came up with a completely different solution to this problem than I did. I am currently moving forward with his design due to the simplicity, although I have not checked it against all cases at this time.

My solution - Keyframes:
I attacked this problem by finding the minimum number of input memory states to reliably identify the pattern on the input channel "C" (this turned out to be 3). I then searched the entire input space for 9 bit combinations that uniquely identified the pattern (keyframes) and created parallel logic paths for these (34 individual 9-input AND gates). This was complex but definitely functional.

Simon's solution - Anchor Point:
Simon came up with a totally different way to tackle this. He evaluated the values for inputs A and B to identify which of the 4 quadrature states the encoder was in (labeled T1 -> T4 in the circuit), and latched a flip flop high or low depending on if the C input was high or low for that state. The memory is always anchored in place at the rising edge of the A input and which memory state is being written to changes based on the states of A and B inputs.

The 6 output patterns each had a 3-input AND gate looking at the values of these 4 quadrature memory states. Seemingly by the original design of the system, the states are mutually exclusive and for all input combinations that actually appear on the encoder, one and only one pattern output is always on. This means I don't need to have the "radio-button" memory circuit discussed above.

With his design, direction changes don't change the latched states, so they can be ignored. Transitions between states happen seamlessly without the detected pattern/outputs glitching. I still need to evaluate direction changes across the pattern boundaries, but I am hopeful these work without issue.

Simon also identified one additional simplification. None of the 6 patterns have the input "C" appearing HIGH at the same time and A and B are both high. The only time this occurs is when the index signal is present (one single pulse per encoder mechanical revolution). This means the condition A and B and C = index pulse.

I also want to look into seeing if I can figure out the correct outputs right when the encoder is powered on and pre-load these into the circuit. This way the servo drives know how to commutate the motor immediately at power on. I read something at the beginning of this project that led me to believe it was possible to figure this out.

My Design: >33 SOIC chips (14 or 16 pin), I never finished the "radio button" memory, output logic, or synchronous flip flops. This could have easily added 5-10 or more ICs

Simon's Design: 11 SOIC chips (14 or 16 pin)

I applied clocked logic to Simon's logic design as some people had suggested and pointed me in the right direction. I'd love feedback if I did it correctly.

My Design (file attached in above post):


Simon's Design (File attached below):


Note that in actual operation, the clock on the left input buffering D-type flip flops would be tied to the clock used everywhere else. I left it manually activated so that I could punch in the inputs and then toggle the clock to introduce them into the circuit (click the clock input 4 times to cycle it in).

Would love to hear everyone's thoughts.

 

Want to say thanks to everyone who pitched in and helped answer my many questions on this circuit (across many threads). I have placed the order for the PCBs (JLCPCB) and will be putting them together when they get here in a week or two. Hope it all works!

 

Wanted to post an update to the couple of threads I had started related to this circuit. My original PCB did correctly decode the signals coming from the motors on the robot, however it was prone to glitches where the outputs would flicker on and off sporadically.

I updated my design to include a circuit modification. This involved adding (1) 4 Channel 2-Input XNOR gate, (1) 3 Channel 3-Input AND gate, and (1) 4 Channel 2:1 multiplexer. These chips work together to detect when an input has changed state and prevent that sample from entering the circuit. Only when 2 successive input readings agree can the outputs of the circuit be updated.

The circuit still functions with the changes I made and all the glitches seem to be gone! I really appreciate all the help and feedback from everyone here.