-
Welcome back Guest! Did you know you can mentor other members here at H-M? If not, please check out our Relaunch of Hobby Machinist Mentoring Program!
Mike's SCARA Robot
- Thread starter macardoso
- Start date
- Joined
- Mar 26, 2018
- Messages
- 2,719
Thanks so much!
I really haven't done much of any digital circuits. I am having a lot of fun reading and learning about it. I find it rather intuitive, although the devil is in the details I think.
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 looked into buying pre-built shift registers.
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): AM26LS32A
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.
This should be much simpler!
-Mike
- Joined
- Mar 26, 2018
- Messages
- 2,719
I am going to look into the pattern detector using a new concept I named "keyframes". Basically, I made the assumption that you needed to be able to identify the current pattern given any set of inputs. This caused me to reject the idea of using 3 bits of memory (current value and 2 previous values) because there were collisions where a given input mapped to 2 different patterns. This brought me to use 4 bits of memory which tremendously increased complexity and slowed down the circuit.
After thinking about it more, I believe I can accept inputs with collisions as long as I ignore them. Instead, the circuit will search for "keyframes" or special sets of inputs which map to a unique output. Using only 3 bits of memory, every pattern has a unique keyframe in each direction even accounting for direction changes and pattern transitions. Collisions between transitions and core patterns are OK so long as the core pattern is one of the two being transitioned between. The currently detected pattern would latch until a new keyframe is detected.
This brought the number of cases I need to consider to 28 compared to many thousand when using 4 bits of memory and mapping every valid input to an output.
Surprisingly, this is no slower than using 4 bits of memory since the pattern will be detected when a keyframe is present (min 1 encoder count, max 4) with a minimum of 3 encoder counts to fill the memory. So 3-4 counts in any direction will run into a keyframe.
To simplify the circuit, I can only consider the 28 main keyframes, however if I want to detect patterns faster at some direction reversals and pattern changes, I could set up the circuit to detect an additional 6 keyframes.
I am going to design the pattern detector next.
Mike
After thinking about it more, I believe I can accept inputs with collisions as long as I ignore them. Instead, the circuit will search for "keyframes" or special sets of inputs which map to a unique output. Using only 3 bits of memory, every pattern has a unique keyframe in each direction even accounting for direction changes and pattern transitions. Collisions between transitions and core patterns are OK so long as the core pattern is one of the two being transitioned between. The currently detected pattern would latch until a new keyframe is detected.
This brought the number of cases I need to consider to 28 compared to many thousand when using 4 bits of memory and mapping every valid input to an output.
Surprisingly, this is no slower than using 4 bits of memory since the pattern will be detected when a keyframe is present (min 1 encoder count, max 4) with a minimum of 3 encoder counts to fill the memory. So 3-4 counts in any direction will run into a keyframe.
To simplify the circuit, I can only consider the 28 main keyframes, however if I want to detect patterns faster at some direction reversals and pattern changes, I could set up the circuit to detect an additional 6 keyframes.
I am going to design the pattern detector next.
Mike
Last edited:
- Joined
- Mar 26, 2018
- Messages
- 2,719
I've attached the state table for the pattern detector. Look at the second tab labeled "3 Bit Pattern Detector".
This lists all the possible input combinations the encoder might produce including the core pattern, direction changes in the core pattern, transitions between patterns, and direction changes across the pattern boundaries.
Green indicates a completely unique input-output combination. These are keyframes.
Yellow indicates an input combination with a collision, but both conditions are OK to resolve to the given output (such as a transition condition where the collision occurs between one of the two patterns being transitioned from). These will be considered keyframes.
Red indicates a collision between different outputs. These must be ignored by the circuit.
The box to the right of the input pattern will either be labeled with the appropriate pattern output, or be filled in grey indicating no output change for that input.
NOTE: HM doesn't allow MS Excel docs to be uploaded. Download the attachment and change the file extension from .pdf to .xlsx to be able to view the workbook.
-Mike
This lists all the possible input combinations the encoder might produce including the core pattern, direction changes in the core pattern, transitions between patterns, and direction changes across the pattern boundaries.
Green indicates a completely unique input-output combination. These are keyframes.
Yellow indicates an input combination with a collision, but both conditions are OK to resolve to the given output (such as a transition condition where the collision occurs between one of the two patterns being transitioned from). These will be considered keyframes.
Red indicates a collision between different outputs. These must be ignored by the circuit.
The box to the right of the input pattern will either be labeled with the appropriate pattern output, or be filled in grey indicating no output change for that input.
NOTE: HM doesn't allow MS Excel docs to be uploaded. Download the attachment and change the file extension from .pdf to .xlsx to be able to view the workbook.
-Mike
- Joined
- Mar 26, 2018
- Messages
- 2,719
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.
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
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.
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
- Joined
- Mar 26, 2018
- Messages
- 2,719
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 quite 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.
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 quite 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.
- Joined
- Mar 26, 2018
- Messages
- 2,719
Quick check in.
I've settled on the design I shared in the previous post. I have matured the design and tested it to the best of my knowledge. I picked out chips in a medium sized Surface Mount Technology (SMT) package called SOIC. They are relatively inexpensive at $0.50 each or so.
My first plan was to produce my boards in the same form factor as the 2090-K2CK-COMBO breakout board from Allen Bradley. This would let me mount my design directly to the servo drive and still be able to access all the important terminals. Unfortunately, this is looking cost prohibitive.
To use the same terminal blocks and D-Sub connectors as the Rockwell board, an additional cost of $35 would be added to each board. In addition, the size of the board would be 170x70mm and would cost me $35 each from the USA or $10 from China (larger purchase Qty required). Since I need 4 of these and rework is likely, I am not willing to put this much into PCBs at this time. Additionally, there is not much room to add my custom circuitry on these board footprints.
A second option is to purchase 4 of these breakout boards from eBay (roughly $20-25 each) and desolder the components I need. This would save me a little cost and I would get silkscreened terminal blocks and the plastic casing. Kinda sounds like a pain and I've had mixed luck with reusing components that I had previously desoldered. I'd still have to buy the much more expensive PCBs, but I'd save $60 or so in components.
My new plan is to create a smaller and simpler board with cheaper screw terminals. This would cost me maybe $20 per board total and would be much easier to rework if needed. These would either hang in-line with the encoder cable going to the drive, or I could find a way to mount them to a DIN rail.
I'm in the process of transferring the schematic from the simulation program I keep posting links to, and putting it into Autodesk Eagle. I've created footprints for all my components and I am just taking my time to make sure I have all the correct peripheral devices like decoupling capacitors included in the schematic.
Hoping to finish this and get them on order within the next week. I really want to see a motor move!
Mike
I've settled on the design I shared in the previous post. I have matured the design and tested it to the best of my knowledge. I picked out chips in a medium sized Surface Mount Technology (SMT) package called SOIC. They are relatively inexpensive at $0.50 each or so.
My first plan was to produce my boards in the same form factor as the 2090-K2CK-COMBO breakout board from Allen Bradley. This would let me mount my design directly to the servo drive and still be able to access all the important terminals. Unfortunately, this is looking cost prohibitive.
To use the same terminal blocks and D-Sub connectors as the Rockwell board, an additional cost of $35 would be added to each board. In addition, the size of the board would be 170x70mm and would cost me $35 each from the USA or $10 from China (larger purchase Qty required). Since I need 4 of these and rework is likely, I am not willing to put this much into PCBs at this time. Additionally, there is not much room to add my custom circuitry on these board footprints.
A second option is to purchase 4 of these breakout boards from eBay (roughly $20-25 each) and desolder the components I need. This would save me a little cost and I would get silkscreened terminal blocks and the plastic casing. Kinda sounds like a pain and I've had mixed luck with reusing components that I had previously desoldered. I'd still have to buy the much more expensive PCBs, but I'd save $60 or so in components.
My new plan is to create a smaller and simpler board with cheaper screw terminals. This would cost me maybe $20 per board total and would be much easier to rework if needed. These would either hang in-line with the encoder cable going to the drive, or I could find a way to mount them to a DIN rail.
I'm in the process of transferring the schematic from the simulation program I keep posting links to, and putting it into Autodesk Eagle. I've created footprints for all my components and I am just taking my time to make sure I have all the correct peripheral devices like decoupling capacitors included in the schematic.
Hoping to finish this and get them on order within the next week. I really want to see a motor move!
Mike
- Joined
- Feb 27, 2014
- Messages
- 2,287
I have had good luck with desoldering terminal blocks. At least as long as you have a solder sucker or vacuum based desoldering tool. I should say that I have always had good luck with not damaging the terminal blocks. The amount of heat needed for the large thermal mass of the terminal block sometimes causes the circuit board they are being removed from to not fair as well. One advantage I have had when getting circuit boards from china is that I can often get the stensil (for applying solder paste to surface mount pads) for free. Also when I was learning to reflow solder in a toaster oven, I managed to ruin a few boards and so the extra volume from China board maker was an advantage.
Eagerly watching to see how you solve the problems to get this very cool robot working.
Eagerly watching to see how you solve the problems to get this very cool robot working.
- Joined
- Mar 26, 2018
- Messages
- 2,719
Yeah, I've had decent luck with that. Would be easier with a hot air rework station but still not too bad. I'm more worried about the DB-44 and DB-15 connectors. These are $15 for the pair and have a whole lot more pins to remove without bending them. I usually end up with solder globs on the pins and have a hard time cleaning them well enough to get them back on a new board.
I think down the road I'll consider doing this, but I'd be real upset if I spent a lot of time and money and found out my board didn't work!
Thanks! I'm having fun with it and I really want to get it moving. It has been fun to take a detour and try to learn/relearn circuits and PCB design.
Similar threads
