# Mike's SCARA Robot



## macardoso

Hi All,

Some of you may have seen me write about how much I am interested in industrial robotics. I've been looking for an old robot to play with for 3-4 years now and one just happened to pop up!




Many people are familiar with the 6 axis articulated robots that are often shown in factories (and I'd love one of those to play with) but what I happened across is a 4 axis SCARA (Selective Compliance Articulated Robot Arm) robot. These are very high speed robots that are typically used in pick and place assembly applications. Using robot kinematics it can translate in 3 axis (X, Y, & Z) as well as rotate the end effector around the Z axis. The one I bought is a rather large for this type of robot and while I don't yet have a manual to reference, I expect the payload to be in the 5-8kg range. Positioning resolution is typically .0001" or better on these units.

The robot did not come with a control (hence why it was so cheap), but I have a lot of industrial controls equipment including servo drives and a PLC capable of controlling motion and doing the inverse kinematic transformations required to control these devices. I intend to build a control from scratch. I bought this knowing full well that there are a ton of unknowns to getting it to work, but that is the fun part to me!

Here is the information I do know: Updated 12/13/2020

*General:*

Manufacturer: EPSON Robotics - Model "BL" OEM Licensed to Seiko Instruments USA
Model: D-TRAN TT8800
Year Mfg.: 1999
Seiko Instruments USA robotics division sold to Epson in 2001
No. of Axes: 4
Weight: 60kg (132lbs)
*Reach/Payload:*

Reach: 31.5 max 11.4" min
Payload 2kg Rated (Full Speed) 10kg Max
T1 Range: +/- 100 degrees
T2 Range: +/- 140 degrees
Z Stroke: 150mm (5.9"). There was an option available for 300mm stroke but I don't have it. It imposed some significant restrictions on motion speed due to the bending moment on the ballscrew.
U Range: Continuous
*Positioning:*

T1 Range Encoder Counts: 455,113
T2 Range Encoder Counts: 497,150
Z Stroke Encoder Counts: 98304
U Revolution Encoder Counts: 344,064
Axes can be limited in range with adjustable hard stops
Max Positioning speed (XY): 5180mm/s (12236 in/min or 11.6 mph)
Max Positioning speed (Z): 937mm/s (2213 in/min or 2.1 mph)
Max Positioning speed (U): 1140 deg/sec (190 RPM)
Positioning Repeatability (XY): 0.025mm (0.00098")
Positioning Repeatability (z): 0.020mm (0.00078")
Z Axis Down Force: 150N (33.7 lbf)
*Motors:*

Motor Type: Yaskawa Sigma Series SGM AC servo.
T1: SGM-04A3SU12 400W (Functionally identical to SGM-04A312)
T2: SGM-02A3SU12, 200W (Functionally identical to SGM-02A312)
Z: SGM-02A3SU21, 200W with 24VDC integral brake (Functionally identical to SGM-02A321)
U: SGM-01A3SU11,  100W (Functionally identical to SGM-01A311). The gearbox pinion is a separate component and is not machined into the motor shaft as stated previously.
Motor Encoder: Yaskawa TRD-Y2048 (UTOPE-20ANK). 2048 pulse per revolution Incremental Differential Quadrature signals with digitally multiplexed commutation and index signals. Yaskawa proprietary signals. Encoders are designed specifically for 6 step commutation on an 8 pole motor.
Motor Brake: Z axis only - power to release. Voltage: 24VDC. Manual release button on top of robot.
*Mechanical:*

Gearbox Design: T1 & T2  - Harmonic Drive, Z - Timing belt reduction, U - Planetary Gearbox
Z/C Axis: Ballscrew/ball spline drive, dual motor belt drive. THK KX series. Pitch unknown. 18mm through bore.
T1 Gear Ratio: Harmonic Drive 100:1 (Calculated from encoder pulses). Harmonic drive model 52-100-960006
T2 Gear Ratio: Harmonic Drive 80:1 (Calculated from encoder pulses). Harmonic drive model 25-80-960007
Z Travel Ratio: Timing Belt Ratio 2:1 (36T motor, 72T Ballnut), Screw lead 0.975"/rev , Motor mm/Rev: 24.765. This needs to be validated by dial indicator measurement. It is close but not exact.
U Gear Ratio: Planetary Gearbox, Ratio 21:1, Timing Belt Ratio 1:1 (72T:72T)
Z Axis Timing Belt: BANDO S3M327UK HE (HTD Tooth, 3mm pitch, Fiberglass, 327mm)
U Axis Timing Belt: BANDO S3M564UK 1A (HTD Tooth, 3mm pitch, Fiberglass, 564mm)
*Maintenance:*

Grease: SK-1A
Grease Harmonic Drives every 8000 hours of operation
Tension Z axis belt to 5kgf
Tension U axis belt to 5kgf
*Electrical/Pneumatic:*

Power connector: 16 pins (factory robot cable available for $50) JAE Electronics: JL05-6A20-29PC-A66F0
Signal connector: MDR 68 Pin Hirose Electric Company: DX30A-68P
Tool Connector: DB-15 Standard Density (30V AC/DC 3A)
Air connection: (2) 6mm 85 psi max
T1 Axis Home Sensor: Optical 24V (3 wire: Signal, +24V, DC COM)
T2 Axis Home Sensor: Optical 24V (3 wire: Signal, +24V, DC COM)
Z Axis Home Sensor: Sunx/Panasonic GXL-8F miniature inductive proximity sensor 12-24VDC NPN-NO, Sn: 1.8mm
U Axis Home Sensor: Optical 24V (3 wire: Signal, +24V, DC COM)
*T1 Axis Motor Data - Complete:*

Rated Power (W): 400
Torque Constant (N*m/A_rms): 0.533
Rated Torque (N*m): 1.27
Peak Torque (N*m): 3.82
Inertia (Kg*m^2): 0.0000191
Poles Per Revolution (n): 8
Winding Resistance (Ohms): 2.46
Winding Inductance (H): .015744
Inductive Time Constant (ms): 6.4
Rated Voltage (Volts): 200
Rated Speed (RPM): 3000
Maximum Speed (RPM): 4500
Continuous Current (A): 2.6
Peak Current (A): 8.0
Damping Coefficient (N*m/(Rad/s)): 0.0
Voltage Constant (V_rms/k_RPM): 32.21
Overload Limit (%): 100.0
Acceleration (Rev/s^2): 10600
Thermal Model Parameters (Copied from AB Y-2012-2-H motor (460W 230V similar size)):
Rth-we (C/W): 32.767
Cth-we (W*s/C): 1
Rth-wa (C/W): 1.3
Cth-wa (W*s/C): 1338

Flux Saturation Curve (% Nominal Inductance): Use 1.0 for all values (discussed in post #23)
*T2 Axis Motor Data - Complete:*

Rated Power (W): 200
Torque Constant (N*m/A): 0.355
Rated Torque (N(m): 0.637
Peak Torque (N*m): 1.91
Inertia (Kg*m^2): 0.0000123
Poles Per Revolution (n): 8
Winding Resistance (Ohms): 2.68
Winding Inductance (H): 0.01404
Inductive Time Constant (ms): 5.4
Rated Voltage (Volts): 200
Rated Speed (RPM): 3000
Maximum Speed (RPM): 4500
Continuous Current (Amps): 2.0
Peak Current (Amps): 6.0
Damping Coefficient (N*m/(Rad/s)): 0.0
Voltage Constant (V_rms/k_RPM): 21.48
Overload Limit (%): 100.0
Acceleration (Rev/s^2): 8244
Thermal Model Parameters (Copied from AB Y-2006-2-H motor (230W 230V similar size):
Rth-we (C/W): 32.767
Cth-we (W*s/C): 1
Rth-wa (C/W): 1.3
Cth-wa (W*s/C): 1062

Flux Saturation Curve (% Nominal Inductance): Use 1.0 for all values (discussed in post #23)
*Z Axis Motor Data - Complete:*

Rated Power (W): 200
Torque Constant (Nm/A): 0.355
Rated Torque (Nm): 0.637
Peak Torque (Nm): 1.91
Inertia (Kg*m^2): 0.0000181
Poles Per Revolution (n): 8
Winding Resistance (Ohms): 2.68
Winding Inductance (H): 0.01404
Inductive Time Constant (ms): 5.4
Rated Voltage (Volts): 200
Rated Speed (RPM): 3000
Maximum Speed (RPM): 4500
Continuous Current (Amps): 2.0
Peak Current (Amps): 6.0
Damping Coefficient (N*m/(Rad/s)): 0.0
Voltage Constant (V_rms/k_RPM): 21.48
Overload Limit (%): 100.0
Acceleration (Rev/s^2): 8244
Thermal Model Parameters (Copied from AB Y-2006-2-H motor (230W 230V similar size):
Rth-we (C/W): 32.767
Cth-we (W*s/C): 1
Rth-wa (C/W): 1.3
Cth-wa (W*s/C): 1062

Flux Saturation Curve (% Nominal Inductance): Use 1.0 for all values (discussed in post #23)
*U Axis Motor Data - Complete:*

Rated Power (W): 100
Torque Constant (Nm/A): 0.408
Rated Torque (Nm): 0.318
Peak Torque (Nm): 0.96
Inertia (Kg*m^2): 0.0000040
Poles Per Revolution (n): 8
Winding Resistance (Ohms): 13.98
Winding Inductance (H): 0.026562
Inductive Time Constant (ms): 1.9
Rated Voltage (Volts): 200
Rated Speed (RPM): 3000
Maximum Speed (RPM): 4500
Continuous Current (Amps): 0.87
Peak Current (Amps): 2.8
Damping Coefficient (N*m/(Rad/s)): 0.0
Voltage Constant (V_rms/k_RPM): 24.25
Overload Limit (%): 100.0
Acceleration (Rev/s^2): 12653
Thermal Model Parameters (Copied from AB Y-1003-2-H motor (120W 230V similar size):
Rth-we (C/W): 32.767
Cth-we (W*s/C): 1
Rth-wa (C/W): 2.2
Cth-wa (W*s/C): 382

Flux Saturation Curve (% Nominal Inductance): Use 1.0 for all values (discussed in post #23)

Note: The TT8800 is the largest robot in the family of "TT8xxx" SCARA robots. The TT8450, TT8550, and TT8700 had reduced reach, speeds, and payload capacities. The TT8450 also weighed 57 lbs which might have been a bit more reasonable for home use... 

These would have come with a 19" rack mounted controller, a terminal keyboard, and a teach pendant.

I know this isn't exactly a machining project, but I think that some might enjoy following along and I really enjoy sharing my projects with this community. I will post lots of updates as I work through getting this guy running again.

-Mike

EDIT: Wanted to give a big shout out to my loving wife who completely took it in stride when I asked if she wouldn't mind a robot coming into the house  

EDIT 5/5/2020: Data updated based on manuals kindly provided by Epson Robotics.
EDIT 5/6/2020: Data updated based on Yaskawa servo manuals and tech support.
EDIT: 5/7/2020: Added additional motor parameters I need to figure out. Added data on home sensors and motor brake.
EDIT: 5/8/2020: Added values to some of the new motor parameters. T1 is almost complete.
EDIT: 5/12/2020: Added info about EPSON being the robot Mfg. Edited encoder description.
EDIT: 5/19/2020: Corrected information on motor encoder. Added all missing motor parameters! Thanks Yaskawa!
EDIT: 9/14/2020: Added Z axis / T3 motor mechanics details.
EDIT: 9/15/2020: Added U axis / T4 motor mechanics details.
EDIT: 9/24/2020: Corrected the U Axis belt tension requirement
EDIT: 12/13/2020: Corrected T2 gear ratio. Added Harmonic Drive part numbers.


----------



## brino

Mike,

This promises to be a very interesting project!

I will be following closely and learning a whole lot from it.
Thanks for sharing this.



macardoso said:


> EDIT: Wanted to give a big shout out to my loving wife who completely took it in stride when I asked if she wouldn't mind a robot coming into the house



She probably thought it was the kind that would do the vacuuming.

-brino


----------



## macardoso

brino said:


> Mike,
> 
> This promises to be a very interesting project!
> 
> I will be following closely and learning a whole lot from it.
> Thanks for sharing this.
> 
> 
> 
> She probably thought it was the kind that would do the vacuuming.
> 
> -brino



She knows me too well to know it wouldn't be that simple


----------



## macardoso

For everyone who has never heard of one of these, I've linked a couple of videos below. These aren't the exact model I have, but give an idea of what they can do.


----------



## mikey

If you can get that thing to do the yard, wash toilets and vacuum the house then you just might have something the rest of us will have to try!

This is going to be fun to watch - thanks for sharing!


----------



## Titanium Knurler

macardoso said:


> For everyone who has never heard of one of these, I've linked a couple of videos below. These aren't the exact model I have, but give an idea of what they can do.
> 
> macardoso, that looks like a great project. I am looking forward to your posts.
> 
> I would love to see Lucy and Ethel try to keep up with that thing!


----------



## macardoso

I was able to get the manuals!!!

Big shout out to Epson Robotics who were kind enough to provided scanned copies of the original manuals and programming references for the TT8800. They were strongly questioning why I was trying to start up a 25 year old robot, but were very supportive when I explained that it was a hobby.

Manuals are attached. The maintenance manual is too large to attach but feel free to reach out to me if anyone wants it.

Also, as of 5/5/2020 there are 3 more of these for sale at hgr.com if anyone got the kick to try this.

I have gone back to the first post to update the data that I was able to learn.


----------



## brino

macardoso said:


> Also, as of 5/5/2020 there are 3 more of these for sale at hgr.com if anyone got the kick to try this.



hmmmmm, once we get them going we could make them play chess, or arm-wrestle, or row a boat.....unlimited options!

Not to minimize your project or your progress. That is all great!
It's just that, for me, this would be such a huge endeavour....sure a great learning experience, but I have way too many projects already.

-brino


----------



## macardoso

brino said:


> hmmmmm, once we get them going we could make them play chess, or arm-wrestle, or row a boat.....unlimited options!
> 
> Not to minimize your project or your progress. That is all great!
> It's just that, for me, this would be such a huge endeavour....sure a great learning experience, but I have way too many projects already.
> 
> -brino



I really don't expect anyone to be as crazy as me here  The truth is that this is going to take a lot of trickery to get the motors working with any 3rd party servo drives. I don't expect many people would want to try to figure that out AND I happen to have drives to play around with. If you had to go buy all your own, this sorta cheap robot would get really expensive real fast. Also the robot is pretty big and heavy - more than I expected honestly.


----------



## bakrch

First project. Buy another one, paint it ... recreate this scene.

"SCARA, you sonofabishh"


----------



## macardoso

bakrch said:


> First project. Buy another one, paint it ... recreate this scene.
> 
> "SCARA, you sonofabishh"



You know they only filmed that to show off Schwarzenegger's massive biceps!


----------



## macardoso

I am going to start bringing the robot in the house now. Even though it only weights 140lbs, I'm going to treat it the same way I did with my lathe and use the engine hoist and a ramp to lower it in slowly. It is large and the joints move when you lift it, so I'm not comfortable tucking it under my arm and carrying it down the stairs.

I have a few outstanding questions that Epson support is trying to help me with. These are going to be my biggest stumbling blocks.

1) In order to use the motors with my servo drives I need to generate a Custom Motor File (.cmf). This requires a lot of nameplate motor information that is not often published. I have requested that Epson try to find these values for me and I am very much hopeful that they can. If not I will have to measure them or replace the motors entirely. These parameters are:

Torque Constant (Nm/A)
Inertia (Kg*cm^2)
Poles Per Revolution
Winding Resistance (Ohms)
Winding Inductance (mH)
Rated Voltage (Volts)
Maximum Speed (RPM)
Intermittent Current (Amps)
Continuous Current (Amps)
Thermal Model Parameters (if possible)
Rth-we (C/W)
Cth-we (W*s/C)
Rth-wa (C/W)
Cth-wa (W*s/C)

Flux Saturation Curve (not required but helpful)

2) Servo motors use encoder feedback to measure position and relay that to the servo drive. There are many dozens of types of feedback but my drives are only compatible with some of them. Very fortunately these are standard differential incremental quadrature encoders (ABZ) which I can read. Unfortunately they seem to be missing any kind of commutation signals. Permanent magnet AC motors require commutation signals to know the rotor mechanical angle so the drive can generate the appropriate electrical angle. This is a lot like the timing belt and cam shaft on a car engine or the electronic timing of the spark plugs. Usually commutation is done with 3 wires carrying 120 degree phased square waves that equate to the number of motor poles. This way there is always a unique coding on these 3 wires for each of the 8 motor poles. The motors on the robot do not seem to have these signals nor any of the other common methods of commutation (analog SIN/COS, serial startup). I might be able to cofigure the drive to self sense the commutation angle, but I don't love this idea, and I don't know if the particular drives I am using can even do this.

3) I don't know the reduction ratios of the gearboxes. I am hoping to find this without tearing down the entire robot to get to the gearboxes.


----------



## Boswell

Looking forward to your adventures. This would sure make one heck of a Bartender robot!


----------



## jbolt

Cool project!

First thing that came to mind when I watched the second video.


----------



## macardoso

Boswell said:


> Looking forward to your adventures. This would sure make one heck of a Bartender robot!



Amusingly, myself and 3 of my very good friends built a robotic bartender in college. To this day I think it might be the only robot to make 8 drinks at a time









This is the Foobartender. It even made up a fair portion of my best man's speech at my wedding!


----------



## macardoso

OK robot is in the house and down the basement. That was as difficult as dealing with my 12x36 lathe (granted I had a buddy help with that one).

Robot in my trunk again. Used a webbing strap to keep the arm bent over on itself.




I used my Harbor Freight engine hoist to lift it out of the trunk and onto a piece of OSB. I like the hoist but it is a real chore to take it apart and carry it upstairs. Also the long legs are great to go under a car but terrible for reaching on top of work benches.




I manhandled it onto the landing of the basement stairs and used the same ramp I did for the lathe to set it up to slide down.




It was secured with some rope going to a chain on the ceiling joist. I used an auto locking belay device (rock climbing) to hold the load until I wanted to lower it slowly. There is a painted plug that normally covers this hole.







Once at the bottom I took apart the engine hoist and carried it downstairs, reassembled it, and picked up the robot again. I could lift the robot for sure, but I was not comfortable moving it around and certainly not lifting it onto the table top. There was around 20 pounds of tooling that I could have removed to make life easier, but I didn't consider it.




I re-positioned the lifting strap and tried to get it on the table but there wasn't room under the duct. Plus the cable tube was hitting the ceiling on the other side. I ended up lowering the table top by 5 holes and it was just enough to get the base onto the table.




The final part really sucked. The hoist's legs are too long and I couldn't get the hook over the table. I ended up having to unhook it from the hoist with only half the base on the table and heave it the rest of the way. Not super safe but I was ready to jump out of the way if it started to fall. It ended up working out ok thankfully. I didn't have anything to hold it down to the table with so I used the rope to secure it.




Here's a quick peek inside the head. T2 motor is on the left, U axis motor is in the middle, and the Z axis motor is on the right belted to the ballscrew.




Bringing it in took 2 and a half hours. I'm exhausted and calling it a night.

-Mike


----------



## brino

Wow! It looks like it weighs more than the bench.
You may need something more substantial to bolt it to.

I guess there really was some arm-wrestling.

-brino


----------



## hman

I guess the arm wasn't so much "heavy" as it was what I call "ugly heavy" ;~)


----------



## macardoso

brino said:


> Wow! It looks like it weighs more than the bench.
> You may need something more substantial to bolt it to.
> 
> I guess there really was some arm-wrestling.
> 
> -brino



The table is far from ideal but it is what I have. The top is 2" of MDF so it is rather stout. Real SCARA robot installations would probably be done on a thick piece of Mic6 tooling plate or something similar, but that would cost me a fortune. 

I sat and bounced on top of the table before the robot went on and it didn't budge. maybe just a little sway side to side.



hman said:


> I guess the arm wasn't so much "heavy" as it was what I call "ugly heavy" ;~)



I'm going to have to save that one! Perfectly describes the experience. I can squat/bench/lift that kind of weight no problem, but make it big, with nowhere to hold onto, and make it move when you do lift it, and all of a sudden it gets a whole lot harder.


----------



## macardoso

Took some pictures of the inside of the robot and did a little research. Thought I'd share.

The motors were identified to be Yaskawa SGM AC servo motors although the naming scheme indicates that these motors were likely specials offered to Seiko for their robots. I think they are electrically equivalent to the other motors in the series, however I'll have to call Yaskawa to confirm. It seems that these servos were offered with several different drives from Yaskawa over the years so they are present in a couple of different manuals. I've attached one manual and provided download links to two others.



			https://www.yaskawa.com/delegate/getAttachment?documentId=TSE-S800-15&cmd=documents&documentName=TSE-S800-15C.pdf
		




			https://www.yaskawa.com/delegate/getAttachment?documentId=TSE-S800-17&cmd=documents&documentName=TSE-S800-17D.pdf
		


After reading it still remains a mystery to me how commutation is accomplished with these motors. The absolute variant of the encoder has a serial channel that could provide a commutation offset at startup, however the incremental encoder does not have this at all. I'll definitely be asking Yaskawa about this as well.

The good news is that the Yaskawa manuals provided me with an absolute ton of information and motor data. While I don't have it all, I'm pretty close. This means that even if the encoders can't be used with the hardware that I have, encoder replacement is a viable option. The factory encoder is a 2048 pulse per revolution encoder so the controller sees 8192 counts per motor revolution (quadrature interpolation gives 4x resolution over the P/R count).




There is a sheet metal bracket that holds up the cable gland. A large number of cables enter the T2 link and connect to the motors, encoders, and user interface panel.




Here is a better closeup of the ball screw/spline. It is manufactured by THK and is in their KX series (model 61108). I haven't really found much information on it, but I'm not too worried about it right now. Notice how there are parallel grooves running lengthwise on the screw in addition to the spiral ballscrew grooves. This screw is ground and was probably quite expensive. It is hollow with an 18mm hole down the center. After removing the old end effector tooling and adjusting the hard stops, I was able to get the full 150mm of travel on the Z axis.

This youtube video has a couple of short segments showing this kind of screw.












Inside the hollow base of the robot is a 400W servo and harmonic drive gearbox. There is also a circuit board that looks like it is mostly an interface board between the cables and the MDR 68 pin connector exposed to the outside. There are also some components on the board so I will have to investigate these. I have a feeling that all it does is light up some LEDs in a window to show the user when the home switches are hit and when encoder power is active.







I'm still in the research phase here. Will share any updates as I come across them.


----------



## macardoso

Called Yaskawa to talk about their motors and was very pleased with their technical support. The "SU" in the motor catalog number indicates a Seiko proprietary catalog number which prevents Yaskawa from providing me any information on the motor even though the robot and series of motors are no longer manufactured or supported. This is pretty common in industry to prevent an end user from trying to find a cheaper replacement part by going direct to the manufacturer. 

I am fairly confident that electrically the motors are identical to their normal counterparts without the "SU" in their catalog string. I hope that any differences are limited to shaft size, paint color, or something else that doesn't affect what I am trying to accomplish. This may also have allowed Seiko to specify the type of connector on the end of the cable to make integration easier for them into the robot.

According to their support engineer the encoders do not have any commutation signals and were painstakingly aligned to the motor electrical angle at the factory using an oscilloscope. Unfortunately this doesn't answer all my questions because the motor would need to rotate until it found the "z" index pulse to know where it was. The engineer told me he didn't know how exactly it worked, but it certainly did not need to move at startup. It is looking more and more like I will need to use commutation self sensing (if my drive supports it) or replace the encoder.


----------



## matthewsx

Wow, what a project!!!!

I can see why you wanted one of these things and I'm sure you have some idea of what you'll do with it once it's up and running. Any chance it will integrate with another machine or process to make things easier in the shop?


John


----------



## macardoso

matthewsx said:


> Wow, what a project!!!!
> 
> I can see why you wanted one of these things and I'm sure you have some idea of what you'll do with it once it's up and running. Any chance it will integrate with another machine or process to make things easier in the shop?
> 
> 
> John



Thanks! Honestly as with many things I do in my shop it is more about the enjoyment of the build than it is needing the end product. Right now it is sitting on a table with a whiteboard top so the first thing I will probably have it do is draw some stuff. Probably a good way to make sure the motors, drives, and programming is working correctly.

Down the road it would make an absolutely overkill toolchanger for my CNC if I wanted. I looked into it real quick already and I can make my PLC talk with Mach 4 over Modbus TCP really easily, so it would be as simple as Mach 4 sending a start command to the robot and a requested tool, then the robot going and picking up the tool from a rack and swapping it for the one in the spindle. Probably would be pretty easy to get it working like one of those side mount pre-load tool changers on most modern CNCs. Neat application but not really why I am playing with it.

I actually tried building an ATC 2-4 years ago and it worked but was never going to be reliable. It ran on an arduino and Mach 3. The programming was shoddy, the Modbus crapped out a lot, and the thing was tremendously complex. I would have had to spend a lot more time and money to get it running well so it sits on the shelf of shame for now.


----------



## macardoso

I have updated the first post with all the new information that I have. Most of this is motor data from Yaskawa. I was able to confirm that the motors are electrically identical to the normal SGM motors to the best of my knowledge, so I will be going forward with that assumption.

I require motor winding resistance and inductance for my servo drives. Yaskawa publishes neither, however they do give an inductive time constant. If I can measure the winding resistance (shouldn't be too hard) and the motor temperature (room temp), then I should be able to calculate the motor winding resistance at operating temperature using the scaling formula for annealed copper (found a paper online). If I know this, I can use the inductive time constant to calculate the winding inductance at operating temperature and I should be in business!

I have no idea how to measure or calculate the thermal parameters, but my best guess will be to copy the parameters of a similarly sized motor that I do have that data for. The flux saturation curve does do something in the servo control algorithm, but I have no clue what it is. If I look at a bunch of the smaller motors I do have data for, they use the ratio 1.0 for 0 all the way to full load amps. Only the larger motors seem to have derating values in here so I *think* I should be OK to assume 1.0 for all those values I need.

The encoder remains an issue. I did identify it as a Yaskawa TRD-Y2048 encoder (available all over the place online), but I cannot find a manual for it yet. The engineer at Yaskawa did tell me these are factory aligned so I will not be removing it unless it is being replaced.


----------



## hman

When I was at Hewlett-Packard in Corvallis, Oregon (mid to late late '80s, IIRC), they used a whole bunch of Seiko SCARAs to assemble calculators.  I never worked (played!) with them, but recall they were fun to watch in action.  You've got yourself a very interesting project there, macardoso!


----------



## Boswell

Is it not possible to directly measure the inductance? or indirectly with an O-Scope?


----------



## macardoso

hman said:


> When I was at Hewlett-Packard in Corvallis, Oregon (mid to late late '80s, IIRC), they used a whole bunch of Seiko SCARAs to assemble calculators.  I never worked (played!) with them, but recall they were fun to watch in action.  You've got yourself a very interesting project there, macardoso!



That's awesome! We have a Fanuc 200iC assembling electrical components near where I work when I have to go down to our factory. I can stand in amazement for an hour at this thing running and nobody else seems interested in the slightest. 



Boswell said:


> Is it not possible to directly measure the inductance? or indirectly with an O-Scope?



I bet it is, but I do not have the knowledge presently to do so. I do have a nice scope that I can borrow if needed. I know the resistance can change by 50% or so from room temp to operating temp, so I wonder what the inductance will do?


----------



## rwm

That is a really awesome machine and I will be following. What is the end game for this? Do you have an application in mind? I am not sure what I would do with this in my shop? Although I like the idea of it making drinks!
Robert


----------



## macardoso

rwm said:


> That is a really awesome machine and I will be following. What is the end game for this? Do you have an application in mind? I am not sure what I would do with this in my shop? Although I like the idea of it making drinks!
> Robert



Thank you! No endgame in mind. I really find robots fascinating and have a bunch of controls equipment to play with. I might set up a work cell and program it to do something silly like draw with a dry erase marker or build legos. I mentioned above but I could build a robotic Auto tool changer for my CNC mill. 

Mostly I thought it would be a fun quarantine project to try to dig up information on an old robot, learn how it worked, how it was built, and what electronics they used. I think most people would be stressed out by the missing information I have right now, but it just seems like an adventure.  I have a pretty good feeling that I can get this running one way or another.

Plus one day I really want to do the same thing with a 6 axis articulated arm. This would be a great proof of concept. The kinematics and control theory behind those are vastly more complicated than a SCARA.

I might do a couple of posts about servo control and kinematics. Maybe some people will find them interesting if they aren’t familiar with robotics.


----------



## rwm

"robotic Auto tool changer for my CNC mill. " Duh, misinterpreted that.
Could this arm hold a tool like a router and be used as a CNC carving unit? I was thinking if you could carve something like foam you could do awesome lost foam casting. I have seen guys do amazing stuff with that. (GM too! 



)
Robert


----------



## macardoso

rwm said:


> "robotic Auto tool changer for my CNC mill. " Duh, misinterpreted that.
> Could this arm hold a tool like a router and be used as a CNC carving unit? I was thinking if you could carve something like foam you could do awesome lost foam casting. I have seen guys do amazing stuff with that. (GM too!
> 
> 
> 
> )
> Robert



It certainly could although you'd be limited in rigidity, tool weight, and accuracy. These robots are very fast but have small payloads (22lbs max including the weight of all the fixtures, spindle motor, and cables) compared to some robots like the ones shown in your video. It actually covers an impressive ~1600 square inch work space compared to the measly 110 square inches of my G0704 mill. Now that work zone is shaped into a funny looking partial doughnut, but it still pretty large.




Robots are very repeatable (sub thousandth of an inch) but not particularly accurate due to a natural stackup of tolerances over the many linkages of the serial chain that make up the robot. Without compensation I might trust it to be within maybe 5-15 thou of the programmed location. Most robot are "taught" positions by moving it there and saving the location. These points can be adjusted as needed during operation and the programmer isn't often concerned with the absolute position of the actuator. If a robot is to perform a pre-programmed task (like CNC machining) they are often geometrically calibrated by moving in a series of specific motions and using measured positioning error to back-calculate the actual length of each link rather than the published values. There is a whole field of research on this very topic and it gets extremely complex when you get into 5, 6, 7, and greater number of axes.

So I guess yeah if you don't mind a 6" Z axis travel and you don't need to be terribly accurate, this would do nice light duty machining.


----------



## rwm

I think it could knock out foam patterns pretty fast. 15 thou would be acceptable error considering 2% shrink.
Robert


----------



## macardoso

Quick update on the status of the robot...

Encoders are still problematic, although I have a pretty good feeling that my drives will be ok to do self-sensing commutation. I need to verify that still but there are references in the manual to it. I have a couple of feelers put out to people who might be able to point me in the right direction.




Here is the user connections location on top of the robot. You get 15 pins to wire whatever you want (up to 30V 3A). There are also two 6mm air lines that you can use up to 85psi. All of that is run through the cable duct in the robot. You could also run your own wiring outside the robot but you have to take into account all the crazy positions they can get into. The white circle is the manual brake release button.




I popped the covers off the base which shows the cables headed up to the head of the robot and the cable entry for the T1 optical home switch.




Here is that circuit board. All the wires land on 4 connectors which have traces on the board going to the 68 pin connector on the right. Interestingly, this board shows "Epson" on it even though Seiko wouldn't sell the robotics business for another two years after this was built. Wonder if it was a spare part?




I was able to confirm the Z axis brake and all the sensors run on 24VDC. The U axis pinion gear is not integral to the motor shaft but rather a separate component that screws on. This means the U motor could be replaced if needed.

I had a look through the motor file I need to write to run these and found a few additional motor parameters that I need that I do not have. In particular I will be most concerned about figuring out what the "Voltage Constant" is and what the units are. Haven't seen this published so I might need to measure it...


----------



## macardoso

I think it might be useful if I gave a brief intro to servo motors and drives for those unfamiliar.

*Servo Motor:*

Servo motors refer to any motor which regulates position, speed, or torque based on feedback. These can be AC surface permanent magnet, AC interior permanent magnet, DC brushless, DC bushed, stepper motors, etc. The most ubiquitous is the 3 phase synchronous AC servo motor. It is a 3 phase motor with permanent magnets on the rotor (usually on the surface but sometimes buried within). The word synchronous means that the rotor will rotate at the same speed as the electromagnetic field (which is not the case with induction motors). An encoder, which is a shaft angle measuring device, is always present to provide feedback to the servo drive on the location of the motor. The servo drive will compare the motor position to the commanded position and adjust the AC output to correct for any errors in the motor's positioning. You can typically identify a servo by 2 cables exiting the motor (one for power and one for feedback), but some newer motors pack it all in one cable. Also, if it looks expensive, it is probably a servo.

*

*

There are dozens or hundreds of kinds of encoders, but the simplest kind (also the kind on this robot) is an optical incremental encoder. This encoder reads a series of slits in a wheel using optical means. The pattern is usually etched in metal on a glass substrate. a pair of receivers provide a pair of square wave signals with a 90 degree phase offset. By looking at the rising and falling edges of the signal as well as which signal is leading the other you can count distance and direction. The drive uses this to calculate the derivative (speed), second derivative (acceleration), and often higher order terms (jerk, snap, crackle, and pop - not kidding). There is often a third slit that occurs in only one position called the "Z" or "Index" signal. It is useful for homing among other things.




Other types of encoders include magnetic, capacitive, as well as absolute variants of each. Absolute encoders know the exact position of the encoder at power on without needing to find the index mark and some can even track the position while powered off with miniature gearboxes. These are obviously more expensive and complicated, but are often the preferred choice for real industrial applications. My CNC uses absolute encoders and loads the position into Mach 4 at startup using serial communications.

*Servo Drives:*

An AC servo drive is really just a very smart and fast VFD. The AC power enters the drive and is converted into a high voltage DC bus using diodes or SCRs. The DC bus is smoothed and filtered before being presented to 6 IGBT (Isolated Gate Bipolar Transistors) which rapidly switch on and off to approximate an AC voltage waveform at the outputs. The voltage is not a true sinusoid which is why inverter duty motors exist, but the current waveform is a true sinusoid. Here is a very simplified diagram of the inside of the VFD.




The real magic of a servo drive is the high speed processing that occurs to figure out the motor position, positioning error, and the required waveform at the output to achieve positioning. The control algorithm relies on a highly detailed model of the motor response, hence why all the parameters I keep talking about are so very important. If you get them wrong the motor may function very poorly or even burn up.

Entry level servo drives and some standalone models get their command from a pulse train like 99% of hobby CNC guys (including me) use to control their motors. Higher end models will communicate with a central controller over an ultra fast communication network like Ethernet (EthernetIP or EtherCAT) or perhaps a fiber optic network like SERCOS. The Allen Bradley Kinetix 2000 drives I plan to use for this robot will communicate with the PLC over SERCOS. The Kinetix 2000 is a low power rack mounted drive with power sharing. The picture below shows a 6 axis system with a power shunting module on the far right.




*So what's so important about commutation? I don't need to worry about that with my VFD...*

VFDs typically run asynchronous induction motors. These motors always run slower than the electromagnetic field rotation due to a phenomenon known as slip. Current (and therefore magnetism) will only be induced on the rotor when the stator's magnetic field is rotating relative to it. The closer an induction motor gets to the speed of the magnetic field, the less torque will be produced on the rotor . There is a balance point where the load of turning the motor shaft equals the the torque produced. If a load slows the rotor, the greater difference in rotor speed to magnetic field speed creates increased torque. Since the rotor is magnetized by the relative velocity only, it does not matter what position the rotor is in.




This is not true of permanent magnet AC servo motors which have rotors that are permanently magnetized by magnets glued to their surface. The drive must know the exact mechanical position of the north and south poles of the magnets so it can appropriately time the firing of the windings on the motor. This is known as commutation. If this is not done correctly the motor may not be able to move or it might burn up. Often, the encoder relays additional signals to the drive to indicate the absolute pole position. These are absent from my motors hence all my difficulty.

Some servo drives can self sense the commutation angle by locking one of the winding with DC voltage and measuring the resulting shaft angle, however this is not particularly accurate, is influenced by load placed on the motor, and causes the motor to move without being commanded to do so (up to 1/8 of a revolution).

The signals on the right are typical of trapezoidal commutation signals created by an encoder that actually provides commutation signals.




EDIT: An important thing to add is that every manufacturer goes out of their way to make sure that you can only use their motors and drives together. It is very difficult to find all the motor info from one manufacturer that another needs to run a motor. Sometimes manufacturers don't even let you try to enter the motor data from another manufacturer. Very frustrating. I would highly recommend that unless you really know what you are doing, to avoid mixing and matching servos.

Also servos can be very complicated to set up so buy from a manufacturer who can support you and provides excellent documentation. I'm helping a guy on another forum who spent a lot of money on Alibaba servos that came with manuals that had a mix of Chinese, Russian, and a little English. Trying to set them up totally made whatever money he saved not worth it at all.


----------



## brino

Trying to identify the parts on your encoder.....

The first one the TI 26C31I is easy enough; it is a "QUADRUPLE DIFFERENTIAL LINE DRIVERS"
datasheet available here:
http://www.datasheetcatalog.com/datasheets_pdf/A/M/2/6/AM26C31I.shtml


However the Yaskawa JL-041A looks like a custom ASIC.
Some info here:
https://www.jotrin.com/product/parts/JL_041A
and here:
https://www.kynix.com/Detail/59180/JL-041A.html

but even when I created a throw-away user login for that first site, the datasheet links only pointed to the Yaskawa home page:
https://www.yaskawa.com/?filetype=datasheet&kw=JL-041A
The second one links to alldatasheet, that basically says"no such part":
https://www.alldatasheet.com/view.jsp?Searchword=JL-041A

They do have some big catalogs on their AC servo drives:
https://www.google.com/url?client=i...FjAAegQIAxAB&usg=AOvVaw10LSLeRT0vke3ewN61tCR9

https://www.google.com/url?client=i...FjABegQIAhAB&usg=AOvVaw32daytl2hbQ6f7ecIZH6T0

-brino


----------



## macardoso

Weekend Update!

I spent much of Friday night trying to figure out how to create a Custom Motor File (CMF) and get Studio 5000 Logix Designer (PLC programming software) to accept the file. There is a checksum included in the file to prevent people from trying to edit or create these files on their own. Long story short, I got it working, but I shouldn't share the details. Fun couple of hours playing with it and another major hurdle overcome.

There are a lot of integer constants in this CMF file that tell the software which drives this motor is allowed to be run on, what search categories it should appear in, and what type of feedback it uses. I was able to open the motion database file in Microsoft Access and read what all the integer codes related to. I was able to use this info to pick out which codes I needed to include.

I am still missing two critical pieces of motor data (winding resistance and voltage constant) for 3 of the 4 motors. I know Yaskawa has this info and I am very hopeful that they can share it with me for the missing motors. With this info, theoretically  I am able to start running the motors (I doubt it will be quite that easy).

I was also able to locate a set of original cables for the robot. Got low best offers accepted on both of them so I ended up paying 1/5 of what most sets of those cables were being sold for on eBay. I'm very excited about that. I had planned on chopping on end off of each cable and landing the wires on terminal blocks, but now that I realize how hard the cables are to get, I think I will look around for the mating receptacle that would have been on the SRC320 robot controller so I can plug the cable between the robot and my new controller. 







I think I am on hold until the cables arrive and Yaskawa provides motor data to me. From there I think the next step will be to try running the motors on the drives using the CMF files I have made. I expect to have some issues with this, but I am still hopeful I can get these working. I think I still have all 3 options for running the robot open to me:

Run original motors with original encoders
Run original motors with aftermarket commutation encoders
Replace motors entirely


----------



## brino

macardoso said:


> I had planned on chopping on end off of each cable and landing the wires on terminal blocks, but now that I realize how hard the cables are to get, I think I will look around for the mating receptacle that would have been on the SRC320 robot controller so I can plug the cable between the robot and my new controller.



Are those 68-pin SCSI connectors? (https://en.wikipedia.org/wiki/SCSI)
If so, I might be able to find some in the junk drawer and send them along.

-brino


----------



## macardoso

brino said:


> Are those 68-pin SCSI connectors? (https://en.wikipedia.org/wiki/SCSI)
> If so, I might be able to find some in the junk drawer and send them along.
> 
> -brino



Yes! They are 68 pin MDR (I think this is equivalent to SCSI?)

The controller used a Hirose Electric DX20A-68S. I've attached the data sheet and the link to the product catalog is here:



			https://www.hirose.com/product/document?clcode=CL0230-0044-4-00&productname=DX-100-CV1&series=DX&documenttype=Catalog&lang=en&documentid=D49664_en
		


I think the connector is a female socket and has a pitch of 0.050".

Thanks so much for the offer @brino 

Also thanks for the reply above regarding the encoder ICs. I hit the same dead ends that you did unfortunately!


----------



## macardoso

Did some research on the Circular power connector for the robot. I wanted to get the original which would have been installed on the rear of the SRC320 robot controller.

The connector is made by JAE electronics and is part of the JL05 connector family.

The connector on the controller end of the robot cable is JL05-6A20-29PC-A66F0.

The mating connector on the SRC320 controller is JL05-2A20-29SC-F0

The socket contacts in this connector are ST-JL05-16S-C1

The connector shell is listed on many websites but is not in stock at most. My best lead so far has been RS components but their website is not showing stock availability right now. https://americas.rsdelivers.com/pro...emale-box-mount-connector-17-contacts/6269378

Digikey has the socket contacts for sale at $0.75 each. https://www.digikey.com/product-detail/en/jae-electronics/ST-JL05-16S-C1-100/670-2343-ND/2044253

Digikey also has the MDR68 panel mount connector available for $17 if @brino doesn't have the connector in his collection (thanks!!!): https://www.digikey.com/products/en?keywords=DX20A-68S

This connector has small pins for connecting to a PCB. I don't have a great way to connect to this, so I might need to order a custom PCB that breaks these pins out to screw terminals.

EDIT: Was able to get all the parts at Mouser for the best price I was able to find. Total cost for all the parts ended up being about the same as the cables  . I guess the upside is that I don't have to cut the cables now.


----------



## macardoso

Robot cables and mating connectors should be here today! I really hope everything fits together (I have about 95% confidence here). EDIT: Cables came in and fit perfectly. They are used and a bit dirty, but I'm super excited about finding them and getting them for the price I did.

I created a CMF file for the 400W T1 servo and successfully imported it into Studio 5000 Logix Designer. I am not sure how well this will run yet, but at least I figured out how to import it! The servo drive might also reject what I am trying to do (self-sense commutation) at a firmware level. I won't know until I power it up and download.

Here are the Kinetix 2000 servo drives. On top is a single channel fiber optic ring. The 4 pin connectors on the front are for the motor output and the brake, and the large connector on the bottom is for motor feedback. The plastic shell is missing off of that connector because I didn't have the correct boards for the Kinetix 2000, but I did for a Kinetix 6000 (big brother) which fit fine if you pull the plastic shell off. The left drive is much bigger than the others because it also handles converting the 240VAC to 325VDC and sharing that power across a backplane with the other drives. If one motor needs to slow down, it regenerates voltage back onto the DC bus which is available for use by any of the other drives. If the bus voltage gets too high, the first drive will shunt that power through a resistor. There is also a 44 pin I/O connector which I will need to use to hook up the optical home switches to the drive.

I have a 20A breaker for the main 240V line, a 6A for the PLC and 24V PSU to share, and 6A for the drives. 6A is a bit small for these drive's full capacity, but I won't be going anywhere near that limit. The first drive is able to convert 3kW of power for all drives to share. I have (3) 600W drives and (1) 300W drive in the rack right now.




I also installed and labeled these 3 tier terminal blocks to hook up the 68 pin SCSI cable to. I figured this would be the cleanest way to have room to work on the signals. I'll machine some sort of bracket to hold the receptacles and then bring the wires from the back into these terminals. I am *not* looking forward to soldering flying lead wires onto that SCSI connector. I found a flying lead receptacle for sale but it was $1300!




EDIT: Been looking online for the correct accessories for the Kinetix 2000 drives and they're not too expensive. If the drives end up working with these motors, I may buy the correct motor feedback + 44-pin I/O combo connector as well as mounting arms to hold and ground the power cables.


----------



## matthewsx

This reminds me of the sticker our lead network engineer has on the back of his monitor "I can explain it to you, but I can't understand it for you".

Awesome work there, especially figuring out the checksum stuff.

John


----------



## hman

matthewsx said:


> "I can explain it to you, but I can't understand it for you"


WOWSERS!  Great quote!


----------



## macardoso

Big progress last night. I soldered up a MDR68 / SCSI68 bulkhead adapter and connected it to the previously shown terminal blocks. This got mind numbingly boring as every step had to be repeated 68 times and the pins were very small, close together, and delicate.

I began soldering from the middle rows outward. I prepped all of the 22ga solid core wires by straightening them, cutting them to length, and stripping the ends to the correct length. I have a pretty good method of soldering that can get good joins in these tight connectors. I dip the tip of the wire in warm liquid flux, tin the end such that there is a slight bulge on the end of the wire, dip the tip in flux again, then use only the soldering iron and the solder on the wire to make the connection. This frees up having to have a hand to add solder. Also the amount transferred is very controlled since you can judge the size of the solder bulge before connecting to the connector. Bridging pins is the big concern here.




Here was the result after 2 hours of soldering. I love the Weller digital temperature control soldering iron I have. I broke out a brand new very fine tip for the iron to make this easier.




I added a small cut of heat shrink tubing to every wire to avoid shorts where the pins are located. Took almost an hour to get the tubing installed.




Here was the result after being shrunk with a hair dryer. The whole time I was very nervous of breaking a pin off the back. I could not find this connector with solder lugs so I was soldering to PCB pins. Breaking one pin would ruin the whole cable assembly since nearly every pin is used.




The back of every wire was stripped and had a ferrule crimped on. The ferrules aren't super necessary for solid core wire, but they make it easier to work with the terminal blocks.




I then had to trace every wire and label it with the appropriate number. I used Brady wire wrap labels at home but much prefer printed heat shrink labels.




I started to land them on the terminal blocks taking a lot of care to try to untangle them as I went along.




And done!




The factory robot signal cable fit perfectly!







All together this took 4.5 hours.   

I hope I never break a pin on this but I'm really worried about it. The outside pins got bent a lot just by working with the assembly. I have everything well zip-tied together to reduce stresses on the pins. I might see if my wife has some clear nail polish that I could use to bond the wires and pins together on the back of the connector. I am not modifying it at this point.

-Mike


----------



## macardoso

One other update...

Thanks to the excellent sleuthing work of @brino I was able to figure out that my motors have what is called a "multiplexed encoder". It definitely does commutation. There are A & B quadrature signals and one additional signal C (labeled as the differential pair Z/Z* in the robot manual - I guess just to confuse people). The C signal is some sort of composite of the U, V, W, and Z (hall effect commutation and index) signals. The circuit is pretty straightforward, but there is a Yaskawa proprietary ASIC with no documentation that does the magic to make this composite signal.

Right now I have no idea what that signal looks like or have any other information on it, but it is a start. I have an oscilloscope to check that signal and I'm hoping to have some screenshots to share tonight. There was some mention in a DeltaTau Power PMAC manual that this encoder might present some sort of signal right when it is powered on. Could be serial but I don't think so?

It is disappointing because I cannot use these motors as-is anymore since the Z channel (really the C channel) is not purely an index signal and my drives will fault on bad encoder data. My new hope is that the multiplexed signal is some sort of analog pattern (maybe a 1 cycle SIN/COS wave) that I can use to create a custom go-between circuit board (maybe several analog comparators in series) that can undo the multiplexing of that signal and pass my drives exactly the signals they expect. This would be a fun pivot on the project. If the signal is digital or serial then things get a lot more difficult and I might need to start considering encoder replacement. I *maybe* could design a board with a microprocessor on board to read this kind of data and generate outputs, but that is getting beyond my PCB design experience.

Here are two wiring diagrams from an old Yaskawa servopack manual. The first shows the motor that I have with the multiplexed encoder signal and the second shows a more "normal" incremental commutation encoder with a LOT more wires coming out of it. I would have much preferred to have that encoder.







Here was the link that brino found that first mentioned the "multiplexed encoder" (it is a bit of the ways down in the product description). This looked to be a 3rd party interface board of some sort.









						DELTA TAU:  digital interface board (ACC-8F)
					

Focus on motion control and robotics application technology, serving the global high-end manufacturing industry and becoming a leader in industry application technology.  E-MotionSupply was founded in 2014 by E-Motion America, with more than 25 years of experience in the motion control industry...



					www.e-motionsupply.com
				




" Decodes U, V, W, T and Index signals (Option 6) if they are encoded on the C+/C- channels (i.e. Yaskawa multiplexed encoders). Jumper selectable."

"Delta Tau recommends the use of this feature when working with encoders that send power-on information right after the encoder power is applied.(i.e. Yaskawa multiplexed encoders )"


----------



## matthewsx

macardoso said:


> Big progress last night. I soldered up a MDR68 / SCSI68 bulkhead adapter and connected it to the previously shown terminal blocks. This got mind numbingly boring as every step had to be repeated 68 times and the pins were very small, close together, and delicate.
> 
> I began soldering from the middle rows outward. I prepped all of the 22ga solid core wires by straightening them, cutting them to length, and stripping the ends to the correct length. I have a pretty good method of soldering that can get good joins in these tight connectors. I dip the tip of the wire in warm liquid flux, tin the end such that there is a slight bulge on the end of the wire, dip the tip in flux again, then use only the soldering iron and the solder on the wire to make the connection. This frees up having to have a hand to add solder. Also the amount transferred is very controlled since you can judge the size of the solder bulge before connecting to the connector. Bridging pins is the big concern here.
> 
> View attachment 324340
> 
> 
> Here was the result after 2 hours of soldering. I love the Weller digital temperature control soldering iron I have. I broke out a brand new very fine tip for the iron to make this easier.
> 
> View attachment 324341
> 
> 
> I added a small cut of heat shrink tubing to every wire to avoid shorts where the pins are located. Took almost an hour to get the tubing installed.
> 
> View attachment 324342
> 
> 
> Here was the result after being shrunk with a hair dryer. The whole time I was very nervous of breaking a pin off the back. I could not find this connector with solder lugs so I was soldering to PCB pins. Breaking one pin would ruin the whole cable assembly since nearly every pin is used.
> 
> View attachment 324346
> 
> 
> The back of every wire was stripped and had a ferrule crimped on. The ferrules aren't super necessary for solid core wire, but they make it easier to work with the terminal blocks.
> 
> View attachment 324347
> 
> 
> I then had to trace every wire and label it with the appropriate number. I used Brady wire wrap labels at home but much prefer printed heat shrink labels.
> 
> View attachment 324348
> 
> 
> I started to land them on the terminal blocks taking a lot of care to try to untangle them as I went along.
> 
> View attachment 324349
> 
> 
> And done!
> 
> View attachment 324350
> 
> 
> The factory robot signal cable fit perfectly!
> 
> View attachment 324352
> 
> 
> View attachment 324353
> 
> 
> All together this took 4.5 hours.
> 
> I hope I never break a pin on this but I'm really worried about it. The outside pins got bent a lot just by working with the assembly. I have everything well zip-tied together to reduce stresses on the pins. I might see if my wife has some clear nail polish that I could use to bond the wires and pins together on the back of the connector. I am not modifying it at this point.
> 
> -Mike



Very nice work on the connector, having the right iron and technique makes a huge difference

One thought for keeping pins from shorting or going open might be to pot the whole thing once you know it's all working.

Maybe something like this?



			https://www.3m.com/3M/en_US/company-us/all-3m-products/~/3M-Scotch-Weld-Epoxy-Potting-Compound-DP270/?N=5002385+3293242430&rt=rud
		



John


----------



## Boswell

Good job on the connector. Been-there/Done-That and it is tedious detailed work. Probably too late to put a larger diameter shrink tube over the bundle to keep individual wires from getting snagged. Still, I suspect that it should be reasonably robust as long as it is protected from repeated mechanical flexing.


----------



## macardoso

Been quiet for a few days but have definitely been making progress forward on this project. Mostly focused on those encoders.

First thing I found out is that the wiring table in the Seiko robot manual doesn't match the pinout at my terminal blocks. I'm not sure if I incorrectly labeled my wires (I triple checked this) or if Seiko numbered their connector differently than I did. Long story short is that I will be ohming out every pin before hooking anything up and generating my own pinout chart. No harm in doing that since it is very unlikely anyone will be recreating my work here.

I hooked up a Fluke Scopemeter I borrowed from work to the T2 axis encoder on the A, B, & C channels. I knew from the information in the post above that I had a "multiplexed" encoder. I had all kinds of ideas in my head about what this might look like, but most of them were centered on some sort of an analog signal. I couldn't have been more wrong! Turns out that Yaskawa came up with this super interesting way to encode this third digital channel with a square wave. The "C" channel square wave rises and falls relative to the A & B channels in a total of 6 different patterns. Not surprisingly, this corresponds to the number of valid unique states of normal 3 wire hall effect commutation signals (the kind I am used to seeing on a "normal" servo).

Below are oscilloscope screen shots of the 6 unique patterns. I have named each of them based on their logic relative to the A & B phases. The C channel of the encoder is recorded on channel D of the scope because I liked the green trace better than the grey one of channel C  

*NOT A*


*NOT B*


*A NOT B*


*B NOT A*


NOR* NAND*


*XOR*



These patterns occur in a very particular order depending on the rotation direction of the motor.

The order goes as follow when channel A leads channel B. This would correspond to a rotation of T2 CCW when viewed from the top of the robot. *NOT-B -> A-NOT-B -> XOR -> B-NOT-A -> NOT-A -> NAND*

If the direction of the motor is reversed, the signals reverse as you'd expect. In this case, channel B would lead channel A (as shown in the pictures above). This corresponds to a rotation of T2 CW when viewed from the top of the robot:* NAND -> NOT-A -> B-NOT-A -> XOR -> A-NOT-B -> NOT-B*

These patterns wrap back around to the beginning so in the case of A leading B, NAND would change to NOT-B and in the case of B leading A, NOT-B would change to NAND.

Each pattern is present for 85 periods of either channel A or channel B (340 quadrature counts). This encoder has 2048 lines or 8192 quadrature counts per revolution. This means the full cycle of 6 patterns repeats 4 times or once per magnetic pole pair. I've done a lot of reading on servomotor commutation lately and this was exactly what I expected to see!

The next challenge will be to try to figure out which pattern of pulses corresponds to the appropriate coding of traditional hall effect signals. My intention currently is to try to design a PCB of discrete digital components that can decode this multiplexed signal in real time and convert it into the standard signals my drives are used to seeing. I have very little experience in digital logic design (especially time series logic design) but it will be a really fun thing to try to learn.

If all else fails, I am actively trying to locate replacement motors (AB TLY series) and I have already identified suitable replacement commutation encoders, however each of these have significant issues (mainly cost and the need to completely rewire the robot).

Thanks for following along!

-Mike

Bonus image (Transition between 2 patterns NAND to NOT-B):


----------



## macardoso

Had one last chat with Yaskawa and got all the remaining motor parameters! They have been so helpful - can't believe it.

With that info I can build four final CMF files to import these motors into Studio 5000 Logix Designer. Here are the possible steps to get these motors/robot running.


Run the motors with self-sensing commutation and no index pulse. This does not require dealing with the multiplexed encoder, but it is likely the drive will not accept either the missing index pulse or the request to do self-sensing commutation. This would be a firmware level issue that I could not fix. Downside is self-sense commutation is less accurate and causes motor motion at startup (up to 60 degrees at the motor shaft )
Run the motors with self-sensing commutation and an index pulse. The index pulse can be obtained by re-wiring the connector inside the encoder and disconnecting the multiplexed channel all together. The drive may still reject the request to do self-sensing commutation. This would be a firmware level issue that I could not fix. Downside is self-sense commutation is less accurate and causes motor motion at startup (up to 60 degrees at the motor shaft)
Design and build a custom circuit board to decode the multiplexed signal and change the CMF files to state that the motor should use hall effect commutation. My drives would ideally have no idea that there was a multiplexed signal at all. The big IF here is designing that board. This is the option I am actively researching because it sounds like the most fun.
Replace encoders with aftermarket commutation encoders. Would cost roughly $250 and require a lot of work to mount and align the encoder, as well as rewire the motor harnesses for the additional wires.
Replace the motors with AB TL or TLY series motors. I have identified semi-suitable replacements which would require shaft adapters. The motors are hard to come by and pretty expensive on eBay (~$1500 for the 4 motors even if I could find what I needed). Perhaps these would turn up at work but unlikely. Again a total rewire of the robot would be required.
Replace the motors with AB MPL series motors. I have better access to these, however they are significantly different dimensionally. I would need to make substantial changes to the motor mounting hardware on the robot including new brackets and shaft adapters. The motors might not fit nicely inside the robot housing. Again a total rewire of the robot would be required.
I have fairly good confidence that I can make either option 1, 2, or 3 to work now. And with the final motor data, options 1-4 are possible. Without that info I would have had to replace the motors entirely. 

-Mike

EDIT: Updated on 5/20/2020 to include the option to use the index signal present at the encoder connector but not wired to the robot. Signal is 5V single ended.


----------



## macardoso

Spent last night finalizing my understanding of the multiplexed signal coming from these encoders. Using a circuit diagram I managed to find, I was able to identify which pins of the integrated circuits on the encoder PCB corresponded to which Hall Effect commutation signal state. This was important, because I could see what the different states of the signals were *before *they got multiplexed in the ASIC and compare that to the multiplexed output. 




Using some extremely fine (.002" DIA) magnet wire, I was able to solder to each pin I was interested and plot that signal alongside the outputs from the chip measured at the terminal blocks. This was really tricky because I have no light where the robot is right now so did everything by headlamp, and I had to stand on top of the table to reach the motor. Made it really difficult to do some really fine pitch soldering. No shorts though! I couldn't use any flux due to concerns of contaminating the code wheel. I also covered it in plastic when I was not soldering to keep dust out.







And a super close up showing the wire soldered to pin 2 of the Yaskawa JL-041A ASIC.




Here is what I found. All images show channel A leading channel B. Applicable Hall Effect signal is shown as the black trace.

When scoping pin 3 (Hall Channel U), the multiplexed signal could be seen transitioning from NOR to NOT B as channel U rose.




The multiplexed channel could be seen transitioning from XOR to B NOT A when the channel U fell.




When scoping pin 2 (Hall Channel V), the multiplexed signal could be seen transitioning from B NOT A to NOT A as channel V rose.




The multiplexed channel could be seen transitioning from NOT B to A NOT B when the channel V fell.




When scoping pin 1 (Hall Channel W), the multiplexed signal could be seen transitioning from A NOT B to XOR as channel W rose.




The multiplexed channel could be seen transitioning from NOT A to NOR when the channel W fell.




I also scoped the Z0 signal (Index signal) and compared it to the multiplexed signal. The Z0 pulse only occurs once per motor revolution, or once every 4th set of multiplexed patterns. The index pulse comes across as an extra long high state near the end of the XOR pattern where it transitions into B NOT A.




The pattern is nearly identical in the reverse direction (Channel B leading Channel A) but slightly different.




Additionally I was able to confirm that the Z index signal is available (not multiplexed) on pin 4 of the encoder. Yaskaw did not land a wire on this, but it does leave the option for me to rewire the connector to ignore the multiplexed signal, transmit the Z index pulse to the drive, and use self-sensing commutation. You can see the un-pinned slot in the connector where the index pulse is present.




Thanks to this information, I was able to build a full timing diagram of the encoder signals and multiplexed patterns. I am using this to write a specification for a digital circuit to decode the pulse stream. It is a lot more complicated than I expected and requires knowledge of the current and past 3 states of all signals after each quadrature count. I am not a member on any electronics forums, but I intend to ask for help evaluating the feasibility of this circuit on those forums. 




I should probably try running a motor with self-sense commutation soon, but I am enjoying decrypting the secrets that Yaskawa packed into their ASICs and trying to learn enough about digital circuits to decode this signal back to the original signals.

-Mike


----------



## macardoso

Also sorry if anyone came looking for machining, you won't find any of that here


----------



## macardoso

I joined the "All About Circuits" forum and posted my questions regarding designing a demultiplexer for the encoder commutation channels.









						Help Me Design - Encoder De-multiplexer
					

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...




					forum.allaboutcircuits.com
				




I will be interested what people have to share and teach me, but for the time being I am going to start investigating the self-sense commutation or "wake and shake". Perhaps tomorrow I will remove the belt from the Z axis motor and start trying to run it with my servo drives.

Here is a timing diagram I drew up for the entire encoder cycle of patterns based on the oscilloscope images I have taken (areas of repetitious patterns are hidden with breaks).


----------



## ats1911

macardoso said:


> Here is a timing diagram I drew up for the entire encoder cycle of patterns based on the oscilloscope images I have taken (areas of repetitious patterns are hidden with breaks).



It looks like this would fit nicely in an FPGA, probably even a CPLD.  What are the voltage levels?

It’s been a LONG time since I did K maps and such, but only a few years since my last VHDL/Verilog so I’m sure I could figure it out. I’m not familiar with servo controls, though, so I’d have to rely on you for that.


----------



## macardoso

ats1911 said:


> It looks like this would fit nicely in an FPGA, probably even a CPLD.  What are the voltage levels?
> 
> It’s been a LONG time since I did K maps and such, but only a few years since my last VHDL/Verilog so I’m sure I could figure it out. I’m not familiar with servo controls, though, so I’d have to rely on you for that.



Wow! I would really appreciate any help that you could give. I know next to nothing about FPGAs other than what they are and what they do. I'll shoot you a PM with a couple more details. The input voltage is 5VDC driven by an AM26C31 line driver. The output is 5V differential and I'd probably use that same line driver on the output.

Thanks so much for reaching out,

-Mike


----------



## macardoso

Made a bunch more progress this weekend. Disclaimer, no I do not yet have any motors running, but I am getting mighty close. Troubleshooting a few more errors.

I started off by building the motor power cable assembly. I had a big spool of 14 AWG shielded servo cable from building the CNC. Bought a 150m servo cable from ebay for $30. Don't know how they managed to ship it for less than that...

I stripped back the four cables and fanned out the conductors.



Here is the circular power connector that mates to the robot power cable. It is a lightweight aluminum body and is powder-coated. The grey insert accepts stamped copper pins that are sold separately.




Each pin was crimped in place and then soldered for a better connection (I had a close, but not exact match for the crimper). The connector shell had enough room for heat shrink to be added which I liked for the strain relief. The grounds do not have wires to go all the way to the motors (the robot combines them internally) so I have to join them all together with the combined ground coming from the robot. I opted to do this with a stack of ring lugs.




The other end of the cables were stripped and ferruled to land on the drives. The exposed shields will be clamped to the motor power clamps I have coming in the mail.




Here is the finished cable assembly. You can see the combined ground ring lug stack behind the zipties.




The drives are starting to come together! The cable clamp arms will help reduce emitted noise and secure those motor leads better.




And finally, the union between the robot power cable (green connector on the right) and the new cable I built (black on the left).


----------



## macardoso

Went to Home Depot to find a 12mm hex bit to remove the robot from the aluminum chunks it was mounted to. They didn't have any that big so I bought a small pipe wrench. Reminded me of the corrugated head screw this picture...




With some persuasion, I got the original M12x1 bolts broken loose and the aluminum pads removed. They're an inch thick so I can make something nice from them! The table was marked out and drilled for four 1/2-13 bolts and got the robot bolted down. The robot was very easy to slide on the slick table surface with the aluminum blocks removed.







I did a bunch more wiring to connect the motor brake on the Z axis and the contactor enable to the drives. It is a touch messy but I can clean it up later. The contactor enable allows the drives to control their input power, only turning it on when they are ready. It also allows them to disconnect from the line if there is a voltage spike.




I also got the rest of the Custom Motor Files made and imported to the PLC programming software. So far so good!

And here is the full control board with the PLC rack. The PLC accepted the program download and the drives accepted the configuration. There are a lot of firmware checks that happen behind the scenes that could have rejected my setup, but it looks like everything is happy so far. I also found some special  SERCOS (fiber optic network) IDN parameters that I can message to the drives to configure them to do the self-sense commutation. That really reinforced my belief that these drives are capable of it.




The 3rd drive (Z axis) shows a Phase 4 indicating the configuration was fully accepted and the drive is ready to run. The other drives are inhibited from running since I don't want to accidentally run a motor that is hooked to a gearbox and cause the robot to crash. The Z axis motor has its belt removed for this testing. It was the easiest to get access to.







I tried to start the motor and was hit with a ton of errors. First one was that I forgot to disable the drive from checking for a hardware enable input signal. After I fixed that, I couldn't start the drives because the DC bus was down at 15VDC (should be at 325VDC). Turns out I accidentally wired the AC input with 2 conductors of L1 and the control power with two conductors of L2. After switching them such that each power input had an L1 and an L2, the drive had plenty of DC bus voltage. Finally I tried to start it again and it immediately faulted with an E07 - Motor feedback loss. I have not solved this just yet.

E07 is normally caused by bad wiring to the encoder or bad noise. I am omitting some wires which might normally be there so I think I need to try to figure out how to trick the drive into ignoring these. Might try tying them all to ground.

The fact that the drive is letting me get this far is really encouraging. Hoping to get a break through soon.

In parallel I am still looking into the signal de-multiplexer. Having the hall effect signals available for input into the drive would be tremendously helpful and would eliminate the need for moving the arm at power-on to detect the commutation angle. It would provide a more quiet, cooler running, and better controlled motor as well.

-Mike


----------



## macardoso

Spent a little more time investigating the E07 error that I get when trying to run the motor. I am guessing the drive doesn't check if it likes the feedback until you try to close the servo loop.

Here is what the manual says about the fault. Not a ton of info, but OK.




The manual also has a couple more excerpts that state the acceptable signal levels on the feedback. Note that I am using the TTL incremental column.




Specifically the On and Off-State voltages are important. +/- 1V to +/- 7V is acceptable according to this document with -7/+12VDC common mode voltage.




In this scope trace, the positive differential signal is compared to encoder DC COM to identify common mode voltages. It appears the A channel has about -0.2VDC and the B channel has -1.5VDC. These are within the specifications for -7/+12VDC.




In this second scope trace, the scope is setup to read across the differential signals. The A and B channels show a peak to peak voltage of 6.5VDC which corresponds to a differential amplitude of +/- 3.2VDC which is nicely within the allowable range of +/- 1VDC to +/- 7VDC. Signals are pretty clean too, especially given the number of connectors and unshielded wire segments in the circuit (no motor power applied yet...).




The point of all of this is that the A and B incremental channels look fine. However, the drive is not recording any counts coming into it. I need to play with it some more to try to identify what is going on and why the drive is not reading the signals even though I was able to confirm they fall within the boundaries.

The second issue is the signals that I do not have. These are: Z (index +), Z* (index -), TS (Thermostat), S1 (Hall Commutation Signal 1), S2 (Hall Commutation Signal 2), and S3 (Hall Commutation Signal 3).

The Z (index) input circuitry according to the manual looks like this. Note the weak pull up and pull down resistors on the input channels. This suggests to me that the input will be biased to 5VDC (differential) if disconnected which is a valid high state. I have also tried tying the + input to 0V and the - to +5V to drive the circuit into a -5VDC (differential) voltage which is a valid low state. Neither of these have prevented the E07.




The Thermostat should be disabled from a selection I made in the CMF file, but just in case I tried grounding it out too. The thermostat is shown between pins 11 and 6. I believe it to be normally closed. I tried leaving this open and tried tying it to DC COM. Neither changed the E07. My motors do not have integral thermostats.

If this were the issue, I'd expect to get an E04 - Motor Overtemp Fault.




Here are input diagrams from another drive (Ultra 3000), but I'd expect similar or identical circuitry on the Kinetix 2000.







Finally we come to the hall effect inputs. These should be disabled by my selection of Incremental AQB feedback w/o Halls in the CMF file, however this configuration is not used on any Allen Bradley motor. It is supported in the drive firmware from everything I have found, but there is no documentation on how to use this feature. I can't find any input specifications or wiring diagrams either. I tried leaving them floating and tying them to DC COM, but that did not help the E07 either.

Here is an input diagram from another drive (Ultra 3000), but I'd expect similar or identical circuitry on the Kinetix 2000.




If this were the issue, I'd expect to get an E11 - MotFeedbackFault, Illegal Hall State.

As a recap: Whenever I MSO (command to turn servo on) or run the Command & Feedback hookup test (checks drive output and feedback wiring), the drive immediately faults with an E07. In the Quick View pane (notification window in Studio 5000 PLC programming software), the axis lists a Drive Fault of “MotFeedbackFault, FeedbackFault, ManufacturerSpecificFault”.

I tried the following wiring methods to try to trick the drive to accept the signals.
•    Wired only A, A*, B, B*, 5V, COM
•    Wired A, A*, B, B*, 5V, COM + tied Z* to 5V
•    Wired A, A*, B, B*, 5V, COM + tied Z, Thermostat to COM + tied Z* to 5V
•    Wired A, A*, B, B*, 5V, COM + tied Z, S1, S2, S3, Thermostat to COM + tied Z* to 5V

So far I cannot enable the motor without a fault.

One final thing to note is this table from the manual describing the encoder power supply inside the drive. All 4 encoders have their power connections tied in parallel internal to the robot. I do not think it is wise to try to parallel the power outputs from the different drives, so 1 drive will end up powering all 4 encoders. This might require more power than the supply can deliver and force me to purchase a small 5V external supply.


----------



## brino

Mike,



macardoso said:


> I do not think it is wise to try to parallel the power outputs from the different drives



Agreed, not wise!

Can you measure the current draw on the four parallel encoders to see if it's anywhere near the supply limit?
Alternately, can you measure any droop in the output voltage? (although the current measurement is more useful....)

-brino


----------



## macardoso

brino said:


> Mike,
> 
> 
> 
> Agreed, not wise!
> 
> Can you measure the current draw on the four parallel encoders to see if it's anywhere near the supply limit?
> Alternately, can you measure any droop in the output voltage? (although the current measurement is more useful....)
> 
> -brino




I did a quick measurement last night on voltage droop. I can check current next. Measured at the drive terminals, the voltage is 5.10VDC. With only 1 encoder powered on (Z axis), the voltage is 4.88VDC at the encoder terminals. With all encoders powered on, sharing the same power output, the voltage measured at the Z axis encoder terminals is 4.40VDC.

I think that is probably a bit too low to be acceptable. I think the difference in voltage at the drive and at the encoder is due to wiring resistance.


----------



## macardoso

I just had a thought and wanted to add one more option for moving forward. I have a number of very old tiny servos (AB Y-series) that were thrown away with cut cables. They are the wrong winding voltage and the cables would be a pain to replace. 







The encoder has the identical line driver to the Yaskawa encoder so I can use it as a known good reference for signal integrity and drive compatibility. I can also start removing wires one at a time to figure out what will fault the drive with an E07. The voltage signals seem to be in line with what I was scoping.




What I could also do is remove the encoder (I know it is compatible with my drive) and potentially mount it to the motors on the robot. I would only do this if the motors were physically incompatible with any of the motors on the robot in case I ever wanted to use these motors with the robot. The encoders from these motors have all 14 wires including all the commutation signals.


----------



## macardoso

Hi all,

I have been working on the encoder dilemma 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. I still feel this is the path of least resistance to getting a running motor, however I got frustrated with it last week and set it aside.

The other path is getting the custom encoder de-multiplexer circuit 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.

-Mike


----------



## matthewsx

Wish I could offer help but it looks like you're on the way. Persist, you will prevail


1ohn


----------



## ats1911

And you say you’ve never done this before....  Awesome progress.


----------



## macardoso

ats1911 said:


> And you say you’ve never done this before.... Awesome progress.



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


----------



## macardoso

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


----------



## macardoso

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


----------



## macardoso

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


----------



## macardoso

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.


----------



## macardoso

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


----------



## Boswell

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.


----------



## macardoso

Boswell said:


> 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.



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.


----------



## ats1911

I wrote up some Verilog and a test bench to go with it, and implemented it in a Xilinx XC9536XL (their smallest 3.3V CPLD).  The zip file attached is for Xilinx' ISE software (which you can download for free at xilinx.com, but you will have to search to find it because it's obsolete since 2013).  The newer Vivado suite doesn't support CPLDs or even the older FPGA families.

I don't have the faintest idea if this is right, but it's based on the Simon schematic and hopefully I didn't hook anything up incorrectly.  It at least compiles and simulates.

Be gentle, it's been a few years now since I wrote any Verilog....


----------



## macardoso

ats1911 said:


> I wrote up some Verilog and a test bench to go with it, and implemented it in a Xilinx XC9536XL (their smallest 3.3V CPLD).  The zip file attached is for Xilinx' ISE software (which you can download for free at xilinx.com, but you will have to search to find it because it's obsolete since 2013).  The newer Vivado suite doesn't support CPLDs or even the older FPGA families.
> 
> I don't have the faintest idea if this is right, but it's based on the Simon schematic and hopefully I didn't hook anything up incorrectly.  It at least compiles and simulates.
> 
> Be gentle, it's been a few years now since I wrote any Verilog....



Thanks so much! Give me some time to look up the software and chipset. Really appreciate your help with this. Would be a great intro to CLPD/FPGA for me


----------



## macardoso

I have completed selection of the actual chips for my discrete digital solution to this problem. I have laid out the components on a PCB but have not routed it yet. There are 14 chips, 1 clock oscillator, decoupling capacitors, and screw terminal connectors. The board has an overall dimension of 2.62" x 1.70" (4.5 sq. in), but this might increase if I add mounting holes. The Auto Router finished 100% on the first pass, so I expect to not have too much difficulty routing the board. The small buffer in the top right corner might be a bit tricky to solder. Since I have so much room for it on this board, I might pick a larger package size. 

Eagle Schematic based on circuit simulation linked above:



Board layout linked to the above schematic.


	

		
			
		

		
	
"


----------



## Boswell

Do you intend to hand solder or reflow?  The last couple of batches of surface mount boards I have made I used a small toaster oven to reflow and it worked pretty good. I purchased a stencil at the same time as the boards and used Solder paste that I got via Amazon


----------



## macardoso

Boswell said:


> Do you intend to hand solder or reflow?  The last couple of batches of surface mount boards I have made I used a small toaster oven to reflow and it worked pretty good. I purchased a stencil at the same time as the boards and used Solder paste that I got via Amazon



I intend to reflow using a hot air rework station (this is the only way I've ever done it, toaster ovens look great though). I think I'm going to buy from JLCPCB and get the stencil at the same time. I picked larger SOIC packages to have as little fuss as possible with the soldering. They are big enough I could probably hand solder them if I wanted. Do you have a recommendation for a solder paste you liked? I've had mixed results with different brands. Leaded is fine for me.

Current cost looks to be $15 + $25 DHL shipping for 10 boards and stencils. Looks like delivery is 1-2 weeks from ordering.


----------



## Boswell

looks like I was wrong about purchasing from Amazon.  here is what I have.

The solder I use is 63Sn/37Pb from Zephyrtonics
Solder paste reflows at 183C  /   361.3F

Here are my process notes

Step 1 : Oven set to 225F pause 2 min after 225 is reached
Step 2 : Oven set to 250F Pause 2 min after 225 is reached
Step 3 : Oven set to 325F Pause 1 min after 325 is reached
Step 4: Set oven for 365F and watch for Reflow
Step 5 : Pause 5 seconds after reflow is observed
Step 6 : Set Oven to OFF
Step 7 : TAP oven gently
Step 8 : Open door to allow quicker cooling


I used a thermocouple to monitor actual air temp in the oven.
I would do any hand soldering (connectors) after the reflow for the SMD


----------



## macardoso

Boswell said:


> looks like I was wrong about purchasing from Amazon.  here is what I have.
> 
> The solder I use is 63Sn/37Pb from Zephyrtonics
> Solder paste reflows at 183C  /   361.3F
> 
> Here are my process notes
> 
> Step 1 : Oven set to 225F pause 2 min after 225 is reached
> Step 2 : Oven set to 250F Pause 2 min after 225 is reached
> Step 3 : Oven set to 325F Pause 1 min after 325 is reached
> Step 4: Set oven for 365F and watch for Reflow
> Step 5 : Pause 5 seconds after reflow is observed
> Step 6 : Set Oven to OFF
> Step 7 : TAP oven gently
> Step 8 : Open door to allow quicker cooling
> 
> 
> I would do any hand soldering (connectors) after the reflow for the SMD



Is there a reason for the reflow profile? I've always done the hot air rework pencil until reflow occurs and then let cool. Obviously violating the reflow profile that is published.


----------



## brino

@macardoso and @ats1911 ,

I think the Xilinx 9500XL series is the perfect fit for this!

I wanted to jump in earlier, but my VHDL is too rusty to be any help.

I may however have some parts, some little debug/eval boards and a way to program them!
I believe I had XC95288XL and maybe XC95144XL, I will have to dig a little though......

I will see what I can find/provide and report back.
I'd be happy to be part of this collaboration!

-brino


----------



## Boswell

macardoso said:


> Is there a reason for the reflow profile?



I used a profile that I found from someone else and probably some online documentation. While I don't know for sure, I think that the main purpose of the heating profile is to 
1. Allow all the parts to come up to temp at the same time even with different thermal characteristics
2. To be above the reflow temp for the shortest period of time. 

So basically pre-heat everything evenly to just below reflow, then bring above reflow and cool down. 

In the end for me, this worked so I avoided trying to fix what was not broke .   If I was in production (Electronics is just another hobby) I would spend more time to optimize.


----------



## macardoso

brino said:


> I think the Xilinx 9500XL series is the perfect fit for this!
> 
> I wanted to jump in earlier, but my VHDL is too rusty to be any help.
> 
> I may however have some parts, some little debug/eval boards and a way to program them!
> I believe I had XC95288XL and maybe XC95144XL, I will have to dig a little though......
> 
> I will see what I can find/provide and report back.
> I'd be happy to be part of this collaboration!



We would love to have you! I'm going to try to push this discrete board out the door and then switch gears and try to learn about the CPLD. I have no experience with it, but it sounds like an awesome technology to try to learn.

Thanks for the details about reflow!


----------



## macardoso

Board is routed!

I gave it a good go trying to do it by hand, but kept getting myself stuck. Ran the autorouter and was able to find a solution that worked well. I spent some extra time cleaning up the traces it left with sharp corners or weird squiggly lines. I added a ton of GND vias to stitch the planes together. 

The board passes a design rule check with 10 thou traces and 10 thou spacing. 

I still need to do the following:

Finish stitching the GND planes
Verify the schematic one more time
Quadruple check the terminal block spacing (I want them to snap together)
Manually add device labels and silk screen text.




A couple of features that I added last minute were two blue LEDS. One to indicate logic power and one for encoder power. Additionally, I included solder jumper pads to select between the logic being powered by the servo drive or the external power supply, and a second set for the encoder.

For my robot, I cannot power the encoder from the drive, but if anyone ever wanted to run just a single motor connected to a drive, then the drive power supply could be used by changing the jumper on the board.

100uF ceramic caps filter both power supplies, and a larger buffer package was added because I had space. Every chip is decoupled by a 0.1uF ceramic cap.

I opted for no mounting holes at this time to keep the size down. It will hang in-line with the encoder cable, probably just below the drive.


----------



## homebrewed

Boswell said:


> I used a profile that I found from someone else and probably some online documentation. While I don't know for sure, I think that the main purpose of the heating profile is to
> 1. Allow all the parts to come up to temp at the same time even with different thermal characteristics
> 2. To be above the reflow temp for the shortest period of time.
> 
> So basically pre-heat everything evenly to just below reflow, then bring above reflow and cool down.
> 
> In the end for me, this worked so I avoided trying to fix what was not broke .   If I was in production (Electronics is just another hobby) I would spend more time to optimize.


There are two reasons for the stepped-temperature profile.  One is to drive any absorbed water off in a fairly gentle manner so the SMD's (and board) don't delaminate due to the so-called popcorn effect -- absobed water turns into steam inside the packages or layers and expands the molding compound or board enough to break bond wires or board vias.  Seen it.  It can cause really baffling failure modes.  The other issue is that the flux in solder paste has a certain amount of water in it, so if it's heated too fast it literally bubbles up and can move parts around before the solder melts.  Seen that, too, but it is more of an issue with very small parts -- CSP's in particular (and you _probably_ aren't using any of those).

Toaster ovens are cheap so a nice solution for hobbyists that assemble boards on an occasional basis.  Way cheaper than an SMD rework station.


----------



## macardoso

Boards have been ordered! Have to place the order for all the components too and pick up some solder paste. I got 25 boards (added $2 over getting 5) and a stencil for $16 + shipping. I hope the quality is good!

Even more, I hope the circuit is correct. It all works in my head, but we will have to wait and see if all of those electrons go where they are supposed to.

On the side, my plan is to work with @ats1911 and @brino to develop a CPLD solution to this problem. It seems way over my head, but the parts are cheap and supposedly are perfect for what I am trying to do! I'm excited to learn about them.


----------



## brino

Mike, from what we have seen here, you and your buddy are more than capable of designing your own VHDL/Verilog source code, committing them to parts and building what ever complex circuits you want!

This should be a fun project for all of us!

-brino


----------



## macardoso

The demultiplexer boards are here! I have assembled a test article and plan on testing it this weekend. I'm going to hold off on assembling them all until I am sure that they work as intended.

I ordered them from JLCPCB with black solder mask and Hot Air Solder Leveling. For how inexpensive these were, I am very impressed by the quality.







Before assembling the board, I did a 100% test of every connection against the original schematic by doing a point to point check with a multimeter. This hopefully would have caught any errors in either my PCB routing or the manufacturer. Everything looked great!

For those unfamiliar, this board uses surface mount components which are typically soldered with solder paste (a sludge of atomized solder and flux). The paste is placed only on the pads that need solder by use of a laser cut stencil (additional $9 to my order).







Once the paste is applied to the pads, you can use tweezers to place the components. Finally a specialized heat gun is used to reflow the solder paste and make the electrical connections. This worked almost perfectly and I bet I can even better with some practice. Here are some components for size reference.

Crystal oscillators:



14-SOIC package integrated circuits (this board uses a mix of 14 and 16 pin chips in SOIC packaging):



SOT-23/5 Digital Buffers:



0603 (60 thou by 30 thou) size resistors and capacitors:



And here is the board all assembled. The encoder input signals come in from the left and snake their way through all the integrated circuits. The encoder outputs to the drive (with commutation and index signals) exit on the right. At the top right, you can see the power filtering, LED indicators, clock source, and jumpers.




The logic powers up perfectly. If I were to do this again, I would probably pick a larger resistor value for the LED. It is very bright.




Using the oscilloscope, I was easily able to pick up the 8MHz clock signal (the squiggles are mostly from the length of socpe probe wire)




Here is my adapter board hooked up to the Allen Bradley servo drive breakout board. It just hangs beneath. I might machine or 3D print a case.




And finally, mounted to the servo drives.




I plan on powering this up today and scoping all the input and output signals. I am maybe 60% confident that it will work correctly and produce the desired outputs. There is a big question of how the drive will handle the initial power on of the encoder. No halls signals can be generated until the motor has moved at least 3 counts (sometimes 4). I still think the encoder might do something funny at power on to setup the halls outputs, but we will have to see. Worst case, I'll have to manually push the robot around just a little bit before it can be run by the servo drives.

I'll get more pics of the soldering process when I do the next 4 boards.

-Mike

EDIT: A bit more learning about PCBs after this order was placed would drive me to make the following changes on a second revision if one were ever made:

Fusing on the input to protect the drive or external power supply
Reverse polarity protection on power inputs
Footprints to prevent the possibility of adding two jumpers at the same time on the input power configuration (could damage drive)
ESD protection diodes on all pins
Footprints for optional LEDs on all input and output pins (easier troubleshooting)
Extend the board and add Silkscreen for the terminal connections to the top of the board
Mounting holes
Fix the LED footprints (they were wrong from an online download and were quite difficult to solder.
Change the encoder side terminal blocks from 10 to 12 and include a place to land a cable shield and pass it through to the drive


----------



## brino

Mike,

The boards look great, congratulations!

Your list of improvements looks like a list of our DFx guidelines from work (DFM=Design For Manufacture, DFT=Design For Test, etc.)

The only (small) piece of advice I could add would be to add some "rework" room between the outside rows of logic devices and the connectors. If you find that you need to add one jumper to one of those device pins you'll have a hard time getting a soldering iron in there to do it.

This project continues to impress!

-brino


----------



## macardoso

brino said:


> Mike,
> 
> The boards look great, congratulations!
> 
> Your list of improvements looks like a list of our DFx guidelines from work (DFM=Design For Manufacture, DFT=Design For Test, etc.)
> 
> The only (small) piece of advice I could add would be to add some "rework" room between the outside rows of logic devices and the connectors. If you find that you need to add one jumper to one of those device pins you'll have a hard time getting a soldering iron in there to do it.
> 
> This project continues to impress!
> 
> -brino



Thanks for the tip and the compliments! I am guessing I'll make a slightly modified revision B of this board and I'll try to add some more room! If you had any other general DFM tips and tricks, I'd love to know more about them. Pretty new to the whole PCB world.


----------



## macardoso

Started testing the board on the robot. I began by hooking the board up to the encoder but not plugging it into the drive. I used the oscilloscope to measure the input A, B, & C channels while using the 4th probe to test various points on the board. This would be an excellent for a Mixed Signal Oscilloscope with a logic analyzer (lots of digital only channels), but I don't have one. Here's what I found.




The A, A*, B, & B* signals all come through very cleanly and the output voltage is right on the money. Since these more or less pass through the board, they don't have any distortion or glitches. As a bonus, the use of the transceivers on the board clean up the noise spikes that come from the robot wiring before it hits the drive. 

The Z index signal turns on and off at the right time - once per revolution - and rises and falls sharply. It is ON for 1 quadrature count. Unfortunately there are a lot of little glitches in the signal. They seem to be (I haven't fully tested this yet) a one clock cycle high pulse when the signal should be low. The bottom trace (D) is the Z index signal and the lower middle trace (C) is the multiplexed signal from the encoder. The three high counts in a row on the C trace triggers the output of the pulse on D.




The S1, S2, and S3 signals properly decode the encoded C channel. Each of the signals rise and fall at the correct transition between patterns on the C channel. I am so stoked about this. There is really no reason why this couldn't have completely failed to work at all, but somehow I was actually able to learn enough about digital circuits to build a board that decoded them! Here are some pictures showing the transition of one of the hall effect commutation signals at the transition of a pattern on the C channel.







Just like the Z channel, there are extremely brief pulses (either high or low) that are not supposed to occur. More concerning however are glitches that turn OFF the output for exactly 3 counts when it should be ON.







My working theory is that both types of glitches occur at the rising and falling edges of the signals and happen when the clock pulse occurs at a bad time. For example, lets say A is HIGH and B is rising, and at the same time C is falling. At this exact moment, the clock samples the input. It registers A and B as HIGH but C had not yet fallen low enough and gets sampled HIGH. This passes the incorrect information into the circuit and a different pattern is detected and the output glitches high or low. On the next clock pulse, the input is sampled again and the error is corrected, giving a 1 clock pulse glitch on the output. 

The worse case is when the sample occurs on the falling edge of a quadrature count. Lets use the same example as before A is HIGH, B is rising and C is falling. This time the clock pulse arrives a few nanoseconds earlier and the inputs are sampled. A is sampled as HIGH, B has not risen high enough so it is sampled as LOW, and C has fallen low enough to be sampled as LOW. In this case the state we are exiting (A high B low) is sampled incorrectly and a glitch is passed into the circuit. Unfortunately on the next clock pulse, B has risen HIGH and we are in a new state (A high B high). The erroneous sample is latched into memory until 3 quadrature counts have occurred and the first state (A high B low) is presented again and is sampled correctly. I think that this is what is occurring in the pictures above. 

I'm probably going to ask for advice on the electronics forum that I joined during this project. I don't think normal noise suppression techniques will help the short glitches because the signal is being driven by a powerful transceiver rather than weak radiated emissions and it definitely won't help the larger glitches. I think this is just an issue with trying to sample a parallel asynchronous signal (encoder input) into a synchronous clocked circuit.

More to follow...


----------



## macardoso

After testing the circuit on the bench, I hooked it up to the servo drive, edited the CMF file to indicate the motor has hall effect commutation signals, and download the configuration to the PLC.

The mess of wires all over the place are the scope probes for testing. The wiring is pretty clean with just the encoder.




The drives accepted the configuration and were immediately able to read the A and B feedback channels (the motor position updated correctly when I turned the motor shaft by hand). In the motor configuration menu is a page called "Hookup". These Hookup Tests are the most important thing to tell you if the drive and motor are configured and wired properly.

The first test is called the "Marker Test". It requires you to rotate the motor shaft by hand and the test will complete when the marker/index/Z pulse is found. This should always occur in the same position. When I ran this test, it would complete in random locations within a quarter turn of the shaft. I'm pretty sure the drive is picking up the 1 clock cycle (125 ns) glitches and thinking they are the marker pulse. This means that without correcting my adapter board, I will not be able to home to the index pulse on the motor. This doesn't prevent me from running the motor thankfully.

The second test is called the "Feedback Test" and it requires you to define a distance and rotate the shaft manually. When the correct distance has been reached, the test completes and the feedback polarity is set in software. This tests the correct quadrature counts are being received by the drive. I was able to complete this test without issue.

The final test is the most important and is called the "Command and Feedback Test". The drive powers the motor open loop and monitors the position and commutation feedback. This test passes when the motor moves the correct distance as specified in the test setup and the drive detects no wiring errors. This test will fail if the motor power wires are swapped (UVW) or the commutation signals are swapped (S1, S2, & S3).

This test gave me the most trouble because the Yaskawa motors are wound differently than AB motors and therefore use a different convention for the assignment of U, V, & W and S1, S2, & S3. There are 36 possible combinations of these signals and it took me 12 different combinations before I found one that passed the hookup test (took me 2 hours). I want to finish testing the rest of the combinations because I expect to find 2 more valid combinations.

Once the hookup test was passed I immediately moved on to the Autotune. This powers the motor with a high open-loop torque and uses the measured response to find the system dynamics. From this information, the drive calculates appropriate gains for the servo loop to give good response. This test completed properly, however testing at higher speeds generated failed tests and a couple of motor overspeed faults on the drive. These should never happen and indicate something could be wrong with the commutation still.

Finally, with the motor sorta tuned, I tried to issue commands to the motor. It energized and held position properly and I was able to command indexing moves with acceleration and deceleration. I did notice that after some period of time the moves would fail and the motor would begin vibrating uncontrollably. Additionally I felt "soft" spots in the motors rotation where I could easily overpower the motor by hand. All of this tells me I am very close but the commutation still isn't perfect.

I have three theories on this one. #1 is that while I passed the hookup test, the motor power wiring and hall effect commutation signals are still not correct. That's why I wanted to test the 24 remaining wiring configurations. #2 is that the glitches in the commutation signals create regions of poor control in the motor. I don't think that this is really the case though because the "soft" spots in the motor are much larger than the 3 counts that the glitches seem to appear for. I can hear these glitches are audible popping of the motor shaft as it rotates however. #3 is that my circuit is not decoding the commutation signals properly. I don't have any evidence for this, but it is a possibility. All the scope traces look like it is doing everything properly, however I need to do much more comprehensive testing to really rule this one out. Probably the best test would be to scope the signal into the ASIC on the encoder again and compare it to the output of my PCB. They should be identical.

I'm feeling like I'm in the home stretch of getting this working.

Here is a short video of the motor executing indexing moves.

View attachment IMG_9228.MOV


----------



## jwmelvin

That’s some amazing work and progress. I’m rooting for ultimate success and impressed with what you have done so far. I’ve made a couple PCBs, a couple including some degree of SMDs. But nothing as detailed as what you are doing. I love it.


----------



## macardoso

jwmelvin said:


> That’s some amazing work and progress. I’m rooting for ultimate success and impressed with what you have done so far. I’ve made a couple PCBs, a couple including some degree of SMDs. But nothing as detailed as what you are doing. I love it.



Thank you so much! I feel like a complete newbie who got pretty lucky on his first try. Sort of a "It works and I don't know why" kind of thing 

I was thinking today, and short of the entire robot being broken, I've gotten about as unlucky with this retrofit as I could have gotten (probably not, but that is how it feels!). Still having a blast and really hoping I am getting close to having working motors. Thanks so much for following along.


----------



## macardoso

Quick update:

I got a small 5V supply in the mail which I added to my test setup. This is now powering all the encoders in the robot rather than trying to pull the power from the servo drives. The reason this is necessary is that the robot manufacturer tied all the encoder power wires together in parallel. The drives cannot combine their 5V outputs in parallel, and a single drive cannot supply enough current for all 4 encoders. The drive power supply powers only the logic chips on my custom PCB.

I finished testing all the combinations of motor power wiring. I still don't know how to interpret the results, but hopefully something will make sense the more I think about it. The notes below are really for my benefit.

The power connector on the drive is labeled U V W and it connects to the motor power wires with colors BRN BLK BLU. The hall effect commutation inputs on the drive are labeled S1, S2, S3 and connect to wires labeled S1 S2 S3. The tests below are listed as the wire number/color attached to the drive terminal inputs U, V, W, S1, S2, S3 in that order

The following combinations yielded successful hookup tests:

BLK, BRN, BLU, S1, S3, S2: Poor motor control, stalls after 2-3 revolutions
BLK, BRN, BLU, S2, S1, S3: Poor motor control, stalls after 2-3 revolutions
BLK, BRN, BLU, S2, S3, S1: Somewhat better control, stalls after 2-3 revolutions
BLK, BRN, BLU, S3, S1, S2: Very poor motor control, runaway motor, motor overspeed fault
BLK, BRN, BLU, S1, S2, S3: Poor motor control, runaway motor, motor overspeed fault
BLU, BLK, BRN, S3, S2, S1: Poor motor control, Failed to Autotune, runaway motor, motor overspeed fault
BLU, BLK, BRN, S1, S2, S3: Somewhat better control, stalls after 5-6 revolutions
All other 29 combinations yielded a "Motor Feedback Signal Error" and a failed hookup test. The tests that failed caused the shaft to snap roughly 60 degrees at the start of the test while the ones that passed started smoothly.

All tests that passed rotated in the clockwise direction when viewing the motor shaft. All tests were completed with the feedback polarity set to "Positive".

When a hookup test was passed, the motor was immediately tuned with the following parameters: Travel Limit - 36000 degrees, Speed - 3600 deg/s, Torque - 100% rated, Direction - Forward Bidirectional, Damping Factor - 0.8

Movement was tested by issuing a Motion Servo On (MSO) command followed by a Motion Axis Move (MAM) command with the following parameters: Incremental, Distance - 360 deg, Speed - 360 deg/s, Acc/Dec - 1000 deg/s/s. The motion was repeated until the axis faulted.

Common trends and puzzling discoveries:

All successful tests rotated the motor shaft CW when viewed from the motor face
Motor control is pretty good when first turned on, however it gets worse each time the motor moves a revolution from the starting position
Eventually, the motor stalls and produces no useful torque
Some successful tests resulted in a runaway motor condition triggering a motor overspeed fault
When motor control gets poor (after a couple revolutions), I can manually rotate the motor shaft and get it to cog to a new position.
There are an odd number of successful tests (weird)
The combination BLK, BRN, BLU was successful in 5/6 combinations of hall effect commutation signals
The combination BLU, BLK, BRN was successful in 2/6 combinations of hall effect commutation signals
All tests that were successful and didn't cause a runaway motor resulted in diminishing motor control the further the motor traveled
I think the biggest issue I need to look into is the diminishing torque. It almost seems like there is a mismatch between the number of motor poles somewhere in hardware/software. I have a few people I know at work who are pretty smart with this kind of stuff and should be able to point me in the right direction.

-Mike


----------



## macardoso

Talked with a guy I consider to be an expert in our motion control products at work about my issues. He agreed about the motor behavior being related to drift in the commutation angle. Apparently the motor mechanical and electrical angles can differ by as much as 30 electrical degrees without a significant loss of motor control, however current draw increases quite a bit as waste heat. The loss of controllability, motor oscillations, and runaway are all symptoms of incorrect commutation. Neither of us could make sense of the weird way that the hookup tests passed.

He had a couple things for me to try:

1) Measure the motor Back EMF using the oscilloscope and match it to the hall effect signals. The drive expects the signals to appear in the following order (RST is UVW and ABC is S1, S2, S3):




2) In the motor CMF file, there is a line entry for "Motor Polarity". Default is "0". Since Rockwell winds their motors such that positive rotation is CW when viewed from the motor face and Yaskawa winds theirs CCW, I think I might have needed to set this equal to "1". After scoping the motor, I will repeat the hookup tests with this value inverted. In order for the motor to function, the mechanical direction, the winding direction, the commutation signal direction, and the feedback direction must all match or be compensated for in software configuration.

He also reassured me that as long as my circuit is correctly generating the commutation waveforms, there is no reason the drive shouldn't be able to run my motors.


----------



## macardoso

After work today I spent an hour or so running the Back EMF tests on the Z axis motor. I'll attach a bunch of pictures here and discuss at the bottom.

Common to all tests: Probe A (Red) measures from Motor terminal "U" (BRN) to motor Terminal "V" (BLK). Probe B (Blue) measures from motor terminal "V" (BLK) to motor terminal "W" (BLU). Probe C (BLK) measures from motor terminal "W" (BLU) to motor terminal "U" (BRN). Motor was rotated at a relatively constant velocity with a cordless drill at a slow speed. Motor was rotated in the *clockwise *direction when viewed from the motor face. Channel D (Green) was changed between tests.

Test 1: Channel D measures PCB output "S1"



Test 2: Channel D measures PCB output "S2"



Test 3: Channel D measures PCB output "S3"



Test 4: Channel D measures PCB output "Z". Cursors are sitting on top of the index pulses.



*Results:* As expected, when the motor is spun clockwise, the back EMF signals appear to be going backwards WVU. This was expected since this excerpt from the SGM manual indicates motor direction. As a note, the motor wire colors are BRN = RED, BLK = WHT, BLU = BLU. I used servo cable I had on hand which didn't have colors to match the Yaskawa convention.




The hall effect signals seem to increment S3, S2, S1 which is somewhat expected as again the motor is rotating in the opposite direction. What is curious is that the image in the post above provided by my colleague shows the halls transitioning at the 0V crossing of the measured Back EMF signal, while the halls I measured are shown transitioning at the intersection crossing between the waveforms. I believe this means the hall tracks natively etched into the encoder disk on the motor are out of phase with the windings (for the particular way Allen Bradley drives expect to see the commutation signals).

If this is true, then the signals should be able to be corrected by applying a negative 30 [electrical] degree commutation offset to the motor. This can either be done from the CMF file (currently set to 0.0) or through a SERCOS IDN message - an instruction in the PLC which sends a command to reconfigure the drive settings over the SERCOS fiber optic network.

The description of this message is the following: "This IDN is the synchronous motor commutation offset. This is set to zero for asynchronous motors. The two bytes contain absolute position at the defined commutation vector U+, V+, W-. U leads V leads W for clockwise rotation from the shaft end. The units are electrical radians from the defined null position."

If the commutation angle is really off by 30 electrical degrees, then I am right at the limit of motor controllability according to my colleague.

I also have a feeling that I will need to set the "MotorPolarity" in the CMF file to "1" since the phases occur in the opposite order compared to what the drive expects.

One last thing is the 4th tests shows that 4 electrical cycles occur between index pulses, and that the index pulse occurs at the peak of the VW BEMF waveform. There are 4 complete signal periods between the index pulses confirming that there are 4 pole pairs or 8 magnetic poles on the motor.

I'll probably play with these settings tomorrow! Have a great 4th of July weekend everyone


----------



## macardoso

One additional thing. You can see numerous glitches on the commutation output channel (Probe D - Green). These are a real issue with my custom PCB and I think I have the issue figured out.




The issue comes about due to the encoder signal (asynchronous) being sampled into a clocked circuit. The very first thing that happens to the signals when they enter my board is that they are "synchronized" by a pair of flip flops. A flip flop is a edge triggered memory element where the value at the input "D" is latched to the output "Q" when the clock "CLK" rises from low to high.




There is a minimum amount of time that the input "D" must be stable both before and after the rising edge of the clock. This is called the setup and hold time. These are specified in the chip datasheet, for example this Texas Instruments CD74AC175 (Quad D-Type Flip-Flop):




If the input signal violates the setup or hold time, *metastability* can occur. Metastability is a state when the flip flop can get temporarily stuck between states or rapidly oscillate until it resolves to either high or low. The issue is this result is completely random and nondeterministic. 

This graphic below shows many samples of the green signal become metastable and how they can take many paths and either settle high or low (before eventually being corrected near the far right edge on the next clock pulse)




The clock that sequences the logic oscillates at a very stable 8.0000MHz. Since there is no way for me to guarantee when the input signal will change, there is a pure probabilistic chance that any given input transition will happen at the same time as the clock edge and become metastable. This is dependent on the circuit clock frequency, the signal frequency, and the proportion of time in which a setup or hold time violation could occur. This calculates to *on average* 240,000 metastable events per second when the motor is running at max speed. But not to worry! We contain this unstable signal between a pair of flip flops called a 2FF synchronizer. This forces a 1 clock cycle delay for the metastable signal to settle and assures a very very high likelihood that there will be no metastability after the synchronizer. Since the value randomly lands high or low, there is a 50% chance that the signal change is delayed by 1 clock cycle into the circuit, this is perfectly acceptable.

In the graphic below, "Din" represents the input to my circuit. CLK-A is the clock in the encoder (of which I have no control over) and CLK-B is the 8.0000MHz clock in my circuit. Each blue box represents the flip flop circuit shown above. You can see the "Din" signal rises at the same time as CLK-B. This causes the output "Ds" to become metastable, however this value settles well before the next clock pulse on "CLK-B". Notice the output "Dout" transitions very cleanly because the metastability has settled at the expense of 2 clock cycles of delay from the input signal "Din".

This synchronization is only needed when a signal is brought in from another clock source or the outside world. Once you are inside the circuit, there is no risk of metastability unless poorly designed.




But hey! I have 2FF synchronizers on all my inputs... Why do I still have glitches? 

Well, the key is that each signal randomly settles to a value when metastability occurs. In my signal, 2 inputs can change at the same time (big problem). There is some finite probability that both inputs will go metastable at the same time (actually pretty likely since they transition at the same time and all flip-flops see the same clock). If both do metastable, there is a 25% chance they resolve to the correct values, 25% chance they resolve to old (but valid) values, and a 50% chance that they resolve to one of two illegal value combinations. This 50% chance of an illegal input combination after metastability is what causes the glitches. 




If the glitch registers on the first sample of a new input combination, then the error is corrected on the next sample, however if the error occurs on the last sample before an input transition, then the glitch gets latched into memory until the encoder moves 3 more counts in the forward direction so the input sample can be corrected. These are the larger glitches shown in some of my earlier scope traces.

There is not a good solution that completely preserves data integrity without additional handshaking signals, however I realized I have an option that isn't available to most people designing circuits - it is acceptable for me to discard input samples. Since it is impossible to know if a flip-flop is metastable, I assume that the first sample after any input transition is bad and I discard it. If the next sample matched the previous, then we know the sample was good and it is OK to use the data. If the next sample doesn't match the previous, then metastability and data corruption occurred and we throw away a second sample and check the 3rd. In this way we trade a small amount of additional delay (100-200ns) for guaranteed signal integrity.

Here is my circuit modification to the input section of my circuit accomplish this. It adds 3 additional chips (3 channel 2-input XNOR gate, 3 channel 3-input AND gate, and 3 channel 2:1 multiplexer). Unfortunately I'll have to re-order PCBs, but I am going to try to rework my test board first to prove the concept before spending the money on another potentially faulty PCB.


----------



## macardoso

Worked on the commutation issues and CMF file last week. I modified the "Motor Polarity", "Commutation Offset", and "Factory Aligned" parameters, however there was not any significant change in motor performance. I also set up a message to change the commutation offset on the fly. Changing this by 30 degrees at a time did not find any value which properly operated the motor. Additionally, the motor polarity did not seem to be changed either.

I need to think more on what is going on here. I have a buddy at work who was interested in taking a look at it, so I might see if he has anything to add to this conversation.

Hope everyone had a great 4th of July.


----------



## macardoso

I have not solved the issues related to motor commutation, however I do feel that I will be able to, so I am not letting that stop me from working on other aspects of this project.

The big update right now is that I have created a Version 2.0 of the interface PCB that demultiplexes the encoders on the robot.










The new PCB is a bit longer than before due to the addition of 3 new IC's as well as "wings" on the outside of the connectors to allow me to silkscreen the pinouts on the top as well as the bottom. It was a pain to have to flip back and forth between the two sides while wiring it.

The 3 new integrated circuits modify the input sampling circuitry to block the first sample after an input state transition from entering the circuit. Only when two consecutive samples are the same can the circuit evaluate new outputs. This should prevent glitches from occurring due to sampling the signals into a clocked circuit and make it more robust against noise (at the expense of an occasional 125ns added delay to the outputs).

The power circuitry has been updated to include reverse polarity protection on the power inputs. The LED resistors have been changed from 85 ohm to 200 ohm to make them a bit dimmer. All the components have been packed more tightly together to save space. I also manually routed all the power circuits before running the auto-router to make sure it branches nicely and all chips properly engage their decoupling capacitors. I opted not to bother adding ESD protection to the inputs and outputs. All the chips come with 2kV protection built in. This isn't the best, but I'll just try to be careful with them. The cost keeps climbing every time I add new features.

The bottom row of IC's has been shifted up to make room for a thick polygon pour on the bottom edge. This is a path to land cable shield connections and pass them through into the servo drive. Without this, I couldn't land any shielded cables. I also changed the one side of terminals from 10 to 12 to add 2 locations to land the cable shield.

I feel kind of bad for the PCB company. This little board needs almost 300 0.20mm holes drilled in it for all the interconnections.

The board is fully routed, but I still need to do a wire by wire verification of the design against the simulation and fix up the silkscreen.

-Mike


----------



## brino

macardoso said:


> I feel kind of bad for the PCB company. This little board needs almost 300 0.20mm holes drilled in it for all the interconnections.



No reason to feel bad ....they should simply know their capability limits: hole size, aspect ratio(hole size vs board thickness), line widths, plating, layer alignment, etc. and charge you accordingly. You likely have no blind or buried VIAs, no buried capacitance or resistance, no exotic plating, etc.

Sure it looks complex to you and me, but their robots won't care!

How many layers is it?

-brino


----------



## macardoso

brino said:


> No reason to feel bad ....they should simply know their capability limits: hole size, aspect ratio(hole size vs board thickness), line widths, plating, layer alignment, etc. and charge you accordingly. You likely have no blind or buried VIAs, no buried capacitance or resistance, no exotic plating, etc.
> 
> Sure it looks complex to you and me, but their robots won't care!
> 
> How many layers is it?
> 
> -brino



Honestly from a PCB manufacturer's perspective, this is as easy as it gets. 2 Layer, 1oz copper, 10/10 mil trace space, 1.6mm thick. No blind, buried, laser drilled, or filled vias. No via in pad. Hot air solder leveling and black solder mask. That's how I managed to get 25 of them for $12.

Just me as a machinist, I'd be ticked off if I needed to drill 300 0.2mm holes in each board.


----------



## brino

macardoso said:


> I'd be ticked off if I needed to drill 300 0.2mm holes in each board.



Absolutely, me too!
I hate to think of how many spare drill bits I'd need due to breakage......and how many scrap boards there would be with broken bits in them.
Unless you could use broken drill bits as "plated-thru VIAs". 

-brino


----------



## macardoso

Bought the parts to complete the Version 2.0 board. Most of the parts are the same so I just needed to replace the components used on the test board and add a few extra.

I bought large DIP chips for the new components to be added to the PCB. My hope is to try to solder them up on a breadboard and rework the existing PCB to prove functionality before I order the Version 2.0 boards from China. This is going to be a bit of a nightmare to try to solder, but I'm going to at least try it.

I think I know what the issue is, but there are a few replies to my questions on All About Circuits that cast doubt if I fully understand the problem. Parts should be here by Friday so I will have something to work on for the weekend!.


----------



## macardoso

brino said:


> The only (small) piece of advice I could add would be to add some "rework" room between the outside rows of logic devices and the connectors. If you find that you need to add one jumper to one of those device pins you'll have a hard time getting a soldering iron in there to do it.



I'm pretty sure that if you never made this comment, my board would have worked on the first try! (Just kidding of course!). I'm not looking forward to having to rework the board. Of course it is on the chips right next to the terminal blocks too!!!!!


----------



## macardoso

Spend some time last week and this weekend reworking the PCB to upgrade the Version 1.0 board to a Version 2.0. As a recap, 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 did a lot of research and theorized that the issues were caused by small timing variations when bringing 3 parallel signals and sampling them into clocked memory chips (Flip-flops). Sometimes, a signal might transition a bit more slowly than the other 2 signals and would fail to get sampled into the memory until the next clock cycle. This would cause corrupted data to be presented to the circuit for one clock cycle and caused further issues in the signal decoding and output memory sections of the circuit.

My solution was to modify the input sampling circuitry by 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

While the plan is to create a Version 2.0 PCB with 3 additional SOIC (Small Outline Integrated Circuit) chips, I wanted to validate the design on the existing PCB. To do so, I bought extra of the new chips in DIP (Dual In-Line Package) packaging, a larger through hole variant of the component. These are the classic integrated circuits you see on old electronics. I soldered up a small breadboard with these components and various jumper wires to make the interconnections.






I then removed the motor side terminal blocks and the U2 chip from my functioning test board. I identified 3 traces on the Version 1 board that needed to be cut before patching in the new circuitry. The traces are 10 thou wide and 1.4 thou thick. I used a heavy duty X-acto knife to dig out the copper and make a decent sized air gap. You can see the cut traces between U2 pins 2 and 5, U2 pins 10 and 13, and U3 pins 2 and 5. When I was done, I soldered U2 back in place.




All I had on hand was some 24 Ga solid core hookup wire so I used that to solder to each IC pin that needed a splice connection. Care had to be taken to avoid lifting the leg of the IC from the pad on the PCB as the solder cooled. 12 wires were needed in total (+ 2 power connections)



The wires were secured to the board with Kapton tape to prevent strain on the connection, and the wires were labeled according to the schematic.




And the wires were terminated on the breadboard.




Wire by wire, the enitre first half of the circuit was checked, first against the schematic, and second against the simulation functional diagram (assuming the schematic was wrong). I didn't find a single short or missed connection!




I then set everything up on my bench by the robot and got to work bench testing the new circuit, just as I did with the original one. Scope channels A, B, and C measured the input channels A, B, and C, while the 4th probe "D" was used to test various locations on the PCB. The robot Z axis motor was hooked up to this board and power was jumpered to allow the board to be used without the servo drive attached.




Here is another shot of the work area.




And the results! First and foremost, the signals still come out of the board which is great news because my changes could have broken the entire thing. And second, since the addition of this circuitry, I have not seen a single glitch on the output! Everything looks very clean and I was able to verify that all channels output the correct waveform and transition at the appropriate times!




When I got done building this, I had perhaps 30% confidence that I had identified the root cause of the problems and corrected it. I am so thrilled that it worked out. My next steps are to install the reworked PCB on the drive and try to get the commutation corrected and a motor running. When that is done, I will order the new PCBs which have already been designed.

Two interesting things... With the glitches removed from the output signals, I can now successfully detect the index/marker signal (Z) when the board is connected to the servo drive. I had not been able to pass that test previously due to all the glitches triggering a premature completion of the test. The second is I observed a startup sequence on the encoder when it was first powered on. It didn't dawn on me what I was seeing so I didn't investigate further, but there was some brief signal on channels A, B, & C and the output S1 turned on (all without the motor moving). This is great news since it means the motor/custom PCB are able to transmit the correct data before the drive boots up. Then I don't have to worry about the halls state being invalid before the motor is moved. This also means the PCB must be powered on at the exact same time (or earlier) as the encoder. This forces me to power the logic circuit from the same external supply as the encoders (jumper on the PCB) or to install a time delay relay in front of the 5V external supply to delay it until the drives have powered on and are supplying 5V out to the encoder ports.

Still making progress! Thanks to everyone for hanging in there with me!

-Mike


----------



## Boswell

macardoso said:


> Still making progress! Thanks to everyone for hanging in there with me!


I can't speak for anyone else, but I am fascinated by this build and "on the edge of my seat"


----------



## BGHansen

Boswell said:


> I can't speak for anyone else, but I am fascinated by this build and "on the edge of my seat"


+1, totally blown away by what Mike is doing here.  He must have gone to the Einstein/Tesla school of Engineering!

Bruce


----------



## macardoso

Boswell said:


> I can't speak for anyone else, but I am fascinated by this build and "on the edge of my seat"





BGHansen said:


> +1, totally blown away by what Mike is doing here.  He must have gone to the Einstein/Tesla school of Engineering!
> 
> Bruce



Thanks so much guys! Truth be told I didn't really study this stuff in college other than two courses on introductory electronics. I mostly focused on control theory which I have barely used since then. I do just love to dive into stuff and try to learn what I need. Always been very interested in robotics and I'm willing to put in the effort to learn anything I need to get this working.

I really appreciate the involvement of everyone on this project. It often gives me the kick I need to keep going when I get stuck. I feel like I am letting people down when I am not making progress.


----------



## homebrewed

Even if you think you are not making progress (as far as getting positive results), in science, negative results are more powerful than positive ones.  It only takes ONE negative result to disprove a theory, while even a million positive test results are suspect because the 1,000,001'th test could be a negative result.

So if you're learning from your mistakes (and it most certainly appears you are), it's all good!


----------



## macardoso

Spent an hour on the robot last night working on commutation. Still no luck, but I have another coworker who is willing to give me a hand and see if we can get this working!

What I did figure out was the encoder startup sequence. For this test, the encoder and converter board were powered by the same 5V supply and the scope was powered on before the board and the trigger armed. When I turned on the power, the scope captured the first moments of the signals. Here is what I found (sorry some are phone pics). The traces A, B, & C are the outputs from the encoder A, B, C respectively. Channel D is scoping the S2 commutation output from my converter board.

When power is applied to the encoder, there is a small blip on channels A and B. Channel C slowly rises and then 40-50ms later, the signals crisply snap to their operating states.




If you watch it a bit longer, you see this sharp notch in the A,B, & C signals.




Here is a zoomed in view of that notch.




And Zoomed in even more! What we see here is the encoder puts out 7 forward and 7 reverse counts in rapid succession. This all happens with absolutely no motion of the motor shaft, it is a purely digitally controlled startup "message" that the encoder sends to "preload" the correct state into the receiving circuit.

I've been worried this whole time about how the drive will know the commutation state at startup without the motor moving at least 3 counts. It seems like Yaskawa knew this problem too and this is how they managed to solve it. This works perfectly for my PCB design as well and it sets the appropriate outputs just a couple milliseconds after the encoder powers on.

This startup message loads the NAND pattern into my detection circuit and sets the outputs S1 LOW, S2 HIGH, S3 LOW, Z LOW.




This does confirm that my PCB needs to be powered on at the same time as the encoder in order to detect this startup message.

Pretty darn cool!


----------



## rwm

Just don't send this thing through the time displacement equipment..
Robert


----------



## macardoso

Had a pretty big breakthrough today! My coworker recommended trying to run the motor on an Ultra 3000 servo drive instead of the Kinetix 2000 I have been using. This is an older drive but is absolutely bulletproof. I am running 6 of them on my CNC'd G0704. The drive operates completely standalone from a PLC controller and is programmed by a serial port on the front.




The configuration software (Ultraware) allows you to create custom files for 3rd party motors and runs a much simpler mathematical model of the motor compared to the Kinetix 2000. This means less motor parameters. Unfortunately without the PLC, I cannot do the kinematic transforms needed to run the robot, but this at least lets me test the motor.

For the first test, I created a custom motor with the correct parameters and told the drive to do self sensing commutation. I wired the motor directly to the drive without my custom feedback adapter board. This was initially unsuccessful, however once I wired the motor leads in reverse (WVU), the algorithm was able to power up the motor, force the shaft to a pole location and measure the commutation angle. From there, the commutation angle is measured as an incremental distance from the starting location. The motor was completely responsive and ran without problems, including some very aggressive indexing moves at the 4500rpm limit of the motor.

In the next test, I added my adapter board and changed the motor file to use hall effect sinusoidal commutation. The Ultra 3000 features a "Commutation Test" which runs the motor open loop and suggests changes to correct wiring and indicates the correct commutation offset. When this test was run, it told me to wire the hall effect feedback signals from my adapter board as S2, S1, S3 and apply a 90 degree commutation offset. When these wiring changes and configuration changes were made, the motor ran perfectly!




So here is what I learned:

The motor power wiring should be W-V-U
The hall effect feedback wiring should be S2-S1-S3
The motor works
The encoder works
The feedback adapter circuit (and rework) works perfectly
The correct commutation offset is 90 degrees
With this info, there is no reason the Kinetix 2000 shouldn't work! If I keep having issues, I can hook up a different Ultra 3000 SE which is enabled to talk over the SERCOS fiber optic ring and try to run the motor from that drive through the PLC. This will potentially have different results since it runs with the CMF file rather than the configuration I used for this drive. It also runs different firmware so it could behave differently.

View attachment 61738684628__821B0D81-290C-4C19-BF7E-713506EDC47A.MOV


----------



## matthewsx

I'ts coming along great, congrats

John


----------



## brino

Your determination (and shear intellect) are incredible.
I have no doubt you will succeed!
-brino


----------



## macardoso

Thanks guys. Means a lot. 

Slowly chugging away at this but I feel like I have not stopped inching forward. Going to revisit running it on the Kinetix 2000 drives this week. What you guys might not understand is the moment that I get this motor to run, I am basically done (hope that comment doesn't bite me in the you know what). As soon and I have the right wiring and settings for any one of the motors, the rest are near copies of it. From there, I have 4 working motors and I can probably write the entire program to run the robot in an afternoon.

I thought about going crazy and writing a basic GCode interpreter that can run on an HMI (I actually did this before for fun at work, but the files got deleted  ). That way I could get the robot to do some complex motion that I program offline just like I do for my CNC.


----------



## macardoso

Borrowed some Allen Bradley Kinetix 6500 drives from work. I have to return them, but I can use them for a while. They do their motion control over Ethernet/IP instead of SERCOS fiber optic and have newer and more featured interface.


There are a few reasons I wanted to use these. First is that Rockwell opened up the interface for the Ethernet drives to allow you to enter the motor data manually if you choose. This isn't recommended and Rockwell won't support you, but it does open the door to using 3rd party motors which just was not possible with the SERCOS series of drives.

Second is that the Ethernet drives have additional testing and diagnostics. I can run a commutation test to determine the correct commutation offset to program into the motor, and I can collect a ton of runtime data from the motor and plot it on my laptop. There are seriously hundreds of parameters and data tags you can look at. The commutation test reported a required offset of 92.5 degrees which is very close to the 90 degrees reported by the Ultra 3000 earlier in this project.

The drives I have are 480V units which I obviously don't have at home. I currently have them powered at 120V and the motor is rated for 200V. This is really not ideal, but I can disable the undervoltage protection on the drive by placing them in "demo mode". I can also disable the motor voltage mismatch fault which would prevent me from running the 200V motor with the 480V drive.

With these features activated, I entered the motor data in the nameplate entry field and was able to pass all of the hookup tests and tune the motor. It runs beautifully! I let it run for hours with zero hiccups. These drives are really high end and the motor is almost silent when running. All the other drives I have used have a high pitched whine due to the current switching frequency. I wish I had access to 4 of these in the 240V flavor for use at home, but that isn't going to happen 

My next step is to get these drives to run the motor with the data coming from the CMF file I wrote. If that works then there should be absolutely no reason why I can't run it on the Kinetix 2000 or Ultra 3000 over SERCOS.

I'll try to hook the belt up to the Z axis ballscrew and post a video of the robot moving under control!


----------



## matthewsx

Nice, have you shared this project with your AB sales rep at work? You never know what might just show up if you do....


----------



## macardoso

I've been working some long shifts at work and haven't had any shop time. Managed to get a few hours yesterday to make some progress on the robot and wanted to share.

I'm fed up with trying to get this working with the Kinetix 2000 Sercos drives. I might revisit this again in the future. It should work, and it irks the heck out of me that I can't figure it out. I'm also trying to hunt down some newer ethernet drives, but for now, I don't have any.

It dawned on me a week ago another way I can approach this. If you remember, I had the motor working perfectly with an Ultra 3000 operating as a standalone drive, but when I tried to run the motor on the exact same drive over Sercos, it wouldn't work. Well I remembered a way I can get it to work with the standalone drive and the PLC running the robot math. Rockwell makes a servo interface module for the PLC called the 1756-M02AE. It is a 2 axis analog servo module designed for making Rockwell PLC's talk with any generic (and old) servo equipment. I happen to have 2 of these (for a total of 4 axis) that I can hook up.




The module works by sending an analog torque command to the servo. Traditionally, the servo drive would close the torque, velocity, and position control loops, however with this module, you dumb down the drive by only letting it control the torque loop. The 1756-M02AE module is then responsible for the velocity and position control. The motor encoder is still connected to the servo drive, but only for commutation data. The encoder data is buffered by the servo drive and then passed to the 1756-M02AE module through a cable.

The benefit of this is pretty much guaranteed success (watch this comment bite me in the you know what). The design is simple and rugged. The downside is a total loss of data from the drive and susceptibility to noise on the analog command line. The Sercos drives were able to transmit diagnostic data over the optical fiber, and I will lose all of that data.

Here was my controls rig before I started this new attempt.




And gutted:




And with a 4 slot PLC rack and 4 drives. I don't have matching drives unfortunately, but for this project I can disable the SERCOS option module on the first two drives to use them as a stand alone unit, and I do not need to use any of the DeviceNet features on the 3rd drive. Ideally, I'd like to find 4 matching 500W basic drives like the one on the far right.




Here is the removable terminal block (RTB) for the analog servo module. It has quite a lot of wires going to it. One large bundle goes to each drive, and a smaller cable goes to the terminal blocks to read the homing sensor on each robot axis.




And all zipped up.




And installed on the servo module.




I ran out of time, but my next step is to test the Z axis under analog control. This will require setting up the program for these modules, and configuring the drive for analog torque reference. This is a couple hours of work there. If it works, then I can hook up the other 3 drives.

I also ordered the version B of my encoder interface circuit. This one will have all my changes integrated to the board. That should be in within a week. I'm really hoping that this works without edits needed.

I really wish that the Sercos drives worked out, but this should do the trick and provide good motor control.


----------



## macardoso

Here is the new circuit board I just ordered


----------



## macardoso

New circuits are in and I got a test unit assembled. I'm getting much quicker at the PCB assembly process, this one only took me about 2 hours to stencil the paste on, place the components, reflow, and clean. I'm pretty confident that this will work now, especially since the reworked board hasn't had a glitch since I put it together.

This board added the 3 chips in the second column from the left.




Next step is to make sure the motors work well with this board. From there I can test the Z axis motor under control of the analog interface card. If that works, then I can go through motor by motor and get them hooked up.

Hoping work slows up a bit so I can make some more progress on this.

-Mike


----------



## macardoso

Planned to spend an hour or two last night testing the new feedback board and analog control of the drives. First thing I needed to do was move the control board with all the drives back under the robot and connect the cables. I powered it on and everything started up fine. I noticed I forgot to hook up the brake leads from the Z axis motor to the 24V PSU.

I didn't want to go find my laptop and pull up the manuals, so with everything powered up, I plugged the wires into the PSU and the brake opened up. I wanted to make sure I got the polarity correct so I removed the wires and swapped them (expecting it to also open the brake or not do anything) and then plugged them into the power supply again.

It was at this moment I knew I screwed up... There was an orange flash from the base of the robot and the stench of burnt electronics. I tried reversing the wires back to the right way, but the brake wasn't working anymore.

Turns out I fried a trace off of the main breakout board in the base of the robot (EPSON SKP337). The robot assumes it is connected to a matching controller, so there is no reverse polarity protection built in. I assumed this board just passed the signals from the SCSI-68 connector which is where the signal cable plugs in, but there is a bit more going on there.







You can see the burnt trace near the top of this photo. It goes under all 5 of the black plastic connectors, so those will need to be removed and the trace cleaned up. There is a risk of the trace lifting off of the board and shorting pins on the bottom of the connector.



I spent two hours tracing out the PCB in the region where the trace failed and here is the schematic I was able to put together. What I did was connect 24V+ to terminal block 66 and DC COM to 67. This forward biased the diode VD1 which failed to a dead short as 10A @ 24V flowed from the power supply. The trace between SCSI pin 64 and VD1 is probably 10mil while the trace between VD1 and SCSI pin 66 is probably 50 mils. There was no fuse present so the trace between SCSI pin 64 and VD1 was the first thing to blow.




I *believe* that terminal 67 (SCSI 65, 66) is the +24V supply rail to the robot. That power is shared between the brake coils (only 1 present on this unit) and the optical/inductive homing sensors. I believe VD1 and VD2 are flyback diodes used to clamp the reverse voltage spike generated by the brake coil in the motors as they turn off and the magnetic field collapses.

I also think this board is probably shared between many different flavors of this robot. I have not pinned it out entirely, but it looks like there are places on the board for an 8 pin IC, a large switch of some kind, and a battery holder to maintain absolute encoder positioning during power cycles.

My plan is to remove all of the black plastic connectors with the hot air rework station I was using to solder the feedback boards. I'll clean it up with flux and solder wick and finally peel the damaged trace off of the board. From there, I can run a new wire to replace the trace and tape it to the surface of the board. The diode should be able to be replaced by any generic diode with a reverse standoff voltage greater than 24V and a response suitable for clamping coil surge.

I don't want to, but I should probably take the time to draw the rest of the circuit out so I have it for reference in the future. They did some goofy stuff here and I do need to understand it better.


----------



## brino

Does the track show continuity from end-to-end? (it looks like you've drawn enough of the circuit to know)

If so, I'd be tempted to just leave it.
You're right it looks darkened in that one area, but if it is not delaminating from the board you might create more problems by removing all those connectors. Is it noticeably burnt between connectors too? (say X50 and X40)

I doubt it could lift enough under the connectors to cause shorting.

-brino


----------



## macardoso

brino said:


> Does the track show continuity from end-to-end? (it looks like you've drawn enough of the circuit to know)
> 
> If so, I'd be tempted to just leave it.
> You're right it looks darkened in that one area, but if it is not delaminating from the board you might create more problems by removing all those connectors. Is it noticeably burnt between connectors too? (say X50 and X40)
> 
> I doubt it could lift enough under the connectors to cause shorting.
> 
> -brino



It is open circuit right now.

It is darkened for the full length of the trace and it goes under each connector. I think it burned open under the X20 and X30 connectors. 

I hadn't planned on removing the trace or removing the other connectors, but it found it lifting off of the board under X10 when I removed it. This worried me that it could lift under X20 - X50 as well and cause a short, so I figured I'd remove all the connectors. The heat must've destroyed the solder mask and the glue which binds the copper to the fiberglass.

I had good luck when removing the X10. I first added a bit of leaded solder to each lead to reduce the melting point and add a bit of flux. I then used the hot air rework station to heat the entire connector until it fell out. Finally I used solder wick dipped in liquid flux to clear out the plated through holes and prepare the board for soldering again. I don't like the idea of removing all the connectors, but I feel confident I can do a good job.


----------



## brino

macardoso said:


> I don't like the idea of removing all the connectors, but I feel confident I can do a good job.



You've shown your skill and perseverance before!
-brino


----------



## macardoso

brino said:


> You've shown your skill and perseverance before!
> -brino



Thanks!

Connectors are removed. Pretty glad I did check. The trace was completely delaminated from the board and would have easliy made a short with a bit of vibration. I removed it entirely. I also found a single via hidden under the X30 connector on this trace. I would have missed this had I just cut the trace at each end.

I left this picture kind of big. The loose trace is hard to see. One piece is near the text "X50" and the other is near the text "26" on the X30 connector. Just past that blackened trace is the via I would have missed.

I have no clue what that 3 terminal orange device is in the upper right corner. +24V enters on pin 1 and exits on pin 3 to be distributed to all +24V power pins. The pin 2 is connected to a pin on the MDR/SCSI connector labeled "RG" which might be robot ground?. Maybe this is some sort of 3 terminal fuse. The component is labeled "NF1".



It was a bit of a pain to clean out the plated through holes for the connectors, but with a full spool of solder wick, I got it done. Everything is ready to be soldered back on once my repair is done.

The brown scum is rosin residue which cleaned up nicely with some 91% isopropal alcohol. Really hard to find any right now!




Spent the rest of last night drawing a full schematic for the board. I'm about 70% done. Most of the pins on the MDR connector just map straight to a pin on the rectangular connectors. A few of them, mostly power, homing, and brake control have some strange circuits. I'd like to have a diagram available in the future. It is also correcting my bad terminal labeling from earlier.




Have to work the weekend, but hopefully I'll have some time after my shifts to get this finished and get the motors spinning again.


----------



## macardoso

Circuit board is repaired!

I finished up the schematics for the board as well. Not sure if they are 100%, but darn close and plenty good enough for me. I forgot to take pictures, but I'll upload them tonight. The schematic drawing is embarrassingly sloppy, but that is because I drew it in the order of tracing the wires and not in any manner that conveyed function. I may still redraw it with a logical layout.

I used some 30AWG magnet wire to repair the board. This is rated to carry 2A while the original trace was probably good for 500mA. The diode (VD1) was replaced with a glass 1N914 diode I had on hand. I have no idea what the original ones were, but this is probably heavier duty than the original. The reverse breakdown voltage is rated for 75V and it will only be seeing 24V. 

I needed to get the magnet wire from the top of the board to the bottom and I found the easiest way to do this was to feed it through the plated through hole that the diode is installed in (the wire also needed to be electrically connected to that leg of the diode, so it worked well). I also soldered all the connectors back in place.

The heat of the solder automatically strips the enamel off of the wire so soldering was easy. I had nice thin 1/8" kapton tape in the house somewhere, but I couldn't find it. I'll clean up the trace routing when I do.







The board was reinstalled and the polarity corrected on the brake leads. I nervously powered it on and the brake clicked open immediately! I'll install a small 500mA fuse on that terminal to prevent this from happening again!

I'll have to study the schematic I drew, but the brake circuit is a bit goofy. I think it always has 24V on it and the robot controller would have switched the connection between the brake return and DC common. There is also a button on the top of the robot that allows you to manually release the brake to lower the tool at the end of the robot arm.

I think this board is generic and can be reused for robots with additional motor brakes and/or absolute encoders. There are footprints to install additional components on the board that I think might have been switches accessible from the back window to define the absolute position on the encoder (if you purchased that option). I don't think that most of the traces are used for my particular robot. It was pretty strange to me that the 4 connectors which go to the motors were all different in the way they connected. I have to study the schematic to figure out exactly how they are different, but I would have thought that they would all be the same.

Here is the board installed in the back of the robot.




I think I am ready to power this up and start running the Z axis motor on the Ultra 3000 as a standalone drive again. If this works, my next step is to swap the reworked Version 1 feedback adapter board for the Version 2 one. If this works then I will reconfigure the Ultra 3000 to accept an analog torque command and try running it from the PLC using motion commands.

If I can get past all of that, the next step is to solder 3 additional feedback adapter boards and startup the other motors. If that works then I can wire up the remaining 3 channels for the analog servo cards. Last step would be to run the entire system with robot kinematics enabled.

If I can get there (god willing), then I need to dream up a robot interface and program some sort of runtime program. I'd like this to be able to run a basic text language with a table of positions and instructions to use a tool. I can create this and copy from some robot control language. I'd also like to add a G-code interpreter to allow offline programming of more complex movements! This could be a couple months of work, but it sounds fun! 

Once everything is working nicely, I'll probably repackage all of the electronics inside a big enclosure like I did for my CNC.


----------



## macardoso

Had a very successful weekend with the robot. Only had about two hours to work on it but got a ton done. Here is what I did.

I am running out of drives that I have to play so I ended up using a mix of normal drives, drives with SERCOS fiber-optic option module, and drives with DeviceNET communications option module. The module is factory installed and shouldn't be removed. For the robot, the T1 and T2 axes are running drives with the SERCOS option module, the T3 axis drive has the DeviceNET option module, and the T4 axis drive is a plain standalone drive.

With the SERCOS module, you can disable it in software and use the drive standalone. I tried to do this with the DeviceNET drive, however that option doesn't exist and the drive was constantly faulted with DeviceNET Link Down since the drive wasn't on a network. I tried a bunch of different things but couldn't get the drive to let me run it. Eventually I got a tip that the option module can be ripped out of the drive and the drive "forgets" that it even had a module to begin with. I did this and everything was OK to run after that.

Here are the guts of that servo drive. The DeviceNET option module would have sat on top of those standoffs. The drive is a sandwich of 2-3 boards. The bottom board with the capacitors is the power module and contains the Isolated Gate Bipolar Transistors (IGBTs) which create the variable frequency motor output. Above that is the control module (visible in the picture) which is the brains of the drive. It evaluates motor command and feedback and generates the control signals to fire the IGBTs. It also handles serial communications and the I/O. This structure is the same for drives up to 2000W. Beyond that the frame size of the drive increases.




I setup the PLC rack with a new program to run the drives using the analog card and tried it out. I quickly found out that I didn't have the card wired correctly, and after a bit of searching, I found this very helpful graphic in the manual.




The big thing I was missing was the external 24V power supply. With that installed, I was able to hookup the enable and drive fault signals correctly. I ran the motor tests and tuned the system and it worked! Seriously this just went smooth as could be. The motor can be enabled and run using the PLC motion commands just as I needed. The motor response is very stiff and responsive. I ran a few manually entered commands and everything worked as expected.

The next step was to remove the old feedback adapter board and replace it with the new one I got in the mail the other day and soldered up. I decided to not bother with scoping all the signals and just try plugging it in to see if it worked. I got really lucky and it worked on the first try! Pretty cool that I designed that circuit from scratch and it is now working as planned. I have to solder 3 more for the other drives, so I'll try to get some better pictures of the process for a follow up post.







I identified the T3 motor has a 36T timing pully which drives a 72T pulley on the ballscrew for a 2:1 drive ratio. Motor is running in the image below




I finished off the afternoon by writing a simple motion control program which raised and lowered the Z axis at around 50% speed ad infinitum. It is nice and quiet when running which is pretty cool. I get position error faults when running the motor above 2700 rpm or so. I did not tune with the load installed, so I should be able to get better performance with some diligence in setup.

View attachment IMG_9622.MOV

















This is probably the biggest breakthrough I've had this entire project. Unless something is truly broken, the remaining motors should be a perfect copy of this axis as far as wiring and software configuration. I will be driving to get these done in the next week or so. The rest of the axes are very difficult to mechanically decouple from their gearboxes/loads. I'm going to try to start them up with the load connected and pray I don't crash anything! I finally see the light at the end of the tunnel.

-Mike


----------



## stupoty

macardoso said:


> OK robot is in the house and down the basement.



missed opportunity not setting it up in the kitchen and doing food and washing up automation.


----------



## macardoso

Since we are getting close to some robot action, I think now would be a good time to discuss the mechanics and kinematics which the software will need to handle.

First thing to discuss is the T3/T4 motor assembly. The two motors are belted to the two nuts on the ballscrew/ballspline. The T3 motor drives the upper nut which is a traditional ballscrew nut. There is a 2:1 gear reduction in the belt system. The T4 motor drives the lower nut which is a ballspline (free to slide axially, fixed rotationally). It has a 1:1 belt drive ratio as well as a planetary gearbox with a currently unknown ratio.




The screw is able to translate and rotate with the differential motion between the two nuts. They follow the equations:
Z = (T3 - T4)*Screw Lead
U = T4
Where Z is the change of position in the vertical cardinal axis, U is rotation about the Z axis, T3 is the rotation of the ballscrew nut, T4 is rotation of the ballspline nut. Screw lead refers to the linear distance traveled per rotation of the ballscrew nut

Since the PLC is controlling the motors and not the end effector directly, we need to rearrange these equations to solve for the motion of T3 and T4. This gives the following solutions:
T3 = (Z/Screw Lead) + U
T4 = U




In the controller, the real motors are Servo Axes and the cardinal axes (X, Y, Z, U) are considered Virtual Axes. Virtual axes can be commanded just like real motors, but are only used for calculations. In the case of the robot, the Virtual Axes Z & U compute the motor axes T3 and T4. Virtual Axes X & Y are used to compute T1 & T2 through the built in kinematics functions. I may also add a Z_Rot virtual axis to handle the screw pitch calculation.

Currently the built in robot kinematics for the SCARA variety do not handle the Z/U interaction, so I will need to handle it in the code manually. To do this, I will need to electronically gear (does exactly as the name implies) Z_Rot to Z with the ratio equivalent to the screw lead. Then T3 will be electronically geared to both Z_Rot and U. T4 will be electronically geared to only U.

The gearing can be set in the startup routine. Once it has been enabled, it is continuously calculated in the background by the PLC motion planner. What this means is I can command motion on Z and U (in inches and degrees respectively) and the PLC will figure out how to move T3 & T4 to make that happen.

The motion planner also has coordinate systems. These allow you to add kinematics to your motors. Kinematics in robotics refers to the calculations required to convert desired motion in an X, Y, and Z Cartesian coordinate system (the one we are familiar with) to motion on the joint motors. These equations become highly non-linear and motion in a straight line in Cartesian space can create some very complicated motion at the motors.

*Forward Kinematics* are the simpler equation to solve and the SCARA robot is one of the easiest geometries to do it on. With a basic familiarity in trigonometry you should be able to see how knowing the joint angles (theta 1 and theta 2 in this example) allow you to calculate the end effector position (X2, Y2 in this example). The calculations ignore the Z and U axes.




*Inverse Kinematics* are the devilishly complicated brother to the forward kinematics. With the inverse kinematics your goals is to determine the joint angles needed to give a defined end effector position. This is done using typically using Devanit-Hartenberg parameters and the homogenous transformation. This is usually a graduate level subject. Unfortunately I never got the chance to cover it in school, but I did buy a textbook and spent a year and a half studying the subject. It is still about as clear as mud to me  . Shown below is a picture of the solution to the inverse kinematics for this robot.




Notice there are two solutions. While going through the math, you end up taking a square root and introduce a plus-or-minus into the equation. This means there are now two equally valid solutions. In real life, this holds true as the robot can approach the desired position from two different angles and get perfectly valid results.

To make it worse, there are many positions within the workspace where one or neither solution is valid. This occurs when the motion required to reach that position is beyond the physical limitations of the mechanics of the robot (for example a position further away than the arm is long, or one near the right edge of the workspace where one of the solutions requires the arm to rotate further than it can go, but the second solution would be valid). The kinematics alone won't always help you find the right solution since they return answers without boundaries or limitations taken into account. The robot control software needs to be able to make decisions on the fly as to which solution is the appropriate one to use (think of cost minimization functions and such). With the PLC kinematics, you must select if you wish to use a right arm or left arm solution when enabling the kinematics. This can be switched at runtime but it creates a discontinuity in the motion control as the arm flips to face the other direction. You can see this happening repeatedly in the second video in post #4 of this thread.

In 6 axis robot arms it gets even worse. With all the extra joints, additional plus-or-minuses get introduced into the solution and you end up with 8 potentially valid solutions for any given position and orientation. UGH!

And after all of that, you have only figured out what the motor positions are to get the robot to a particular position. Let's say you want the end effector to move in a straight line in Cartesian space, you now have to consider path planning. This is done with the derivative of the homogenous transformation called the Jacobian. I never got to learning this by hand. But it allows you to create the non-linear function which the motor must execute to generate linear motion at the end of the arm through some god-awful math that looks like this:




Thankfully, the PLC handles this part for you behind the scenes. All you have to do is command motion in X and Y like a CNC machine, and it will do all the math to make the motors move where they need to.

This is a super deep subject that makes me really excited, but I think I'll stop here before I bore anyone. If you want to hear more, or have questions, let me know and I'll make a follow-up post.

-Mike


----------



## macardoso

Finished the other 3 circuit boards last night which should allow me to interface with the remaining servo motor's feedback. As promised, I took some extra pictures to share my process for assembling surface mount PCBs.

For the second set of PCB's I ordered, I opted not to have the manufacturer trim down the stencil. Instead I got the full size sheet (same price) with two pieces of hard paperboard with a slick coating. I think these are the backing sheets used on their CNC drill machines and they cut them up to use as packing material for their finished products. I used one of the boards and some kapton tape to build a hinge. There are two spare PCBs underneath to build a fence to locate the PCB to be loaded with paste. This lets me quickly load and unload many boards for application of solder paste without having to worry about alignment.




The solder paste is kept chilled in the fridge. A credit card is used to squeegee the paste into the cutouts. Extra paste is put back in the jar.




And here are the boards with solder paste applied. This did not turn out as neat as my first board, but it doesn't need to be a perfect paste job to get good results while soldering. Any wiggle or vertical movement of the stencil against the board will smudge the paste.




For placing my parts, here is my setup. I used the other piece of scrap board as a work bench. I have the schematics up on my computer to help identify the parts to be placed. I am using antistatic tweezers to place the components, and all the parts to be placed are in the blue bag. I go through one component at a time and place all the parts that I need.




Here's (44) of the 0.1uF ceramic decoupling capacitors




And a couple of the SOIC chips.




Halfway done.




An hour later I have all 3 boards populated and a 4th board with solder paste on it to use as a test article to dial in the reflow temp. I am using a cheap $30 reflow gun borrowed from a buddy. You can dial in both the air temperature and the air flow rate. I reflowed at 350*C and 4/10 on the air flow. I spend about 3-4 minutes heating the board with about 4-5" of clearance. Once the flux in the paste is melted, I know I am close to the melt temperature. From there I place the heat very close to the board and quickly reflow the parts.

I found it important to heat the capacitors quickly otherwise the pads would melt at different times and the tiny capacitors would tombstone (see link here). Once the tiny components are well flowed, then I can take my time with getting the bigger components to reflow. I work in a wave across the board, allowing components ahead of the heat gun to preheat a bit more before I get to the for final reflow.

I take one last pass at all the IC's at a 45 degree angle to the board to clean up any stubborn solder beads that didn't fully melt if they were hidden under the chip. Then I let the boards cool for 10 minutes.




All soldered up. At this point, I use a copious amount of 91% isopropyl alcohol and an old tooth brush. The flux dissolves in the alcohol and can be rinsed away after several washings. This also cleans up any miniature solder beads left from the solder paste. The better your transfer of paste at the stencil phase, the less cleanup is needed.




All Done.




I soldered on the connectors after this by hand, but didn't take pictures. The next step is to wire up the T4 motor and try to get it running. If I can do that I'll get the Z/U kinematics programmed and then move onto T1 and T2.


----------



## brino

Great work as usual Mike!

You certainly master both the theory and the practical of your projects.

After all the tense work of placing parts and waving around the hot air blower, wouldn't it be nice to have a robot arm to do that next time? 

-brino


----------



## macardoso

brino said:


> Great work as usual Mike!
> 
> You certainly master both the theory and the practical of your projects.
> 
> After all the tense work of placing parts and waving around the hot air blower, wouldn't it be nice to have a robot arm to do that next time?
> 
> -brino



Thanks Brino!

I actually thought that would be a fun first or second application once I get this running. Maybe make some cheap circuit boards with 555 timers to make a few LEDs blink. I imagine that the parts would need to be moderately big to have any success in placing them. Circuit boards are so cheap, so it would be fun to try!

I also thought about trying to program it to assemble little lego cars over and over.

Now that I got one motor working, I am really excited to start the programming.

-Mike


----------



## pontiac428

An hour of placing SMDs with forceps?  I'd pass out from lack of oxygen well before that.


----------



## Boswell

I use one of those little vacuum pencils thingys. designed to pickup and position SMDs. There cheep and work very well. Still tedious and exacting work


----------



## macardoso

pontiac428 said:


> An hour of placing SMDs with forceps?  I'd pass out from lack of oxygen well before that.



It was an oddly zen experience. Been doing work on a laptop 10 hours a day so it was welcome to do something with my hands. I had just mowed the lawn 10 minutes before I started, so I was expecting my hands to be shaking like crazy with these little parts, but I had great success.



Boswell said:


> I use one of those little vacuum pencils thingys. designed to pickup and position SMDs. There cheep and work very well. Still tedious and exacting work



Ooohhh! That sounds awesome. Might need to get me one. Where'd you get it?


----------



## brino

Boswell said:


> I use one of those little vacuum pencils thingys. designed to pickup and position SMDs. There cheep and work very well. Still tedious and exacting work





macardoso said:


> Ooohhh! That sounds awesome. Might need to get me one. Where'd you get it?



@Boswell , I too would appreciate if you could provide a link.
Thanks,
-brino


----------



## macardoso

Wife and I are both working 10-12 hours a day, 6 days a week right now. I'm exhausted - BUT this robot has given me a kick in the pants to get it working! I've felt quite stuck for a while, and now I am making quick progress. Fun feeling. I want to spend all my free time on it.

I got a few hours on the robot yesterday and was able to get the T4/U axis motor running. I'm hoping all the remaining motors require roughly the same effort, because this wasn't too bad.

First step was to wire up the feedback adapter board to the terminal blocks on the robot. There are two cables in the bundle, one is 9 conductors and contains the encoder signals and power output to the encoder. The second is a larger two conductor cable which connects this board to the 5V PSU.




The adapter board is then wired to the feedback breakout board which plugs into the drive. I wish this was a one piece assembly, but it works for now.




I ohmed out all the connections all the way back to the motor at the end of the robot and confirmed the connections were correct. I really screwed up the numbering on the terminal blocks relative to the robot manual, so I need to carefully double check every connection by hand.

I powered on the drive and tried the encoder, but absolutely nothing worked. I even got the scope out and was ready to start tracing signals. I was super bummed my feedback adapter board wasn't working. I didn't have the mental energy last night to try to trouble shoot the circuit.

That's when I realized I had left the motor encoder unplugged from the cables inside the robot from when I was checking the pin connections. After I fixed that, the board powered up and worked great!




Whoops.




I was able to setup the drive very quickly and do some indexing tests. That's full speed for the rotary axis. The motor is quite a bit louder due to the planetary gearbox attached to it. I figured out the gear ratio is 21:1 and the belt drive ratio is 1:1 (72T:72T).

Compared to the belted connection of the Z axis, the servo response of the U axis motor through the gearbox is incredibly stiff. I tried twisting the screw with all my strength and could barely get the motor to 100% torque and it can go to 300% rated if needed until the motor overheats. This would be great at installing screws!

View attachment IMG_9651.MOV


















































The next step is to get the drive wired up to the second channel of the analog servo interface module and get the PLC controlling the motion. From there I can either move on with getting the T2 and T1 motors running, or I can work on the homing sensors and kinematics of the Z and U axes.

I think I am also getting to the point where I need to install a true safety system. This thing is fast and I need a good Oh-S**t button.


----------



## Boswell

brino said:


> @Boswell , I too would appreciate if you could provide a link.



here is a link on Amazon for the one that I have VACUUM PICKUP PEN


----------



## macardoso

Got a couple more hours in on this project this weekend. Not much but still plugging away. Work should settle down after this week which I am very much looking forward to.

First thing I did was disassemble the terminal block area of the board I've been building this on. I needed some extra room for additional components and to wire things right. I added a second DIN rail below the first and added some power distribution terminals and fusing for the 24V and 5V power supplies. I added a slim relay to control the motor brake and wired it to a relay output on the Z axis drive. The relay on the drive would probably have no issue driving the brake directly, but I threw the interposing relay in there anyways. This took a lot more time than expected.

I also opted to add two safety relays which will be connected to an EStop button. The relays each have two mechanical relays inside which will be wired to interrupt the drive enable signal should the Estop buttons be pressed. This isn't the best way to do drive safety, but these older drives do not have a Safe Torque Off (STO) safety rated input. Hitting the EStop will immediately turn off the output from the 4 drives and the motors will coast to a stop. I have not wired this circuit yet.

Finally I wired up the analog interface servo module to the U/T4 axis drive. This allows me to control that motor from the PLC. I did some basic functionality tests and tuned the axis. I was able to quickly set up the electronic gearing between the T3 and T4 motors to allow me to independently control motion on the Z and U axes. When Z wants to move up and down, only the T3 motor spins. When U wants to rotate, the electronic gearing drives both the T3 and T4 motors at the same time (T3 moves twice as fast as T4 to accommodate for the gear ratios). With both motors running, the screw rotates in place without any vertical motion. If you want to rotate U and move Z at the same time, both motors must rotate, but T3 will either move faster or slower than twice the motion of T4. It is pretty neat to watch the synchronization between the motors. I think this whole robot will be mesmerizing to watch once it is fully working.

Here is a crappy video of the two axes running in synchronization. It doesn't look like much but notice how the large pulley underneath the arm (connected to the T4 motor) and the belt at the top (connected to the T3 motor) move at the same time. I do not need to command this interaction for each move, only one time to establish the gearing ratio and direction, then the PLC handles it in the background.

View attachment IMG_9663.MOV

















I forgot to take pictures of the wiring - I'll add them to this post a bit later.

My next step is to connect the homing sensors of the Z and U axes to the servo interface module. This should allow me to develop a homing sequence and command positioning moves in absolute coordinates. I also want to make sure I get the wiring right before I start wiring the second servo module.


----------



## macardoso

Can anyone offer some suggestions on how to film better video for this project? I only have a cell phone camera and poor lighting. It is in a small basement with the rest of my shop so it looks cluttered.

Also HM limits me to 18 seconds of video when I upload from my phone. Anything longer will cause errors. I think this is because HM doesn't downscale picture and video resolution. How do I get around this if I am not editing my videos?


----------



## Lo-Fi

macardoso said:


> This is a super deep subject that makes me really excited, but I think I'll stop here before I bore anyone. If you want to hear more, or have questions, let me know and I'll make a follow-up post.



Enjoying the thread. This is something that really interests me, having fumbled about with a Canadarm model while modding Kerbal Space Program. I knew what I needed to do, but never put the time in to figure out the computation to move the end effector in Cartesian space while having the various joints do all the heavy lifting with an algorithm driving it. 

For what it's worth, you might find the Unity game engine to be a good tool for figuring this all out virtually if that's helpful.


----------



## macardoso

Lo-Fi said:


> Enjoying the thread. This is something that really interests me, having fumbled about with a Canadarm model while modding Kerbal Space Program. I knew what I needed to do, but never put the time in to figure out the computation to move the end effector in Cartesian space while having the various joints do all the heavy lifting with an algorithm driving it.
> 
> For what it's worth, you might find the Unity game engine to be a good tool for figuring this all out virtually if that's helpful.



That's awesome. I played KSP for a while but never saw a mod for the Canadarm. That would have been pretty cool. The math is wild if you are calculating it yourself. Especially for 6 axis arms with wrists.


----------



## Lo-Fi

I messed with a whole load of stuff that never got released, sadly. Too much to do, too little time. I started the Kerbal Foundries mod, which included wheels, caterpillar tracks and all sorts of whacky stuff, as well as collaborating on lots of other mods. One of the guys I frequently worked with was a robotics specialist - was a really interesting guy. We discussed the Canadarm and messed with a few rigs - he even made a lovely model - but decided it was probably a step too far to create the solver just for a game! Lol.

Either way, really interested to watch your progress on this.


----------



## macardoso

Been thinking some more about the control software I am going to write for this robot and wanted to share my thoughts.

I think I am going to build the graphic interface pretty similar to Mach 4. I'll probably aim for a bit more graphics area and dump most of the CNC centric graphics like spindle controls and tool changes.




Here are the things my software/graphics must have:

Welcome screen with navigation to startup tasks, diagnostics, and runtime screens
Ability to load G-code/robot code into the PLC using a flashdrive (I know this is going to be much harder than it should be)
Ability to interpret G-code/robot code (write a custom interpreter)
Automatic homing
Robot kinematics (obviously)
Jogging
Display of cartesian position and joint angles
Lookup table of taught locations for use in robot code
Fault handling
Ability to read PLC inputs and control outputs from the execution of the G-Code
Realtime adjustment of speed, acceleration, etc.
And things that would be really cool to add:

Animation of the robot arm showing the workspace bubble and the robot links as viewed from above. Bubble should update when the tool geometry is updated.
Singularity avoidance (stop motion before hitting the edge of the workpiece bubble, including during jogging)
Collision avoidance (stop motion before hitting objects defined in the workspace). Add these items from the HMI and have them appear in the graphics window.
Code test mode - verify code function before moving robot in real life. Verify no collisions or other abnormal conditions


----------



## macardoso

Lo-Fi said:


> I messed with a whole load of stuff that never got released, sadly. Too much to do, too little time. I started the Kerbal Foundries mod, which included wheels, caterpillar tracks and all sorts of whacky stuff, as well as collaborating on lots of other mods. One of the guys I frequently worked with was a robotics specialist - was a really interesting guy. We discussed the Canadarm and messed with a few rigs - he even made a lovely model - but decided it was probably a step too far to create the solver just for a game! Lol.
> 
> Either way, really interested to watch your progress on this.



That's so cool - I've seen that mod! That game is a blast and I think it must've been pretty neat to get involved with the modding community. That's completely foreign to me!


----------



## macardoso

Spent some time working on the robot last night again. The homing sensors are proving to be a bit trickier than anticipated. Let's discuss.

The first issue is that wiring information is spread out across lots of different documents and some of the information (like the circuitry on the robot PCB itself) is completely undocumented. This isn't unexpected since this interface would have been between the robot and the matching controller. I've attached my horribly drawn circuit diagrams from the PCB inside the robot. I'm almost too embarrassed to share this, but it is helpful info. Again, I drew this as I was reverse engineering the board and it conveys the order in which I went through each trace on the board, and does not necessarily convey electrical function. Below are the other relevant excerpts from the robot manuals.

This is the overview of the cable harnesses. They are nicely labeled inside the robot and can be unplugged at each connection point shown in the diagram.




This is the pin assignment detail for the T3/Z axis motor and sensors. There are similar diagrams for the other motors. The connector "X30" is a rectangular connector on the PCB inside the robot. The manuals do not indicate how the PCB interfaces the "X30" connector to the "X1" connector which is the one that the IO cable plugs into from outside the robot. That is why I needed to draw the PCB circuit by hand.




Here is a cleaned up sketch of just the Z axis homing sensor circuit. This is what I need to interface to. NF1 is a power filtering component, R3 is a current limiting resistor for the sensor power supply, and HL3 is a green LED which illuminates when the home sensor is triggered. Notice the direction of HL3. Not only is an NPN sinking sensor installed, but the circuit board forces the direction of current to flow *into* the sensor.




The homing sensor is a Sunx/Panasonic GXL-8F miniature inductive proximity sensor 12-24VDC NPN-NO, Sn: 1.8mm. From the data sheet, we can see that the sensor is an NPN transistor type and wants to sink the load current.

Normally you would hook these up to sourcing inputs which would have the inputs pulled up to 24V by an internal resistor. This way, when the NPN type sensor turns on, the input pin is shorted to 0V. When the sensor turns off, the pullup resistor brings the input voltage back to 24V




My issue is that the 1756-M02AE servo interface module has sinking inputs for the home sensor and expects a PNP *sourcing* type sensor to be connected.  UGH!




From that same manual, the specifications for the input voltage is that it must be higher than 17.0V to be registered as HIGH and less than 8.5V to be registered as LOW.




Here is my solution to the issue. I think I can add an external pull-up resistor at the analog interface module terminals. It needs to fight the pulldown resistor enough to get the voltage well above 17.0V and it needs to draw less than 100mA when shorted to ground or the sensor could burn up. It also needs to dissipate low enough power to not damage the resistor

I first tested this idea with a 4700 ohm 1/8W resistor, but only got the voltage up to 15.6V. Making the assumption that the 1756-M02AE servo interface module only has a simple pulldown resistor, then you can do a voltage divider calculation to figure out that the equivalent resistance of the internal resistor to the module is roughly 8750 ohms. EDIT: I noticed that the manual shows an input impedance of 7500 ohms. Close enough 

I looked in our lab at work and found some resistors in a little tub of scrap electronics that as probably been untouched for 30 years. They are Vishay Dale CPF-2 Precision Metal Film Resistors. They are 2000 ohm +/- 1% and rated for 2W. Let's check the calculations. First the voltage divider calculation indicates I can expect a 19.5V ON voltage (EDIT:18.9V assuming 7500 ohm input impedance) which is sufficiently well above the 17.0V limit. Next, when the proximity sensor turns on, it will draw 12mA of current, which is less than the 100mA limit on the sensor. Finally, that 12mA at 24V will dissipate 0.29W which is less than the 2.0W rating of the resistor. The proximity sensor guarantees a residual voltage of 0.4V at 16mA and we are even lower than that. We should be way below the 8.5V lower limit for OFF voltage.




I think this should work! I plan to wire this up tonight to verify. Here is the same sketch from above, but now the terminals for the 1756-M02AE are added and the 2000 ohm pullup resistor are shown. Terminal 6 (ENABLE-0+) on the 1756-M02AE is shown only because it to directly connected to the 24V power supply and is a convenient place to put this resistor, however the enable input plays no role in this circuit.




And this is just for the Z axis! The other 3 axes use a different kind of optical gate sensor for homing. I'll need to go through this same exercise for one of them to figure out how to make this work, but I expect it will be very similar.

NOTE: the red marks in the attachment refer to what I damaged a few posts ago. These have since been repaired.


----------



## macardoso

Project update time!

*Z Axis Homing *is completed and functional. My addition of the external 2000 ohm 2W resistor worked well and gave me a respectable voltage of 19V when ON and 2V when OFF. Not ideal, but sufficiently above and below the noise margins on that input. I configured the servo module to use a Normally Closed homing sensor. I then added homing to the simple program I wrote before so the Z axis fully retracts before starting movement. I also rewrote the code to use absolute positions instead of incremental distances. Here is a short video of that in operation. (I am having trouble with the video sizing. Something with the HM interface. If you view fullscreen, the resolution and size should be better)

View attachment IMG_9669.MOV


























The axis drives towards the switch at a medium speed. When the sensor is triggered (red LED comes on), the motor stops and reverses off of the switch at 1/8 of the initial speed. When the home sensor turns off, that position is recorded as home and the program begin a cyclic up and down movement.

Amusingly, you can see my cat chilling on my workbench in the background.

*T1, T2, T4 Homing *is my next major hurdle. I ended up starting a post on All About Circuits to try to get some help on this. Unlike the Z axis, which uses an inductive proximity sensor, the remaining 3 joints use an Omron EE-SV3 "Photomicrosensor (Transmissive)" with a fiberglass "code wheel" to trigger it. I'm pretty sure I have the EE-SV3-B model. Here is the link the the datasheet: https://omronfs.omron.com/en_US/ecb/products/pdf/en-ee_sv3.pdf




Here is a schematic of the sensor on U axis.




This sensor is configured to work similarly to the proximity sensor in that it pulls the input down to 0V, however it differs in that when it is ON (nothing sitting between the gate), it only sinks 6mA (while the proximity sensor could sink up to 100mA). This means it is unable to pull the input below the 8.5V requirement when the input is pulled up by the 2000 ohm external resistor.

I did the math and it turns out there is no value for the external resistor which satisfies both the input high >17V and input low <8.5V requirement. I'll save the gory details, but what I ended up needing to do is change out a resistor on the robot's internal PCB from 1200 ohm to 800 ohm. This allows more current to pass through the photogate emitter and also allow it to sink more current on the phototransistor. By adding the 2000 ohm external resistor and swapping in an 800 ohm resistor, I *should* be able to get 6V when the input is low and 19V when it is high. This should be acceptable.

I purchased some 800 ohm 3W resistors from Digikey at $2 each. I didn't want to modify the robot at all, but this is a small change to allow me to use the analog servo interface module that I have. These should arrive tonight.

Here is a simplified version of the schematic. I will be installing R1 externally with a value of 2000 ohms. I will be removing R4 from the robot PCB and replacing it with an 800 ohm.




*DIN Rail Components*

Here's a picture of where the DIN rail wiring stands.

*

*

Starting at the top left, I have a couple of terminal blocks for connecting PE grounds. Then there is a 20A main breaker (shares power to the other two breakers), a 6A breaker for the PLC and DC power, and another 20A breaker just for the drives. There 6A breaker feeds the 24V 3.5A supply and the 5V 2A supply. Each supply passes through a fuse and gets distributed across the terminal blocks on the top.

The bottom row has some spare terminal blocks for the safety wiring, a dual channel input safety relay and an expansion module. Then there are a few terminal blocks and a slim SPDT relay for the Z axis break. Finally there are 68 terminals connected to the robot SIGNAL cable.

I don't love how messy this is, but hopefully I can clean it up if I put this in an enclosure at some point.

I started the *T1 & T2 Drive Wiring. *I hooked up cable to the remaining two feedback adapter boards. I will go back and clean up the Z axis wiring as well - it is messy since it was the first one I worked on.

*

*

Looks pretty clean actually!

*

*

All 4 installed!

*



Terminal Block Pinout*

I finally completed the mapping between my terminal block numbering and the SIGNAL number in the manual for the robot. They zig-zagged around the connector while I counted straight across. I think I followed industry standard - and I'm sticking to that story.

*

*

This will be very helpful to have. Not entirely sure what the signals HCOM, EMB1, and THS do yet.

Hoping to get the homing switches, T1 & T2 motor wiring, and the analog interface to T1 & T2 done soon. I see the light at the end of the tunnel for work, so I hopefully I will have a bit more time soon.

-Mike


----------



## brino

@macardoso 

Mike, I am really enjoying this thread.
Thanks for all the photos and details you provide.

-brino


----------



## macardoso

Another weekend of big progress forward! This is getting to be really fun.

I realized I take very few shots of the entire robot. It is pretty large and I often try not to show off my cluttered little basement shop, but it is good to get a sense of scale and layout. There are plastic covers which go over the top of the second arm link and hide the motors and cables.




I started out by finishing up the wiring to the T1 and T2 axis drives. All 4 of the new encoder interface PCBs started up without a glitch. So happy with there - probably the most successful part of the project.




I tested out each of the motors running only from the servo drives (talking to my laptop with a serial cable). I was able to run hookup tests and autotune the servos without issue. Here are two videos of the first movements of the arm links.

This is the T2 joint motor. It is coupled to a 72:1 harmonic drive gearbox. The arm is flopping around because the T1 axis is powered off and free to move. This was roughly 75% max speed.

View attachment IMG_9702.MOV

















And the very first movements of the T1 axis. The acceleration needed to be limited to roughly 2% of maximum or the table it is sitting on would really start to shake. This robot has some impressive power. The T1 joint motor is located inside the cast aluminum base and is oriented shaft-up connected to a 100:1 harmonic drive gearbox.

View attachment IMG_9703_Trim.mp4

















I then powered up the PLC and commanded motion on the Z and U axes while letting the drives continue to control the T1 and T2 joint motors. This created 4 axis motion similar to how the robot will look once I get a 4 axes running under coordinated PLC control.

View attachment JWNA2645.MOV

















I let this run for several hours while I began wiring the remaining two channels of the 1756-M02AE analog servo interface module. I went out and bought 200' of my favorite multiconductor data cable. They are 24AWG and come in 9, 15, and 25 conductor varieties with a foil shield and drain wire. The whole cable is very thin and is great to work with compared to the thick 16AWG wire I used on the other card. It is L-Com CS15-100.




Here is the mostly completed wiring harness before packing up tightly inside the wiring door.




I finished the wiring by adding the two drive connectors and cabling for power and home sensor connections. This took almost 3 hours in total to get this harness assembled.




I hooked up the harness to the drives and added the motors to the PLC program. 20 minutes of configuration and tuning and now all 4 axes are fully integrated into the PLC!




With this done, I am tremendously close to getting it working. The next biggest hurdle is homing. The robot kinematics require a very accurate knowledge of the arm's orientation when the kinematics are started up. Since these motors have incremental encoders, the only way to accurately know the arm's position is to have reliable homing. The home sensors must be very repeatable and trigger at the exact same location every time homing is activated. I also must know the exact angle of the arm when the home sensor is triggered. this is going to be tricky and will be discussed in my next post.


----------



## macardoso

So the homing sensors are the next problem child in this project. As a quick recap, the 1756-M02AE servo interface module is responsible for reading the homing sensors and has an internal 7500 ohm resistor pulling the input down to 0V. It expects 24V to be externally applied to drive the input high.

The robot has sensors (called transmissive photo interrupters on Digikey) which are wired to pull an external input down to 0V. This is likely because the original robot controller used the opposite type of input as the module I am trying to use. I thought I could get clever and add external resistors and swap resistors on the robot PCB to get this to work (as shown in the picture below), but this isn't working very well.




After adding all the external resistors and swapping out 3 out of 4 resistors on the PCB, here is what I found.

Z axis homing works great still. I will not mess with this. It gives 19.3V high and 1.9V low.

U axis home sensor is functional, however there is some kind of short on the PCB pulling the input down to 2.0V regardless of if the sensor is plugged in or not. I am pretty sure this is somewhere between the diagnostic LED and the sensor shown in this sketch. I will have to investigate further.




The T2 home sensor circuit is semi functional (gives 19.3V high and 10.0V low when tested with a good sensor), however the sensor itself is covered in heavy dark oil and is completely non-functional. It is hard to see in the image below, but that is the sensor, viewed from the bottom of the T2 joint. Replacing this sensor is going to be a real pain and will require me to disassemble the T2 joint. The two cylinders inside the arm (just barely visible, translucent amber color) are the hard stops on the T2 axis and are rubber to absorb impact.




The T1 sensor and circuit are fully functional (19.3V high and 8V low), but the code wheel used to trigger the sensor has multiple slits in it. This means the sensor could indicate home in one of many positions. I bet this is designed this way since the user can install bolts which act to limit rotational travel of the J1 axis. If there was only one slit and the travel was limited, it is possible that you wouldn't be able to home the robot. I'd prefer to change this up so there is only 1 slit and then I do not need to manually position the robot before executing the homing sequence. This will require disassembling the T1 joint as well. I expect to find a similar multi-slit code wheel in the T2 joint when I open it up, but right now, I cannot tell.

I think the right thing to do here is replace the sensors with ones that are appropriate for my type of input. Option 1 is to rewire the existing sensor to source current instead of sinking. I'd still have to replace the T2 sensor but I could use the identical part.  Option 2 will be to replace the sensors. The ones I have are "transmissive photo interrupters - phototransistor output" (general term according to Digikey). They also have these sensors with logic outputs which are a digital signal that is amplified. This is closer to what I want if I could find one that had the same physical dimensions (or close enough) to the ones I currently have. I am actively looking for a replacement, but it is hard! There are a billion shapes and sizes of these. Panasonic and Omron seem to have the largest selection. I placed a support request into Omron to see if they could help me with sensor selection.

I really want to find a sensor that bolts into the existing mounting holes otherwise I have to machine new brackets. New sensors are $10-$40 each.

The other challenge is I need to get a replacement connector for the other end of the sensor. I spent 2 hours looking for this connector last night and finally identified it as a Molex series 5102 SPOX connector P/N: 5102-3. This has been discontinued for some time and the only replacements available are from Alibaba. The recommended replacement is P/N 51191-0300, but I am not sure if it will mate to the receptacle for the original connector. They are pretty cheap, so I might just buy the parts and try it out. I also do not know if the crimpers that I own will work on these connectors.




If I do manage to get these sensors working, the final challenge will be accurately measuring the angular position of the home sensor relative to the absolute angles of the arm. This is critical to getting the kinematic transforms to be accurate. Here is my plan. I need to measure the centerline of the base of the robot and project it out across the table. I can then place a dial indicator on the table and run it against the circular casting of the T2 joint. I will sweep the arm back and forth until I find the high spot in the indicator travel. I will then measure how many encoder counts occur between this spot and the home sensor location. I can convert this to degrees.

Once I have determined the T1 home sensor angle, I can lock the T1 axis at 0 degrees and repeat the process further away for the T2 axis, measuring against the collar on the end effector (ballscrew). I should be able to get very accurate measurements with this technique.

Once I have these numbers, I can finish filling out the kinematic transform settings and start using this as a true robot!


----------



## Papa Charlie

Very cool project, way over my head. But I love to read about it and see the logic you use in analyzing and diagnosing the issues and solutions.

Very impressive.


----------



## Lo-Fi

Can you not just buffer those limit switches with an appropriately chosen and arranged transistor circuit? Should be way simpler than replacing the ones that are hard to get to?


----------



## macardoso

Lo-Fi said:


> Can you not just buffer those limit switches with an appropriately chosen and arranged transistor circuit? Should be way simpler than replacing the ones that are hard to get to?



I definitely could, but it would require me to add a new circuit board somewhere. I don't have a good spot to add one, nor do I want a hand soldered breadboard hanging somewhere (not that the wiring is all that pretty right now, but at some point, I'd like to put this into an enclosure.

I have to pull the T2 sensor out anyways, and I'm considering machining a new code wheel for the T1 joint sensor, so I'll likely be pulling it all apart anyways. Bit of a bummer, but it will be cool to see further inside the joints. Doesn't look too hard to do, other than dealing with the weight.

The gearboxes are supposed to get repacked every 8000 hours of operation with Harmonic Drive brand SK-1A harmonic drive grease. Bet that is overdue... Wonder how much a tube would cost if they'd even sell it to me.


----------



## macardoso

As a fun side note, there is a brake release button on top of the robot which has been non-functional this entire time. Once I got the wiring figured out, I found out the brake button was working again. That was on my list of things to address later, so it was a nice surprise


----------



## macardoso

So I am out of luck on using the original homing sensors, rewired for sourcing. They worked exactly as expected, except for one thing... The current limiting resistor (800 ohms) in front of the emitter drops almost all of the voltage from the power supply. All that is left after it is the forward voltage of the photo interrupter emitter, a measly 1.20V.

Even the robot manual is wrong (not the first time), calling this pin on the sensor cable +24V.




Without modifying the circuit to place the resistor after the circuit, the best I can do is source 1.2V and pull down to 0V. So my "rewire the original sensor" plan is now dead. Time to replace it - or replace the main PCB (I don't want to go there yet - expensive).

The best options I have seen are Omron EE-SX67, EE-SX77, EE-SX87, EE-SX95, or Panasonic PM25/45/65

I need the sensor to have PNP outputs and accept 24VDC. I would prefer an integral cable. Prices seem to be in the $10-40 range.

None of these sensors have the same form factor, so I will need to machine an adapter. hopefully I can come up with a solution that fits in the same mounting holes without needing to machine anything on the robot.

Edit: one final option is to create a tiny interface board that hooks up to the homing sensors inside the robot and amplifies their output.

Edit: My front runner is the Panasonic PM-F25-P. It is tiny, but I will definitely need to machine an adapter plate. It is 1/3 of the cost of the Omron sensors so I'd like to be able to make it work.


----------



## Lo-Fi

You could probably get away with surface mount components for adaptor boards. It's only signal level, after all. https://www.seeedstudio.io/ or similar are pretty darn cost effective too.


----------



## macardoso

Here is a model of the new sensor (left) alongside the existing sensor (right). I will need to make a tiny adapter to adjust the height and position to get the beam located at the correct spot while using the original mounting holes




Here's a top down view of the sensors. Notice how the new sensor (right) sits further back from the original mounting holes in order to get the beam window in the exact same location.




Here is the sensor mounted with the adapter.




And the actual adapter. This part is TINY. The mounting holes are for M2 screws. I'll need 3 of these. My old concern is if using both of the mounting screws could impact the code wheel. If so, mounting it with only one of the original screws would be acceptable. I'll probably make them from Aluminum.




And a very quick and dirty drawing.


----------



## Papa Charlie

Looks like it would work except for the one mounting hole in the adapter that is partially impaired by the new sensor mounting hole. I would change from the impaired adapter hole to a pin that would protrude into the PCB to maintain alignment. That would also allow for more surface area for the head of the fastener to mount the sensor to the adapter.


----------



## hman

Thanks for the info on the Panasonic!  Can't count the number of Omron EE-SX670 series (670, 671, 672, etc.) photosensors I used on machines at HP.  They have a nice, narrow beam, and come in a variety of mounting options.  Always on a purchase order, so "funny money," and more-or-less unaware of how costs tend to mount up.  Good to know there's a more ffordable alternative.


----------



## macardoso

Papa Charlie said:


> Looks like it would work except for the one mounting hole in the adapter that is partially impaired by the new sensor mounting hole. I would change from the impaired adapter hole to a pin that would protrude into the PCB to maintain alignment. That would also allow for more surface area for the head of the fastener to mount the sensor to the adapter.



Yeah, I'm space constrained and unsure how that will pan out. One option is to use only the original mounting holes and not use the hole thru the new sensor. The sensor would be retained by the overlap of the screw head. Another option is to use only the new mounting hole on the left, and the original on the right. I could improve this my turning a tiny grub screw to fit the original hole and have a turned locating diameter to keep the sensor straight.

I think I can make it work with how it is drawn though.

The adapter bolts directly to the robot body into two tapped holes.


----------



## macardoso

hman said:


> Thanks for the info on the Panasonic!  Can't count the number of Omron EE-SX670 series (670, 671, 672, etc.) photosensors I used on machines at HP.  They have a nice, narrow beam, and come in a variety of mounting options.  Always on a purchase order, so "funny money," and more-or-less unaware of how costs tend to mount up.  Good to know there's a more ffordable alternative.



That's pretty neat, do you still work there? Honestly, with how expensive industrial sensors are, these are super cheap by comparison. I really hope these end up working out for me.


----------



## hman

I accepted a "golden handshake" in 2005.  There had been several rounds of both voluntary and involuntary RIFs.  And though I really enjoyed working there, it appeared that things were slowing down ... and the offer I accepted included HP's continuing their part of health insurance coverage until I got on to Medicare.  I still miss a lot of the wonderful folks I worked with.

PS - we had a goodly number of the blue Seiko SCARAs in the calculator assembly area.  I didn't work with them directly, but did design and build a part feeder for one of the calculator lines.  A Seiko picked the part up from the feeder and placed it onto a PC board.  Here's a scan of an old photo I have of one of my part feeders, with the Seiko in the background.


----------



## macardoso

hman said:


> I accepted a "golden handshake" in 2005.  There had been several rounds of both voluntary and involuntary RIFs.  And though I really enjoyed working there, it appeared that things were slowing down ... and the offer I accepted included HP's continuing their part of health insurance coverage until I got on to Medicare.  I still miss a lot of the wonderful folks I worked with.
> 
> PS - we had a goodly number of the blue Seiko SCARAs in the calculator assembly area.  I didn't work with them directly, but did design and build a part feeder for one of the calculator lines.  A Seiko picked the part up from the feeder and placed it onto a PC board.  Here's a scan of an old photo I have of one of my part feeders, with the Seiko in the background.
> 
> View attachment 338881



Man, that is so cool


----------



## macardoso

hman said:


> I accepted a "golden handshake" in 2005.  There had been several rounds of both voluntary and involuntary RIFs.  And though I really enjoyed working there, it appeared that things were slowing down ... and the offer I accepted included HP's continuing their part of health insurance coverage until I got on to Medicare.  I still miss a lot of the wonderful folks I worked with.
> 
> PS - we had a goodly number of the blue Seiko SCARAs in the calculator assembly area.  I didn't work with them directly, but did design and build a part feeder for one of the calculator lines.  A Seiko picked the part up from the feeder and placed it onto a PC board.  Here's a scan of an old photo I have of one of my part feeders, with the Seiko in the background.
> 
> View attachment 338881



PS: Just saw the name this morning and chuckled. Feels very fitting.


----------



## hman

We'd occasionally give names to machines at HP.  It was anticipated that there would be more than 3 or 4 of this type of part feeder.  There's lots of two-person partnerships, some three-person, but I had to rack my brain to come up with a larger series.  Settled on the Little Rascals.  Unfortunately, the project was cancelled after just Spanky and Alfalfa


----------



## macardoso

Weekend update! Done with crazy work hours finally - so nice to have a full 3 day weekend with only normal house chores.

Got a few good hours on the robot. Here is where I got to:

The new optical proximity switches arrived. They are quite tiny and really feel pretty nice.




I had a cheap DuPont style pin crimper. It isn't the right tool for these pins, but it worked well enough. The "right" tool for the job would have cost be $450 - kinda crazy.




I got the connectors correct and they snapped together perfectly with the original connector.




I replaced the 800 ohm resistors (R1, R2, R4) with 1A inline fuses. This gives 24V down the wire without sacrificing the overcurrent protection. I also removed the external 2000 ohm pullup resistors at the servo interface module. After that I plugged in the sensor and got a perfect 23.7V high and 0.7V low. Super happy about this and totally worth trying to get the new sensors working. R3 remained as a resistor since that is how the original board was wired and it is already working so no need to fix what isn't broke.




Next up, I programmed up the CNC to make those 3 sensor brackets. I used 5 tools and it took me about 2 hours to program.




I used a 2x4" piece of aluminum and faced it flat as a fixture. I then lapped another aluminum block against my surface plate to get it flat and superglued them together. The spindle was used to apply down pressure for an hour until it cured. I was concerned about the stability of this method, but it was rock solid.




Faced and drilled.




Tabs roughed and finished.




Body was finished at this point. 10 thou of material remains above the superglue for stability.




And cut through the remaining foil down to the super glue. The 1/8" endmill is pretty dull and left a bad burr. The parts were easy to clean up and the foil remnant is thrown away. About 3 minutes over my gas stove got the glue hot enough to break the parts loose.




Here are the parts, cleaned and deburred.




And the sensors installed. These turned out great!


----------



## macardoso

OK, I lied earlier, there was a bit of machining on this project


----------



## macardoso

After I got those machined, I was able to install the U axis sensor and T2 sensor without needing to disassemble the arm. Getting the T2 sensor installed was tricky, but I was able to fish the cable through the arm without disassembly.

The T1 sensor is buried deep in the arm and needs disassembly to install. My dad is spending the weekend with me, so I might drag him into him helping me take it apart.

I do have one major hiccup right now. I tested all the sensors before installation and everything worked perfectly. After I got everything buttoned back up though, the U axis sensor was stuck at 3.3V and would switch between 3.3V and 0V when I hit the robot or banged on the table. Like there was a loose connection.

I was able to narrow it down to the X10 connector being plugged in (it was not while I was doing initial testing. The X10 connector services the T1 motor encoder and the T1 homing sensor. There should be absolutely no interaction between this and The U axis sensor on the X40 connector.

I tracked this back even further and found out the sensor work correctly when the T1 motor encoder is unplugged and gets hosed up when the encoder is connected... Not good, there DEFINITELY should not be any interaction between these two devices

I checked the T1 encoder and found the B positive encoder phase is reading 0V steady. All other phases were showing encoder counts. I really hope that the encoder and motor didn't get damaged when I plugged this sensor in.

I did not scope this motor's phases before I connected it to the feedback adapter board. I need to power the motor up again and make sure it is still working. If it is no longer working, then I damaged the encoder when the sensor was attached. Really hoping not.

Not sure why there is any interaction between these devices - need to trace that further. Could be a short on the PCB... I saw weird behavior on this sensor even before replacing it, so I have a feeling this has been an existing problem.

In other news, Rockwell released Studio 5000 V33 PLC programming software this past week. The big news is that it now has native support for my robot's kinematics (including the Z/U screw interaction). I will be migrating to this version and starting to develop the runtime program.

Next steps forward are:

Fix the U axis homing sensor & T1 encoder
Measure homing angles
Develop the robot PLC program
Develop an HMI interface to the PLC program
Design and machine a pneumatic gripper


----------



## macardoso

To keep my thoughts straight, here are the tests I'm going to do to figure out what happened with the T1 Motor / U Home Sensor:

Unplug U Home sensor. Does the T1 B phase work?
Unplug U Home sensor. Does the motor pass the hookup tests and run OK?
If the B phase does not work, does it work on the other motors?
With power off, is there any continuity between the T1 motor encoder and the U home sensor?
Remove PCB and see if I can trace any problems out.
If I fried the motor, I can try to replace the encoder output driver chip, or get a new motor for $130... Bummer


----------



## macardoso

So, it turns out I did fry the motor. I started testing as stated in the previous post and couldn't get the B phase to work anymore. I tried running the motor hookup tests built into the servo drive and they all failed and the drive would fault on E11 (Illegal Hall State). Remember that I had this motor working perfectly a week ago. Scoping my feedback adapter board showed absolute garbage coming out of the hall effect commutation outputs. This is because it cannot correctly decode the signal if the B phase is dead.

I wanted to see if I could figure anything out, so I removed the T1 motor from the underside of the large cast aluminum base. The maintenance manual is very clear about how to do this, but this dummy removed pretty much all the screws but the correct ones. I finally got it out though.

This is the wave generator from a harmonic drive. These are the absolute coolest mechanical devices that I can think of and I've always wanted to hold one. If you are interested, check this wikipedia link out. The ground bearing race visible just below the large steel puck is ground extremely thin and pressed over an elliptical plug connected to the motor shaft. The bearing freely deforms to match this elliptical shape. If I squeeze it on the major axis, the motor shaft will rotate about 90 degrees which is totally wild.




Here is the rest of the harmonic drive. The thick ring with the bolts around the perimeter has spline teeth cut on the inside and mates with the flexspline (shown inside with the yellow grease). The flexspline is a thin cup made from fatigue resistant steel with external spline teeth. It has 2 fewer teeth than the circular spline and connects to the load (robot arm). When the wave generator is inserted into the flexspline (that's in the polished area free from grease), the flexspline deforms into an ellipse. As the input shaft is rotated, the wave generator creates a meshing action between the flexspline and the circular spine along the major axis of the ellipse. The spline advances two teeth forward for every revolution of the input shaft, giving extremely high reduction ratios. Since the meshing action is wedge shaped sliding rather than rolling, the gearbox can be made with near zero backlash.




These are used in robotics, planes, the International Space Station, and the wheels of the Apollo lunar rover. Cool stuff.




I tightly wrapped the wave generator in plastic wrap to keep it clean and placed masking paper on my workbench to create a clean workspace.




This is the output section of the Yaskawa encoder. The JL-041A chip on the left is their proprietary ASIC which multiplexes the encoder signal and made my life so difficult. The chip on the right is a Texas Instruments AM26C31I Quad Differential Line Driver. This chip buffers the signals coming from the JL-041A and creates an inverted pair of signals to be transmitted on twisted pair wire over substantial distances. I was really hoping at this point that any damage would be limited to this chip.




Using some 30AWG magnet wire, I attached to various pins on the chips. In particular, I got pin 15 of the JL-041A (B phase output) and Pin 9 of the AM26C31I (B phase input). I was *really *hoping that this signal would be intact. If not then the JL-041A was dead and I'd have to toss the motor. I also soldered to pins 10 and 11 of the AM26C31I which are the buffered pair of signals that should look like the B phase (except pin 11 should be inverted).




Here's the scope probes. All of them referenced the power supply common.




And here is what I got on the scope. As expected, Channel C (B phase buffered output - noninverted) is dead and sits at 0V. The good news is that Channels A & B are showing a perfect signal of B so the rest of the encoder is OK. Notice how Channel D (B phase buffered output - inverted) is the opposite of A & B. This is for noise immunity when transmitted in a twisted pair with channel C.




I got pretty excited at this point. When I designed my feedback adapter boards, I copied this exact chip as the output driver. I have spare chips to make one additional feedback board.




The big challenge is that just below this this circuit board is the precision etched glass phototransmissive disc that the encoder reads. Any contamination at all could ruin the encoder. There are also parts hanging from the bottom of this circuit board so I couldn't use the hot air gun to remove the chip. I opted to mechanically cut each leg of the IC with a pair of sharp diagonal snips. I then used my soldering iron to remove the remnant of the leg from the pads. I accounted for each of them so I didn't leave junk in the encoder. I used some nice solder wick to clean the pads and remove this goop that they used to secure the chips to the board.




Finally I placed my new chip on the board and hand soldered it in place with the thinnest solder I own. It doesn't look very pretty because I was using a soldering iron and not paste and a hot air gun, but whatever, the joints are good. I added the test leads back on.




And after powering it back up, all the signals came through perfectly! I can't believe I was able to get this fixed. I think this is back to 100% functional. Channels C & D get fed directly into my feedback adapter board. I removed all the test leads and sealed the encoder back up.




I will not reinstall the motor until I can figure out why it got fried in the first place. I am expecting to find a short between the B phase of the encoder output and the output of the U axis home sensor output. I'm guessing the old sensor was shorting but since it was a sinking sensor (and it only sank 6mA) it did not damage the encoder. I think that when I put in the new optical homing sensor on the U axis, it can now source 24V at 100mA which went directly into the AM26C31I driver output and fried the chip inside.

I'll do some continuity checks next and try to identify the source of the issue. It is probably on the robot PCB, but it could also be in the interconnect cable or at my terminal blocks.

Whew - Mike


----------



## Papa Charlie

I am no electronics person by any means. Give me voltage.

But I am enjoying following your thread and the analysis work you are doing. I love analysis and the logic behind it. Looking at these pictures of the motor, I did not understand the scale until I saw your finger holding the new chip next to the old over the motor. I don't think my fat fingers would do well with this.


----------



## macardoso

Papa Charlie said:


> I am no electronics person by any means. Give me voltage.
> 
> But I am enjoying following your thread and the analysis work you are doing. I love analysis and the logic behind it. Looking at these pictures of the motor, I did not understand the scale until I saw your finger holding the new chip next to the old over the motor. I don't think my fat fingers would do well with this.



Yeah the encoder is tiny for sure. The first time I messed with the encoder (back on page 2 of this thread), I would soldering in the dark while kneeling on top of the table with the robot. I don't know how I got that done. At least this time I was on a brightly lit workbench!

Thanks for following along and writing back! I enjoy sharing this project and it gives me a kick to keep moving forward.


----------



## macardoso

Was able to confirm. There is a dead short between X11-3 (Encoder signal 1B) and X42-1 (Sensor signal 4HOME). This is what fried the encoder. This short remains when the SIGNAL cable is unplugged from the back of the robot, ruling out a short in the cable or at the terminal blocks where I did all my wiring.

The short disappears when X10-X50 are unplugged from the robot SKP337-1 PCB ruling out any quantum tunneling/magical effects of electrons jumping between different cable harnesses. Pretty certain that the short is somewhere on the PCB. Will update when I learn more.


----------



## Papa Charlie

I told you I am no expert when it comes to electronics, but from this image I pulled from an earlier post of yours. It looks like the burn mark goes all the way from X50 to X10 crossing over several circuit paths. Could the carbon from what I am calling the burn line cause it to short across different circuits?


----------



## macardoso

Papa Charlie said:


> I told you I am no expert when it comes to electronics, but from this image I pulled from an earlier post of yours. It looks like the burn mark goes all the way from X50 to X10 crossing over several circuit paths. Could the carbon from what I am calling the burn line cause it to short across different circuits?



Well I found the issue. It was related to this blown trace but not exactly as you described. I scrubbed all that crap off the board with isopropyl alcohol when I first repaired it, however when I soldered the connectors back on, I ran into trouble with the soldermask rubbing off easily. This left a glob of solder connected to the X40-20 pin and it jumped to the trace sneaking next to it. This trace was the X10-5 signal which went to the T1 B encoder phase. The black line is sharpie I used to follow the trace all around the board.




A quick cleanup with solder wick left this connection completely repaired.




I tested the continuity between the sensor and the T1 encoder pin and no longer had connection. While testing continuity, I shorted this connection again with a screwdriver and got a beep. I am confident this was the issue. I'll triple check this and then reconnect the motor and try to get it working again. I'm hopeful the encoder repair worked. I also hope the U axis homing photosensor is OK, but I didn't see any signs of damage before so I am not too worried.


----------



## Papa Charlie

Glad that you found the issue. With the circuits being so small, it is great because you can put a lot into a very small area. But on the other side of it, it is really easy to cause impacts to local circuits.
Thanks for sharing your findings.


----------



## macardoso

Was able to test the T1 motor and it ran great. The harmonic drive made a few funny sounds while the grease settled in and now it is nice and quiet again.

Have not tested the homing sensor, but I don't expect to have any issues.

The last two mechanical tasks are to install the T1 homing sensor inside the shoulder (T1 joint) and to measure the zero angle offsets with a dial indicator. Then time to start programming.


----------



## brino

Well done Mike!
 

-brino


----------



## macardoso

Hi all, hope everyone had a great weekend. Had my dad come visit and coerced him into helping me finish the T1 home sensor installation. The maintenance manual gave a pretty good description of how to do this, and I've attached the relevant pages here.







The bolts well very tight and required a substantial cheater bar to break them loose. The arm lifts off a boss on the shoulder joint and can be laid on the table without undoing the cable harness. It weighed probably 60lbs.




The shoulder joint was pretty neat to see and was pristine in condition. It still has a thin film of rust preventative all over the steel components. You can see the multi slotted homing code wheel in this shot. I was considering replacing this with a single slot variant, however I don't think it is worth the effort. I will manually position the arm at the homing location before startup, just as the operation manual for this robot with the original control describes. 

Since the arm can be travel limited with special bolts for safety reasons, it is possible that a single homing location may be inaccessible if the travel was limited.




Here's the other side.




From the top, you can see the two sector blocks on the right side which act as hard stops for the T1 arm motion. This arm can move incredibly quickly and weighs quite a lot. An impact with these hard stops would be very violent. The blocks have roughly 1/4" firm rubber pads (amber colored) glued to their faces to act as bumpers to absorb impact energy.




Here is the original homing sensor as-installed.




And my new one. The clearances between my mounting bracket and the code wheel are tight, but everything worked perfectly.




Now that I have all the motors and homing sensors working, there is no need to keep the covers removed. I gave them a good wash and reinstalled.




Here's the lower cover. I think the gridded ribbing on the first arm link (left side of pic) is pretty cool.




With all 4 sensors installed, I was able to test the homing and it is working great. As mentioned above, the T1 and T2 axes need to be manipulated to place them close to the home location. The homing sequence can then be run from there.

You can see the dial indicator set up to measure the homing angles. I need to find the center of the aluminum robot base and draw a perpendicular line across the table. The dial indicator should be close to centered over this line. The more accurately I can measure the homing angles, the more accurately the robot will position in cartesian coordinates after the transform, especially at the edges of travel.

I started the actual runtime program for this robot as well as the HMI screens. The program is a state machine with the transitions between states handling power on, homing, power off, hard stop, and fault reset. The 3 states I chose are Stopped (powered off), Running (able to perform motion, may or may not be moving), and Faulted (something went wrong). The transitions are Starting (power on and homing), Stopping (stop motion and power off), Faulting (hard stop motion and power off), and Resetting (clear faults).

A super quick test of the code yielded some bugs (as expected), so I'll need to spend a little time troubleshooting it.  I also want to spin up a computer to act as the HMI terminal for this robot program.


----------



## Papa Charlie

Congrats, that is an amazing piece of equipment. 

Do you have a plan for it, or is this work you are doing currently the plan? Which there is nothing wrong with the learning process that you are going through. Maybe a second purpose will arise after the learning process.


----------



## macardoso

Papa Charlie said:


> Congrats, that is an amazing piece of equipment.
> 
> Do you have a plan for it, or is this work you are doing currently the plan? Which there is nothing wrong with the learning process that you are going through. Maybe a second purpose will arise after the learning process.



Thanks! Getting close! 

Honestly no, I don't have a plan for it. I love robotics and this showed up at the right time (quarantine) and was cheap. I plan on writing a nice operating program and interface for it, and then making some simple programs. Here were a few ideas I had (open to more!):

Attach a dry erase marker and draw shapes on a whiteboard
Pick and place assembly of small lego cars (got some pieces from my dad when he visited for this purpose)
Pick and place assembly of something? using a gripper I want to design and machine
3D printing by attaching a hot end extruder. It would have a very large workspace. 
Lightweight machining????, maybe, probably not though.
Auto tool changer for my CNC mill. Integrate with Mach 4 using Modbus TCP. This would semi-permanently attach it to the machine, so I'd want to be sure I was done playing with it by that time. 
Fun educational demo for a local high school shop class?


----------



## Papa Charlie

I can understand the primary purpose of just learning how it works and can I fix it, followed by programing it for what ever. That would have been enough. I could see this as a tool changer but would be concerned with chips or coolant getting at the electronics. Maybe it is waterproof but didn't look like it.

I love the mechanics of the arm. Beyond what you have already done, which as I said would be a satisfying project alone, it really doesn't matter what you do with it. That is along as you are enjoying yourself.

I have designed and built machines many times over the years. Could have gone and bought one but always like the challenges and felt I could do it better. For me, it has to look like it came out of a factory and performs. Once I get past that, it is more of what is next.

But now that I think about it. That could be a great way to feed cases into my annealer that I built or some other reloading process. Maybe take the measured powder from my Sartorius lab scale that I use for my competition loads and drop it into the case for me. Not necessary but would be cool.


----------



## macardoso

Papa Charlie said:


> I can understand the primary purpose of just learning how it works and can I fix it, followed by programing it for what ever. That would have been enough. I could see this as a tool changer but would be concerned with chips or coolant getting at the electronics. Maybe it is waterproof but didn't look like it.
> 
> I love the mechanics of the arm. Beyond what you have already done, which as I said would be a satisfying project alone, it really doesn't matter what you do with it. That is along as you are enjoying yourself.
> 
> I have designed and built machines many times over the years. Could have gone and bought one but always like the challenges and felt I could do it better. For me, it has to look like it came out of a factory and performs. Once I get past that, it is more of what is next.
> 
> But now that I think about it. That could be a great way to feed cases into my annealer that I built or some other reloading process. Maybe take the measured powder from my Sartorius lab scale that I use for my competition loads and drop it into the case for me. Not necessary but would be cool.



As far as chips and coolant, I can have the arm move to a parking location behind a closing door. The robot itself is not waterproof in any way.

I'll post projects as I think of them for the robot. I'd love to also get a 6 axis robot arm at some point like a Fanuc 200iC/D. We will see, they are very expensive - even in the used market.


----------



## macardoso

Drew up a quick PowerPoint sketch of how I want the HMI to look:




From the top,

*Menu Bar*
A Windows-like menu bar allows for basic program control, navigation to pop-up screens, and system settings. I'd like everything to be able to be configured from here rather than needing the PLC software. The X in the top right corner closes the application.

*Coordinate View*
Shows robot cartesian coordinates as well as the joint/motor angles.

*Toolpath Display*
A live data display will show toolpath lines as they are executed as well as the current tool position. The HMI software is going to be lacking some features in this area that I'd like, but I'll do the best I can

*Code Window*
A scrolling code window will highlight the current line of code. The current line of code is displayed and may be changed when the program is not running. A completion bar will show program completion in percentage of total lines of code. The program will be able to execute G-code (limited feature set at first) and robot code (I haven't decided on which language to use - or to create my own).

*Command Buttons*
Large buttons on the left control the startup and operation of the robot. The robot will automatically home when enabled. Run will start the program, hold will pause motion and allow the program to be resumed, stop will end the program, and reset will reset faults if needed. Buttons will be disabled when not able to be used.

*Override Pane*
Two sliders control the speed and rapid overrides

*Control Pane*
The control pane allows the user to load and manage programs. Programs are stored in PLC string memory arrays. If the program is too long (~>70000 lines) the program will be broken into multiple different arrays. The programs should be loaded from flashdrive containing text files. VBA scripting will transfer the file contents line by line into the PLC memory. This is tricky but I've done it before. A code editing window will be made available which can edit the code in PLC memory, not on the flashdrive. Run from here can be selected to start the program midway through while executing modal changes preceding the current line. Verify program will check program execution for errors and out of range motion, without moving the motors.

*Jog Pane*
The jog pane allows the user to jog the robot, either in cartesian coordinates or joint angles. The jog can be continuous or incremental. Jog speed and jog increment are programmable and will be retained for each axis when deselected. Forward, reverse, and stop buttons (for incremental movement) are available

*Screen Pane*
The screen pane gives the user controls to change the toolpath display (which is unfortunately not click interactive). I want to add a robot overlay to the screen, mimicking the mechanical shape of the robot. I also want to consider adding reduced speed and avoidance zones to help the robot not crash with hazards inside the workspace. 

*Offsets and Positions Pane*
This pane will allow the user to edit the work and tool offsets. These selections are read only when the program is running and will update to show the current work and tool offset selected. The teach position zone will allow the user to edit saved positions and teach new ones. These positions may be referenced in the code execution by calling a P# variable. 

*Diagnostics Pane*
Finally, the diagnostics pane indicates the current mode of the robot state machine and indicates other important diagnostics.

*Bottom bar*
The bottom bar shows the current diagnostics message plus offers a button to open a message history popup. There is blank space here to add additional features


Still thinking up features! I can add tabs and sub menus on the screen as needed, but right now I don't think any are needed.


----------



## macardoso

Thought of a few items I do not have in the display above. I'll need to find a way to elegantly add them.

Multiline Manual Data Input (MDI)
Single Block Execute Select Button
Block Skip Select Button
Optional Stop Select Button
I/O control pop-up window
Motor Tuning pop-up window
Soft limits configuration pop-up window
Workspace bubble configuration pop-up window
Avoidance Zone configuration pop-up window
End of Arm Tooling (EoAT) control window
I got a good start on the HMI development yesterday. I'll post some updates. I also plan on posting a little overview of the PLC programming software and HMI development environment if anyone is interested.


----------



## macardoso

OK, PLC Software.

I'm using Rockwell Automation's Studio 5000 PLC development software (Version 33).




PLC's differ from your standard microcontroller in a number of important ways. First off, they are designed for large amounts of I/O which someone else has done the leg work of developing the interface for you. There are dozens of flavors of I/O modules and all of them are designed to plug into the PLC rack and have a data assembly automatically created for you as soon as you add them to the program. Next, PLC's are designed for networking and connectivity. All of the network processing is handled in the background and typically does not affect the execution of you runtime program. PLC code is interpreted (meaning no compiling) so you are able to "go online" with the PLC and watch it execute your code. Online edits to the code while the PLC is running are perfectly fine in most cases. Rockwell PLCs have 4 languages (Ladder logic, structured text, function block, and sequential function chart) which can be used interchangeably. Ladder logic is the easiest to read, especially at runtime.




PLCs are also excellent for real time program control and time dependent control (think of timers and scheduled code execution). This is perfect for machines since they have real world characteristics which require time delay in your code.

Here is the controller organizer for the PLC. From top to bottom... The Controller tags contains all globally scoped tags (PLC name for variables) in tabular format. Your actual code is organized into tasks. Tasks can occur on a schedule (periodic tasks), driven by an event (event tasks), or run continuously with whatever remaining processor power is left (continuous task). Each PLC can handle up to 32 tasks, although you typically only have a few. Inside each task are programs, you can have 1000 of these per task. Finally inside each program are routines (no limit on this). Programs may have their own locally scoped tags which can only be used by that program. Here I am using 3 periodic tasks (2ms, 10ms, and 50ms).

The motion group contains all the motion axes and coordinate systems for this PLC. I have 8 axes (T1, T2, T3, T4, X, Y, Z, and U) and 2 coordinate systems (cartesian and robot). The motion group can update every 2ms.

Finally at the bottom is the I/O tree where all the connected devices are stored. I have the PLC, an Ethernet interface module, and (2) 1756-M02AE analog motion modules.




Here is an example of some simple ladder code. Ladder logic was created to be easily read by electricians familiar with relay logic. In the rung below, the logic statement is: IF (*A* and NOT *B* OR *C*) THEN *X* = 1. There is also the parallel statement: IF ((*A* and NOT *B* OR *C*) AND *D*) THEN *Y* = 1.




Here is an example with a timer which  would be a touch tricky to do in an Arduino without stopping the processor. The statement is: IF *A* THEN start *TIMER*. IF *A *AND *TIMER DONE* THEN X = 1. The timer is preset to 1000ms and the accumulator will count up on screen until 1000 is reached. DN is a status bit indicating the timer is done




Here is an example of the real code running the robot. When the program counter tag (Wrk_ProgramStep) is equal to step 10, then execute the MAM (Motion Axis Move) instruction. This commands the axis T3 (Z axis motion) to move incrementally the distance contained in the tag (Wrk_BasicMotion_Pos1) which is currently -3 inches. The move should use the speed and accelerations contained in the tags shown below (current values are displayed with the tag), and the motion should follow a trapezoidal profile. The rest of the arguments in the instruction are advanced features not used at this time. The tag T3_BasicMotion_MAM1 is a unique tag containing the information pertinent to this motion instruction.

After the instruction is executed, the PLC sits on this rung of code until the status bit T3_BasicMotion_MAM1.PC (Process Complete) is set, then the program jumps to step 20. Motion programming is one of the most intensive tasks for a PLC. The PC bit is set when the PLC is done commanding motion and the command for the axis to reach its final destination has been sent.




I can't cover every detail of the program, but this is a quick and dirty introduction. Feel free to ask any questions.


----------



## macardoso

I'm having an interesting thought session on the PLC program memory.

My PLC can store up to 40MB of tag (variable) memory, which includes all the data needed to make the program work in addition to saved robot/Gcode programs. Programs will be stored in arrays of strings where each array must not exceed 1.5MB - I'm calling this a Block. If a program is longer than one Block, then it can use a second, and my code will pickup on the second block where the first left off.

Here's the tricky part. The default String datatype in the PLC holds 82 characters and the largest array <1.5MB is 17873 indices. This is essentially the number of lines in the program. If any line (e.g. "M03 S1000") is shorter than 82 characters, then the extra characters are used to hold a null character and are useless.

I can opt to define a String datatype shorter than 82 characters (let's use 41) and now the largest array is 35746 indices. I trade number of characters per line for more lines of program code. The problem comes however, if I ever have a line that is longer than 41 characters, then the data is truncated when it is loaded into the PLC. I could probably flag this error during the data transfer, but I can't fix it.

My CAM software often creates very long programs (hundreds of thousands of lines) with tons of small moves. I want to be able to use these. The trick will be trying to come up with the optimal number of characters per line so I don't truncate data in 99.9% of cases, but I don't waste any more data than is needed.

BTW, if I assume a 41 character length of string, then I can store a total of 714,920 lines of code distributed between 20 (or more) Blocks. This reserves 25% of the controller memory for use by the program. Once these Blocks are full, I will have to delete programs from controller memory before loading new ones. I'll also need to create some sort of file system manager that tracks which blocks belong to which program, and what memory is available for use/free to load data into.


----------



## matthewsx

I have an idea for your first program....






John


----------



## macardoso

macardoso said:


> I'm having an interesting thought session on the PLC program memory.
> 
> My PLC can store up to 40MB of tag (variable) memory, which includes all the data needed to make the program work in addition to saved robot/Gcode programs. Programs will be stored in arrays of strings where each array must not exceed 1.5MB - I'm calling this a Block. If a program is longer than one Block, then it can use a second, and my code will pickup on the second block where the first left off.
> 
> Here's the tricky part. The default String datatype in the PLC holds 82 characters and the largest array <1.5MB is 17873 indices. This is essentially the number of lines in the program. If any line (e.g. "M03 S1000") is shorter than 82 characters, then the extra characters are used to hold a null character and are useless.
> 
> I can opt to define a String datatype shorter than 82 characters (let's use 41) and now the largest array is 35746 indices. I trade number of characters per line for more lines of program code. The problem comes however, if I ever have a line that is longer than 41 characters, then the data is truncated when it is loaded into the PLC. I could probably flag this error during the data transfer, but I can't fix it.
> 
> My CAM software often creates very long programs (hundreds of thousands of lines) with tons of small moves. I want to be able to use these. The trick will be trying to come up with the optimal number of characters per line so I don't truncate data in 99.9% of cases, but I don't waste any more data than is needed.
> 
> BTW, if I assume a 41 character length of string, then I can store a total of 714,920 lines of code distributed between 20 (or more) Blocks. This reserves 25% of the controller memory for use by the program. Once these Blocks are full, I will have to delete programs from controller memory before loading new ones. I'll also need to create some sort of file system manager that tracks which blocks belong to which program, and what memory is available for use/free to load data into.



OK, to start out, I made a memory block datatype with a length of 55 characters. This is because it is longer than the longest gcode string I could quickly think of (I'm not planning on adding canned cycles or anything crazy here...) which was "N12345 X12.3456 Y12.3456 Z12.3456 U12.3456 F123.45". Also my current HMI screen can only display 55 characters...

Each data Block is 25000 lines long and equals exactly 1.5MB of controller memory. I made 10 blocks to start out, consuming 15/40MB available on the PLC.




This can easily be changed in the future if it is a problem.

The way I'm planning on making this work is this. There will be a file manager object in the PLC code. Its job is to track which programs are loaded and what memory blocks (in which order) are used to save that program. It needs to help the Gcode interpreter know which line of which block it should read from when the robot is running. It also marks which programs are empty and will interface with the HMI VBA code to load programs from flash drive into PLC memory.

All this data is contained in a "Program Ledger" which has the program name, a bit to identify if it is empty, a bit to identify what language the code is in, and an array of integers to identify which memory blocks the program is stored in and which order they should be loaded in.

I'm not quite sure if I am going to have the Gcode interpreter read directly from the memory block, or if the memory block should be copied to a working tag before being read.

Honestly, I'm making this a lot more complicated than it needs to be. I could simplify this by only allowing a single 25000 line program in the PLC and reading directly from that. I think the file system would be kind of neat though!


----------



## Grey

After reading through this thread I thought I was at work back in the mid 90's.  Glad all I had to do was design the mechanics and electrical interfaces.
Some "hobbies" people have around this site.
Add a linear track to that and you could have it serve drinks to people of all sizes down a bar.


----------



## Boswell

is it hard to change the max number of char per line?
Could you just inspect each program for the max line then set the PLC to that for each program you want to run?
Alternatively, It is likely that line length will be a bell curve so there would be a small number of lines that were the largest outliers. Identify them then manually figure out a way to break them into multiple smaller lines.


----------



## macardoso

Boswell said:


> is it hard to change the max number of char per line?
> Could you just inspect each program for the max line then set the PLC to that for each program you want to run?
> Alternatively, It is likely that line length will be a bell curve so there would be a small number of lines that were the largest outliers. Identify them then manually figure out a way to break them into multiple smaller lines.



The number of characters per line is fixed once the program has been downloaded to the PLC. It is the dimension of the memory addressing and I don't know of a way to change it.

Since this is for my own use, I'm OK with the 55 line limit I think. Comments in the code would probably be the most likely candidate to push a line over the 55 character limit. 

It is easy enough to change this later if I find I didn't include enough characters per line.


----------



## macardoso

Did a bit of work on the robot hardware again yesterday and measured the "zero angle orientations". This is the angular distance between the home position (random based on home sensor installation) and the cartesian world definition (the XY axes of the table the robot is mounted to). In layman's terms, this is the difference in angle of each joint from home position to "arm-straight-out" 

This was admittedly a super frustrating experience. I need to measure this as accurately as possible to allow the kinematics to give accurate final positioning of the robot, however even leaning on the table top could generate a 30 thou movement in the dial. I drew out a straight line down the table centered on the robot base and called this the workspace Y axis. I centered the indicator tip over this line to the very best of my abilities (using the yellow plastic level as a vertical fence) and swept the T1 axis back and forth. The position of highest indicator travel indicated when the axis was lined up with the Y axis. 




In tried measuring on the casting, but found it too uneven to get good measurements. The machined steel bearing between the joints was better. I took 10 measurements (looking at the PLC's reported axis position measured from the motor encoder) and did an average.




Once the T1 axis position was found, I turned that axis on and locked it in the zero angle position. I repeated the process with the T2 axis, measuring against the collar on the end of the ballscrew.




The zero angle orientations I measured (relative to the home position, CW motion positive) are the following:
*T1 = -7.4910° 
T2 = -18.8768° *

Honestly I don't trust these numbers past 1 decimal point but whatever, it will be a good start. If I ever bump one of the homing sensors, I will need to remeasure these values. Here is the dialog box in the PLC which handles all the robot geometry.




I *think* I should be able to get the kinematics working now. Wife and I are doing a few days of vacation this week so I'll tackle it when we get back!


----------



## Papa Charlie

I would have thought that those distances from pivot point to pivot point on the robotic arm would be something that would be available from the manufacturer for individuals to use in their programing of the movements. 

What is the approximate distance from pivot point to pivot point based on your measurements? It would certainly be easier to help with a measuring concept if we knew that.


----------



## macardoso

Papa Charlie said:


> I would have thought that those distances from pivot point to pivot point on the robotic arm would be something that would be available from the manufacturer for individuals to use in their programing of the movements.
> 
> What is the approximate distance from pivot point to pivot point based on your measurements? It would certainly be easier to help with a measuring concept if we knew that.



The link lengths (L1 & L2 in the diagram) are provided by the manual for the robot and are 450mm and 350mm respectively. The angle offset from home is typically measured on a “mastering” fixture at the manufacturer. I didn’t have these numbers, but even if I did, they changed when I replaced the sensors.

This data is usually stored in NVRAM in the robot controller, which is why it is important to match the controller to the robot if buying used.


----------



## strantor

Ok I've just spent the past 4 days worth of commode time reading through this thread. I admit, there were some portions I zoned out for. I tend to do that as I have the attention span of a 6 y/o.

Not to open old wounds but I never got closure, I need to know... when you found that your commutation signals were going into that MUX chip (and you soldered magnet wire to them) why didn't you just use them? Why mess with the custom de-MUX board? I'm sure I missed something. My apologies if the question has already been answered.

And now for something more relevant, why are you trying to store an entire g-code file in your PLC? I assume you're familiar with 3D printers? I would be looking at something like that, where the PLC gets its instructions from a computer one at a time (or one snippet at a time - in 3D printers this snippet would represent a single layer or "slice" of the model). This way you (your computer) could be in total control of what the PLC receives, no comments, no illegally long instructions, etc. Your PLC could have a bit of a buffer so it isn't waiting between instructions.

Really cool project and cool thread. I'm glad i read through it an now im subscribed for future updates. Can't wait to see what direction you take this!


----------



## macardoso

strantor said:


> Ok I've just spent the past 4 days worth of commode time reading through this thread. I admit, there were some portions I zoned out for. I tend to do that as I have the attention span of a 6 y/o.
> 
> Not to open old wounds but I never got closure, I need to know... when you found that your commutation signals were going into that MUX chip (and you soldered magnet wire to them) why didn't you just use them? Why mess with the custom de-MUX board? I'm sure I missed something. My apologies if the question has already been answered.
> 
> And now for something more relevant, why are you trying to store an entire g-code file in your PLC? I assume you're familiar with 3D printers? I would be looking at something like that, where the PLC gets its instructions from a computer one at a time (or one snippet at a time - in 3D printers this snippet would represent a single layer or "slice" of the model). This way you (your computer) could be in total control of what the PLC receives, no comments, no illegally long instructions, etc. Your PLC could have a bit of a buffer so it isn't waiting between instructions.
> 
> Really cool project and cool thread. I'm glad i read through it an now im subscribed for future updates. Can't wait to see what direction you take this!




So the biggest issue is that the robot already had cable harnesses wired for the multiplexed encoder scheme. These cables plug into a custom PCB which pins them to the 68 pin signal connector which matches the robot cable I have.

If I wanted to use the non-multiplexed commutation signals, I would have needed an additional 6 conductors per encoder which just don't exist in the cable harnesses. Not to say I couldn't have scrapped the guts of the robot and started over, but designing the encoder interface board felt like the path of least resistance to me - but it was probably a wash.

Additionally, the commutation signals in the encoder were not buffered or line driven. I would seriously question whether they would transmit cleanly over the 20' of cable between them and the drive.

The simplest solution would have been to replace the encoders entirely, but once I removed the original encoder I was committed to replacement since they were factory aligned, and this concerned me. I'm really glad I went down the encoder interface board path anyways. I had a blast designing the circuit and learning about digital logic. I've never had any good reason to learn that before and now I have a new skill. I should still hit up some of the people offering to help me with the CPLD/FPGA stuff since I bet that is a lot more useful in today's world.

As far as the G-code stuff, my hope is to not need a laptop to be connected to the robot in order to run it. There will be a mini-PC which runs the HMI client, so I guess it could go there. If I run into issues with storing the program in the PLC, I can trickle feed it.

I designed a G-code interpreter at work for fun before and it ran great, unfortunately my laptop which had the program got stolen and I had no backups. I want to recreate that. Bit frustrating that I know I figured this out once, but have no notes or memory of the details of how it worked.


----------



## macardoso

I am still trucking along with this project. Mostly I've been reading the documentation for the robot kinematics instructions with orientation control. Rockwell changed the way that kinematics work since I last learned them, so I have a lot of catching up to do. I'd be willing to argue that this is one of the more complicated things that can be done in a PLC (at least that I have experience with).

The new instruction uses a Motion Axis Path Move (MAPM) instruction instead of the traditional Motion Coordinated Linear Move (MCLM) and Motion Coordinated Circular Move (MCCM) that I am used to. This seems to have some neat benefits, but the learning curve is a bit steep right now. 

I did get my program set up with functioning kinematics (the Motion Coordinated Transform with Orientation (MCTO) is running), but thus far it has not moved an inch under control of the kinematics. Getting close.


----------



## Boswell

Well as  Vilfredo Pareto said, the last 20% of a project will use 80% of the Effort or something like that.


----------



## macardoso

Took a little mental hiatus from this project while I was doing a side job, and now I've jumped right back into it. I'll do a more detailed follow up post once I get things cleaned up a bit better, so consider this a check-in.

I have a rudimentary software interface for the robot built. It can correctly handle startup, homing, controlled shutdown, and fault checking. There is also the start of the HMI interface built, basing it off of the Powerpoint mockup shown above. The kinematics are functioning mostly correctly, however I am having issues with my moves becoming non linear over long distances. This sounds like I have the wrong values for gearbox reduction ratios or joint lengths, however I have measured these geometrically and they spit out the correct values within the tolerance of my measuring (sharpie and measuring tape).

After exhausting my knowledge of things to adjust, I decided to go back to an older version of PLC software and try setting up the robot with the non-orientation controlling kinematic transform. This will give me proper control of X,Y, and Z, but I will need to manually control the U axis. If I can set this up correctly then I can try to take what I have learned and compare it to the newer version of software with the orientation controlling kinematics.

One major limitation of the *new* kinematics that I learned, is that there is an inability to control rotation while doing circular interpolation in XYZ space. I don't know if this is still in development or what, but it is annoying. An application where you might want this is a tangential drag knife where the knife should trace out curves. I could see myself building the orientation control manually in the older version of software and just using that going forward - we will see.

Knock on wood, but there has not been a mechanical or electrical hiccup in months. Those feedback interface boards I built are working perfectly! I had to return the oscilloscope I was borrowing from work, so I decided to suck it up and get my own. You can get a pretty powerful scope for not a ton of money these days. I hope that this one will cover me for any project I need it on for a very long time. There is a Mixed Signal (MSO) option module available for an extra $450 if I ever wanted which would add 16 digital channels to the existing 4 analog channels. This would have been SO helpful when I was originally designing the board









						SDS1104X-E (100 MHz) Super Phosphor Oscilloscope | Siglent
					

Buy SIGLENT’s SDS1104X-E (100 MHz) Super Phosphor Oscilloscope featuring SPO technology that provides excellent signal fidelity and performance.




					siglentna.com


----------



## macardoso

OK here is a little bit more of the update I promised. First off, here is where the screen stands:

The blue window is a graphics display of the toolpath in XY space. The control buttons are in the lower left corner. ENABLE/DISABLE starts the homing and turns on all the motors. Clicking it again stops all motion and turns off the robot. The FAULT/RESET button initiates a manual fault on the system and the RESET button will clear any fault, manual or mechanical, and return the system to a stopped state. The state machine status is indicated in the lower right. Axis positions are in the top left, and the program code will eventually be displayed below. The X in the top right exits the program.




I have exported my code and set it up in V32 of the PLC software as well as V33. V32 only has basic XYZ kinematics while V33 has XYZU kinematics with orientation control and Tool Center Point (TCP) control. 

My issue of non-linear motion appears in both forms of the program leading me to believe that somewhere I have the software configured wrong. The configuration gives the PLC a virtual description of the robot mechanics. The software then decides how the motors must move so this virtual robot creates the desired motion. If the virtual description of the robot mechanics does not match the physical robot, then motion positioning issues will occur. I think this is my issue.

There are a few things that can be wrong:
-Axis direction - I do not think this is my issue since the motion would be VERY wrong

-Gearbox ratios - I am pretty confident in these values based on data out of the manuals. The best method would be to open up the joint gearboxes and either count teeth or get a part number to reference. I expect these to be integer gearbox ratios since they are harmonic drives and the numbers I calculate from the manuals are within 4 decimal places of an integer multiple. 

-Arm lengths - These are provided in the manual and In trust them pretty well, however I'd like to do something to physically measure them. I did this once but will repeat the exercise.

-Home offsets/zero angle orientation -  these are values I measured manually a few posts ago. This is how the robot knows where it is in XY space after being homed. An error here would give the kind of issues I am seeing. In thought my method was sound, however I think I need to assume these are totally wrong and try again to measure them. When they are done, T1 = 0.0 degrees and T2 = 0.0 degrees should place the arm straight out along the length of the table.

Other than this, I do understand the programming now. I will be able to write up a program pretty quickly I think.

-Mike


----------



## macardoso

OK, my next test is to measure all these values empirically to the best of my abilities. I can easily and accurately measure encoder counts, but not much else. I will have a hard time getting even a rough measurement (directly) of the following: joint angles, arm lengths, XY positions. The robot is very large and there are no good surfaces to take direct measurements from.

My new scope arrived as an early Christmas present to myself (with some help from my dad as well). It is awesome, and I will be using it to take some direct measurements from the encoders.




First order of business is to validate the joint gearbox ratios. I will be using the scope to count the number of rising edges of the pulses on encoder channel A. I am placing the scope in segmented memory mode where it will capture many instances of the waveform and save each to memory. It can store 80,000 waveform instances or 14 million samples, whichever is less. I don't need to see the waveforms, but rather I care about the count of triggers as I sweep the arm across a roughly known distance. I will multiply the triggers by 4 (quadrature counting) and the number should match the data in the manual to a reasonable degree of accuracy. Encoder counts divided by the degrees swept will give me the gearbox ratio of the joint. I do not trust my zero angle location or the hard stop location so the degrees swept will be an estimate. Also there is a furnace duct overhead that limits how far I can sweep the J1 joint so I will be measuring 0 -> -100 degrees rather than +100 -> -100 degrees of travel.

In this test, the scope acquired 59342 triggers which equates to 237,368 encoder counts. The robot manual indicates that this model of robot should have 100 degrees of travel in each direction from 0. Doing some dimensional math gives us 237368 pulses / 100 degrees = 2373.68 pulses per degree. 2373.68 pulses per deg * 360 degree / rev = 854524 counts per revolution. We know that the motor has 8192 counts per motor rev so 854524counts per rev / 8192 counts per motor rev = 104.312 rev/motor rev which is the calculated gearbox ratio.

This answer corresponds closely to the 100:1 value I calculated from the numbers in the robot manual. The source of error is mostly likely in the position of the zero location or the hardstop location. My program shows this value of the distance traveled as 103.52 degrees. I repeated the measurements over a larger swept angle using the angle measurements from the PLC and got a ratio of 100.005:1. I expect the value to be an integer ratio since it is a harmonic drive. so I consider this to be a confirmation of the ratio. The only better check will be to open up the robot and find a gearbox part number. It is not listed in the manual.

The process was repeated for T2 joint. I traveled from 0 to the minus hardstop, very roughly 140 degrees, and measured 67624 pulses or  270496 quadrature counts. This is actually quite a bit more than the 248575 counts estimated in the manual. Unfortunately my scope has a max memory of 80000 acquisitions so I have to separately repeat the process to measure from zero to the other hardstop. In total, I measured approximately 531012 counts over the full travel rage which exceeds the 497150 counts stated in the manual. In practice this is not unexpected since the working range should be smaller than the range between hardstops. Using these numbers and assuming 280 degrees of travel, I get a gear ratio of 83.3:1. Not super close to the 78:1 I calculated from the manual. I need a better measurement of actual degrees traveled.

By locking T1 in position, I was able to manually position T2 at each endstop and use a sharpie held in the robots end effector to mark dots on the table. A machinists scale was used to measure the distance between the dots. By using the formula for a circular chord, I could calculate the angle traveled as 291.87 degrees, a bit larger than the published 280 degrees. Recalculating the gear ratio with this value gives 79.95:1. Again, curiously higher than the 78:1 ratio I calculated from the manual.







The next step was to open up the harmonic drive and locate a part number or count teeth. Doing this ruins my zero angle orientation measured above.


----------



## macardoso

Whoooo! Figured it out. Turns out there is a misprint in the manual and the T2 gearbox ratio is really 80:1! That would really mess up the kinematics. I also confirmed the T1 is 100:1.

I did have to pull the harmonic drives apart to get these numbers so all of my home position measurements are now wrong. No big deal, I will remeasure.

Here is the T1 gearbox showing the Harmonic Drive Corp part number 52-100-960006 (100:1)




Here is the T2 gearbox showing the part number 25-80-960007. (80:1). "25" refers to the diameter of the gearbox.




I still want to validate some other numbers but this might be all I need to fix my issues.


----------



## Boswell

Gotta hate it when the documentation is wrong. Glad you found the issue.  I was also wondering if you could build a jig to help calibrate it. some way to bolt flats on the different moving parts that you could get reliable/repeatable measurements from?


----------



## macardoso

Boswell said:


> Gotta hate it when the documentation is wrong. Glad you found the issue.  I was also wondering if you could build a jig to help calibrate it. some way to bolt flats on the different moving parts that you could get reliable/repeatable measurements from?



Oh this has been driving me nuts. I've been in a great mood all afternoon after figuring this out.

Modern robots have a place to bolt on a mastering fixture which has indicators. Once the robot is moved such that all the indicators read zero, then it is in a known position. I could probably come up with something like this... Haven't thought about it yet.


----------



## macardoso

Got the homing angles measured again just as before. Took 26 measurements for each joint and threw away the highest and lowest outliers. This should be moderately accurate, but between the table flexing and the perhaps 80” loop of bendy stuff between the end of the robot and the tip of the indicator, I found the measurement to be very fiddly. I got values within about 1/2 of a degree at the joint which actually is a fairly large distance at the end of the 18” section of arm. I’d like to come up with a more accurate way to measure this, but it will do for now. Here is the T1 zero angle offset measurement setup




I was able to get the indicator over the centerline drawn on the table by clamping a level to an angle plate, then centering the indicator tip on the edge of yye




And repeated for T2




After updating the program to reflect the new gearbox ratio and zero angle offsets, I booted It up and it worked! All the motion is now linear and constant velocity. Even the absolute distances are accurate as closely as I can measure. It is mesmerizing to watch. I need to write a sample program and then I’ll get a video together to show it running.

Big thanks to everyone following along and commenting. It gives me a drive to keep going on this!


----------



## macardoso

Here is the very first program running coordinated motion with inverse kinematics and path planning. This has been a long time coming.






The robot is executing a series of point to point moves with linear interpolation and constant velocity between each move. The motion is programmed in XYZ space and the PLC handles calculating the joint motor motion. Motion to each successive point is velocity blended such that the commanded position comes within 0.005” of the specified target position.

Move velocity is 10 inch/second. I've tested it up to 30 inch/sec so far without issues. The whole table starts shaking long before then.


----------



## Boswell

Way Cool !   It is great to get to see the results of you considerable effort. Thanks for bringing us all along.


----------



## macardoso

I am working hard at creating a requirements document for the robot's control software. This will help me organize my code and stay focused on the goals. There are a lot of "neat features" that are not critical to the function of the robot but will be fun to try to invent.

Likely the most challenging will be a routine which continuously calculates the robot's workspace based on the tool offsets and orientation, then looks at the robot's position and velocity to determine if the robot is going to exceed the working space or crash into an avoidance zone that has been defined. If this is true, then it will activate a maximum rate stop to keep the robot from entering a singularity or otherwise crashing into an object I wish to avoid.

I am also designing the motion control architecture which will allow me to accomplish my goals. Here is the one I have designed for the V33 software:




There are 3 coordinate systems (blue), 4 real motors/servo drives (grey), 4 analog servo cards (red), and 10 virtual axes (green). These are linked with background motion instructions (purple) and commanded motion instructions (orange).

Without going too deep into how this works, The red analog cards send commands to the grey servo drives - simple. The 4 red analog axes are grouped into a robot coordinate system (blue). This is linked through the Motion Coordinated Transform with Orientation (MCTO) to the cartesian coordinate system (blue) with six virtual (non motor controlling) axes. 3 axes are for the cardinal directions X, Y, Z, and the other 3 control rotation about those cardinal axes. My robot does not support rotation about X or Y so those are essentially unused. The command Motion Coordinated Path Move (MCPM) controls this coordinate system and supports linear motion with coordinated orientation control (change tool rotation while moving).

In order to support circular motion, a 3rd coordinate system (Command CS) is added with 3 cardinal virtual axes (green). These link to the Cartesian coordinate system cardinal axes through 1:1 electronic gearing (Motion Axis Gear - MAG). The non-orientation controlling coordinated instructions Motion Coordinated Linear Move (MCLM) and Motion Coordinated Circular Move (MCCM) can now be used. All of this is linked to a master speed reference virtual axis using Master Driven Coordinated Control (MDCC) and Master Driven Axis Control (MDAC). This is the most complicated part but it allows me to turn one knob and adjust the overall speed of the robot. This can accomplish speed override and feed hold very easily. The master speed is set by the Motion Axis Jog (MAJ) command against the Master Axis.

Orientation of the tool can be controlled in coordination with a linear move using the MCPM instruction or independently using a Motion Axis Move (MAM) instruction while another instruction is running. I can issue commands only from the orange blocks.

This is probably the most complicated motion structure I have ever worked with and will be the first thing I actually program.

Once I get the requirements specification a little more polished, I will share it with everyone.


----------



## macardoso

Alternatively, If I wanted to program in V32 (before automated control of tool orientation) then the architecture would look something like this:




Fewer axes but a lot more motion instructions. One challenge is that you cannot have more than one Motion Axis Gear (MAG) active on a slave axis at one time. Therefore I'd have to come up with something else for T3 and T4 since they have too many gear instructions. There are other instructions that can be set up to behave like a gear if needed.

After all this, I'd still be short of the Tool Center Point (TCP) control available only in V33.


----------



## brino

Mike I was following along .....to a point....
.....but now I think these smilies say it best......














-brino


----------



## hman

I've ALWAYS been impressed with the ability of robot controllers to do the coordinate conversions required for cartesian motions and linear (or other path) interpolations - in real time!!!  It really illustrates the computation speed of computers (even the ones 20 years ago, when your robot was built).  As with others, I've been "lightly" following your fascinating build, but you've definitely left ne in the dust with respect to many of the details.

Congratulations on the first functional test!


----------



## macardoso

hman said:


> I've ALWAYS been impressed with the ability of robot controllers to do the coordinate conversions required for cartesian motions and linear (or other path) interpolations - in real time!!!  It really illustrates the computation speed of computers (even the ones 20 years ago, when your robot was built).  As with others, I've been "lightly" following your fascinating build, but you've definitely left ne in the dust with respect to many of the details.
> 
> Congratulations on the first functional test!



It really amazes me that this can be done. I have to imagine the first guys trying to make robots work would have run into the difficulty of the task and I cant believe they didn't say this was more effort than it is worth.

I'm standing on the shoulders of giants here. Someone has pretty much done all the work of the inverse kinematics for me in the PLC. Granted it all needs to be set up correctly and I need to write a program to tell it what to do, but still all of the "hard" stuff is done behind the scenes. I tried learning all the math on my own about two years ago. I got through deriving the kinematic equations and the multiple inverse kinematic solutions, but that only tells you what position to move the joints to give a specific XY position. Beyond that, velocity and acceleration control, the actual path planning, etc. was beyond me.

I always picked on my computer science buddies in college ( I did Mech E. and EE) for having to take linear algebra, but now I do regret not taking it. The math for robots is laid out in matrices and I would have had a much easier time with the math if I had formally learned it.

Not sure if I mentioned it earlier, but if anyone comes along this thread and is really interested in robotics, the textbook "Introduction to Robotics: Mechanics and Control" by John J. Craig is excellent. It gently introduces you to the subject in the first few chapters with some simple robot configurations and basic math. By chapter 4, you are solving full kinematic solutions to robots (I spent nearly 3 months getting through that chapter). It goes on to cover Jacobians (velocities in robots), trajectory generation, singularity avoidance, linear and non linear control of an actuator, force control of a robot, and some robot programming (which I expect to be a bit out of date for modern robots). I really wanted to finish this book but lost focus since I didn't have a real robot to mess with yet. I would enjoy jumping back into it if I ever find myself with free time (haha).






						Introduction to Robotics: Mechanics and Control (3rd Edition): Craig, John J.: 9780201543612: Amazon.com: Books
					

Introduction to Robotics: Mechanics and Control (3rd Edition) [Craig, John J.] on Amazon.com. *FREE* shipping on qualifying offers. Introduction to Robotics: Mechanics and Control (3rd Edition)



					www.amazon.com


----------



## macardoso

I changed my program back to V33 using the kinematics with orientation control. Ran into a few issues along the way but ended up being successful. Below is a video showing the transform maintaining the angular position of the U axis (Look at the tape flag at the top of the white "tool"). This requires coordination of all 4 motors simultaneously. In the software I am only commanding a motion along the virtual cartesian X axis, the transform is doing the rest.






I have also modified the program to only require the robot to home after a power cycle. If the robot has been homed already the motors just turn on since they already know their absolute position. Additionally, the kinematic transform is kept active even when the motors are disabled. The transform automatically switches into "forward mode" and calculates the XYZU positions based on the joint motor angles. I can manually push the robot around and the transform updates the on-screen displays to show me the cartesian position.


----------



## macardoso

Here is a simple program showing the robot executing a joint flip:






The kinematic transform cannot support this transition natively. Doing so would require it to approach the workspace boundary which is a mathematically undefined region which calculates infinite joint velocities. In this video, cartesian motion is programmed to approach very near the workspace boundary, then a set of synchronized moves are executed on the joints to re-orient them in the desired position, then cartesian moves may again be programmed without ever disabling the kinematic transform. The transition is accomplished with constant joint velocities rather than constant cartesian velocity.

In the final version of my software, I hope to have this process automated where I can define a vector along which to generate the joint flip, and all the motion and velocities required to make it happen are calculated automatically.

Orientation is not controlled through the flip, giving the incorrect orientation in the "lefty" configuration after the flip. I still need to figure out how to transition to a new orientation, but it shouldn't be too hard.


----------



## macardoso

After a very long hiatus from this project, I got a kick to pick it up again. I'm stationed up in Alaska for work for a month and the sun barely sets so I have a bit of free time to work on the code side of this project while my shop is 4000 miles away.

I'll share the progress I make here, but I do want to clarify that I am not a programmer by trade so there are likely plenty of things I am going to do in a sub-optimal way. Also, I will be programming this on an Allen-Bradley ControlLogix PLC since it has some powerful real-time motion control built in that I am already leveraging for control of the robot. This makes the robot integration easy but takes away most of the nice programming constructs you have with C++, python, or any other computer programming language. 

I have shared some fancy code architectures in the past, but I decided I wanted to start somewhat simple and work on the G-code parser and interpreter. The function will take a command bit, read one line of G-code, parse it into a data structure, and return. Once the data structure is filled, the motion planner will take over and execute the functions intended by the line of code.

Here is where I have gotten so far:



		Code:
	

Err := 0;
ExErr := 0;
k := 0;
l := 0;

COP(SampleCode[0],WorkingString,1); //Copy G-Code to Working Tag
FOR i := 0 to WorkingString.LEN by 1 do; //Remove all Spaces
    FIND(WorkingString,SpaceCharacter,1,Location);
    if Location <> 0 then
        DELETE(WorkingString,1,Location,WorkingString);
    else
        exit;
    end_if;
end_for;

UPPER(WorkingString,WorkingString); //Capitalize all characters

if (WorkingString.DATA[0] < 65) OR (WorkingString.DATA[0] > 90) then // Check if first character is a letter, if not, set error
    Err := 1;
    ExErr := 1;
end_if;

while (WorkingString.LEN >0) do //loop through the entire working string and pull out all the key-value pairs and place them in the key-value array
    for j := 1 to WorkingString.LEN by 1 do    ; //Search for the next key character
        if (WorkingString.DATA[j] >= 65) AND (WorkingString.DATA[j] <=90) then
            NextKey := j;
            exit;
        end_if;
    NextKey := WorkingString.LEN;
    end_for;
    Mid(WorkingString,1,1,Key[k]); //Copy Code at index 1 into key array
    l := NextKey - 1;
    Mid(WorkingString,l,2,Value[k]); //Copy code between index 2 to the next letter into value array
    STOR(Value[k],RealValue[k]); //Convert the array of values to REALS
    k := k + 1;
    DELETE(WorkingString,NextKey,1,WorkingString);
end_while;


The code does the following functions:

Copies a line of code from the program file to working memory
Delete all spaces from the string
Capitalize all the letters
Pull out all the letter(key)-value pairs and store them in an array
Convert all the values from string to floating point REAL datatypes
The language is a Rockwell Automation PLC programming language called Structured Text. Most PLC code is programmed in Ladder Logic, which I will be using for 90% of this program, especially the motion control, however Structured Text is excellent at array manipulation and loops which I need for the parser.

The data is stored in a User-Defined DataType (UDT) which I can create with all the structures necessary to store the parsed data. I am still in the early stages of figuring out what is needed, but here is what mine looks like so far.




Once the data is sorted into matching Key and Value arrays, I will have a second half of the parser place the data into the correct spots in the UDT, as well as particular global variables as needed. I've really only roughed the comments for this part but this is somewhat how it will look:



		Code:
	

//-------------------------------------------------------------------------------------------------------
//------------------Code Parser---------------------------------------------------------------------
WorkingMotionData.Feedrate := Val_Feedrate;

For n:= 0 to 40 by 1 do
    case Key[n].DATA[0] of
        65: //A
            // No function coded at this time
            // A is reserved for motion about a rotary axis aligned along the X axis
        66: //B
            // No function coded at this time
            // B is reserved for motion about a rotary axis aligned along the Y axis
        67: //C
            // No function coded at this time
            // C is reserved for motion about a rotary axis aligned along the Z axis
            // Note that for the SCARA robot, U is used for rotary about Z axis
        68: //D
            // No function coded at this time
        69: //E
            // No function coded at this time
        70: //F
            Val_Feedrate := RealValue[n];
            WorkingMotionData.Feedrate := Val_Feedrate;
        71: //G
            case RealValue[n] of
                0:
                    //Move Rapid rate into feedrate
                    //Linear Interpolation
                1:
                    //Move Feed rate into feedrate
                    //Linear Interpolation
                2:
                    //Set circular interpolation CW
                3:
                    //Set circular interpolation CCW
                4:
                    WorkingMotionData.Sts_Dwell := 1;
                5:
                    //High performance look-ahead milling - not implemented
                6:
                    //Rational B Spline Machining
                7:
                    //Imaginary Axis Designation
                9:
                    //Exact Stop Termination
                10:
                    //Programmable Data Input
                11:
                    //Data Write Cancel
                12:
                    //Full Circle Interpolation CW
                13:
                    //Full Circle Interpolation CCW
                17:
                    //XY Plane Selection
                18:
                    //ZX Plane Selection
                19:
                    //YZ Plane Selection
                20:
                    //Set units to inches
                21:
                    //Set units to mm
                28:
                    //Return to home position
                30:
                    //Return to secondary home position
                31:
                    //Skip Cycle
                32:
                    //Long hand single point threading
                33:
                    //Constant Pitch Threading
                34:
                    //Variable Pitch Threading
                40:
                    //Tool Radius Compensation OFF
                41:
                    //Tool Radius Compensation Left
                42:
                    //Tool Radius Compensation Right
                43:
                    //Tool Height Offset (Negative)
                44:
                    //Tool Height Offset (Positive)
                45:
                    //Axis Offset Single Increase
                46:
                    //Axis Offset Single Decrease
                47:
                    //Axis Offset Double Increase
                48:
                    //Axis Offset Double Decrease
                49:
                    //Tool Height Offset Cancel
                50:
                    //Set Maximum Spindle Speed (CSS)
                    //Cancel Scaling
                52:
                    //Local Coordinate System (LCS)
                53:
                    //Machine Coordinate System
                54:
                    //WCS 1
                55:
                    //WCS 2
                56:
                    //WCS 3
                57:
                    //WCS 4
                58:
                    //WCS 5
                59:
                    //WCS 6
                54.1:
                    //Extended WCS (Requires P1-48)
                70:
                    //Canned Cycle
                71:
                    //Canned Cycle
                72:
                    //Canned Cycle
                73:
                    //Chip Break Canned Cycle
                74:
                    //Tapping Canned Cycle (LH)
                76:
                    //Fine Boring Canned Cycle
                80:
                    //Canned Cycle Cancel
                81:
                    //Simple Drilling Canned Cycle
                82:
                    //Drilling with Dwell Canned Cycle
                83:
                    //Peck Drilling Canned Cycle
                84:
                    //Tapping Canned Cycle (RH)
                90:
                    //Absolute Coordinate System
                91:
                    //Incremental Coordinate System
                92:
                    //Position Register
                94:
                    //Feedrate Per Minute
                95:
                    //Feedrate Per Revolution
                96:
                    //Constant Surface Speed (CSS)
                97:
                    //Constant Spindle Speed (RPM)
                98:
                    //Return to initial Z level in canned cycle
                99:
                    //Return to R level in canned cycle
            end_case;                 
        72: //H
            WorkingMotionData.HeightOffset := RealValue[n];
        73: //I
            WorkingMotionData.ArcCenter[0] := RealValue[n];
        74: //J
            WorkingMotionData.ArcCenter[1] := RealValue[n];
        75: //K
            WorkingMotionData.ArcCenter[2] := RealValue[n];
        76: //L
            // No function coded at this time
            // L contains the number of times to repeat a subroutine/canned cycle
        77: //M
            // No function coded at this time
        78: //N
            // No function coded at this time
            // N typically is coded for a line number and should not cause a control function
        79: //O
            // No function coded at this time
            // O is typically coded for the program number
        80: //P
            WorkingMotionData.DwellTime := RealValue[n];
        81: //Q
            // No function coded at this time
            // Q is the depth of peck in a canned cycle
        82: //R
            // No function coded at this time
            // R is the retract height in a canned cycle
        83: //S
            WorkingMotionData.SpindleSpeed := RealValue[n];
        84: //T
            WorkingMotionData.ToolNumber := RealValue[n];
        85: //U
            // No Function coded at this time
            // U should be the rotary motion about the Z axis
        86: //V
            // No Function coded at this time
            // V is an auxillary axis
        87: //W
            // No Function coded at this time
            // W is an auxillary axis
        88: //X
            WorkingMotionData.PositionData[0] := RealValue[n];
        89: //Y
            WorkingMotionData.PositionData[1] := RealValue[n];
        90: //Z
            WorkingMotionData.PositionData[2] := RealValue[n];
    end_case;
    if (Key[n+1].LEN = 0) then
        Exit; //At then end of the data in Key, exit the loop early
    end_if; 
End_for;


Once I get this working, I'll need to optimize it for scan time. The controller will only have a look-ahead of one block, so lots of extremely short moves will race against the processing time to parse and prepare the next move. The motion controller should be able to keep up a 2ms position command refresh no problem.

More to come - Mike


----------



## macardoso

Well, here it is 7 months later and I really haven't made any progress forward. Life got immensely busy and I haven't had a chance to catch my breath. Wife and I moved from Cleveland to Detroit and are getting settled in our first owned home!

I left off on this project feeling a bit overwhelmed by the programming task in front of me. The robot and kinematics work perfectly, however I am limited to programming, in PLC ladder logic, a fixed operation for the robot. This is perfect for a defined task (like a robotic tool changer for my CNC mill), however it greatly lacks flexibility and ease of programming. For this reason, I really want to be able to have the robot run on G-code. Doing so allows rapid programming and availability to use graphical CAD/CAM programs to generate robot motion (rather than moving a cutting tool). There are low cost hobby programs which do this (Mach 3/4, LinuxCNC, GRRBL, etc.) but they lack the kinematics for the robot (well, it is possible in LinuxCNC, but that's a bit more complicated). So, to get the robot running on G-Code, I needed to essentially write these programs from scratch in PLC logic. I have actually done something very similar before (sadly I don't have the code) but it is a monumental task and there are a ton of gotchas which I have never found a good workaround for (like copying a text G-code file from a flashdrive to the PLC). I got a start on this task in June 2021 but stalled out.

I was helping a buddy set up his first CNC machine and I had a lightbulb moment! The Rockwell PLC, once kinematics are active, allows you to electronically *gear* the robot's motion (in a cartesian axis) to an external encoder input. This is a common application for conveyor belt integration. The robot uses a camera system to locate a part on the conveyor, moves to the desired pickup location, then matches belt speed and direction during pick-up of the product. An encoder on the conveyor constantly streams position/velocity data about the conveyor to the PLC so that the robot matches the product motion exactly, even if the conveyor changes speed.

Check out this video at the 1:00-1:20 mark.











OK, well why do I care? Well it gets better. Not only can the PLC track one encoder, but it can track one encoder per cartesian and ancillary (rotation) axis *all at the same time*. In my SCARA robot with 4 degrees of freedom, this would be XYZ and U (rotation about Z). In a 6 axis robot you would have XYZUVW. And rather than commanding robot *velocity* as in a conveyor application, then encoders technically command *position* as one encoder pulse equates to a discrete step in distance or angle of rotation. OK cool. So I can have 4 encoders to command the robot around in 3D space. The encoders command cartesian positions and the PLC continues to handle the kinematics to generate the joint motion that places the end of the robot in the desired 3D space.

Well here is the lightbulb moment. The coordination of the 4-6 encoder signals that I want is exactly what all these CNC control programs (like Mach 4) do. So forget about all that custom programming of the G-code interpreter into the PLC, I'll do all that on a computer running software designed to do it. The software will send commands to a motion control board which will produce output command signals that look exactly like encoders to the PLC. My motion control board of choice, the Warp9 Ethernet Smoothstepper (used on my CNC mill) gives you the option to output step/direction pulses for stepper drives, or quadrature signals that look like encoders. The PLC is still handling the kinematics, so Mach 4 thinks it is commanded any normal CNC milling machine.







So in summary, Mach 4 handles reading G-code, motion planning, and axis coordination. The motion controller connected to Mach 4 generates signals for each axis that look like encoders. The PLC reads these encoders and blindly follows where they command the robot to go. The PLC converts cartesian (XYZ) coordinates to robot joint coordinates. And finally the PLC commands the servo drives to move the robot.

The PLC will need to handle functions like homing the robot and there will need to be some IO and communications between Mach 4 and the PLC (potentially digital IO for critical signals and Modbus for diagnostic data), but that is doable. Work offsets would be accounted for in Mach 4, but tool offsets (due to the nature of how they affect the kinematics) must be handled by the PLC.




In order to read the (4) encoder inputs, I'll need (2) more dual channel analog servo cards (1756-M02AE). Each of these allows you to read (2) feedback only encoder axes. Remember, I'm already using (2) of these cards to command servo motion on the (4) robot joints. These are expensive modules, retailing at over $3000 each, but due to their age and the obscurity of their applications in modern motion control, there are literally hundreds of them on ebay, many selling in the $30 range.




I have some additional robotics related news that is a secret for now, but stay tuned!

Whooooo! I am excited about this again!


----------



## brino

macardoso said:


> Whooooo! I am excited about this again!



I can hear your excitement and enthusiasm....... in fact, that's about all I understood from your post!


I will have to read it thru again later, with a big cup of coffee.

Brian


----------



## Boswell

macardoso said:


> Whooooo! I am excited about this again!


Gotta love mental breakthroughs like this !  Looking forward to hearing about your progress again.


----------



## macardoso

I'm going to put some info here, mostly for my own good about connector kits and other parts I'll want to update the wiring on this robot. When I was prototyping on this system, I hand wired lots of D-Sub connectors for attaching to the servo drives. Going forward, I'd like to start replacing those with purpose built cable sets using crimped D-Sub connectors. I think I will also build a custom PCB for the robot SIGNAL cable (MDR-68 connector) rather than having a ton of wires going all over the place. I'll also need to build a purpose built daughter board for the Ethernet Smoothstepper with optical isolation up to 4MHz for the encoders, and some cheaper ones for the general purpose IO.

*DB-15HD*
Plug Body: 180-015-173L000   (LINK)
Pins: 180-001-170L001   (LINK)
Backshell: 977-009-020R121   (LINK)

*DB-44HD*
Plug Body: 180-044-173L000   (LINK)
Pins: 180-001-170L001   (LINK)
Backshell: 977-025-020R121   (LINK)

*MDR-68 Socket, PCB pins*
Socket: DX20A-68S(50)   (LINK)

*PCB Terminal Blocks, Removable, Screw Clamp, 4 position example*
Receptacle, 90 Deg.: TBP02R1W-381-04BE   (LINK)
Receptacle, 0 Deg: TBP02R2W-381-04BE   (LINK)
Plug: TBP02P1W-381-04BE   (LINK)

*Optoisolator, 1 Channel, High Speed (5Mbps), 5V*
Optoisolator: TLP2395(TPL,E  (LINK)

*Cheap crimper that claims to do D-Sub:* LINK


----------



## macardoso

macardoso said:


> I have some additional robotics related news that is a secret for now, but stay tuned!


Alright I didn't want to jinx it before I knew I had won the purchase, but I got another robot! This is a 6 axis unit. I expect the project to follow the same path as this one did, but much of what I did to make this one work won't apply to the new one unfortunately. 

Feel free to follow along if you'd like: https://www.hobby-machinist.com/threads/mikes-6-axis-articulated-robot.97888/

I plan on working on them concurrently as getting this one running on G-Code will also help the next one.


----------



## macardoso

Bit distracted since I have a second robot now, but I did get 2 more analog modules in the mail. I really want to try hooking them up to a smoothstepper and letting it run. I just need a second Smoothstepper now.

As I've started learning about the 6 axis robot, I've learned that they are not really suited for control by Mach 4. The issue is that there are many places within its workspace volume that it cannot go, or had limited articulation within. If you try to control the robot in XYZ space, you'll find you can't move far before running into a limitation of articulation and the robot will fault out. Most sources I've seen recommend doing all the moves in joint space, where mathematical limitations don't apply, and saving the cartesian moves for the final approach to your target position.

The SCARA on the other hand doesn't suffer from this (other than the joint flip). As a result, it should be perfect to run G-Code, as long as it falls within the workspace of the robot and does not require a joint flip.  

Haven't forgotten about this project.


----------



## macardoso

I moved late last year and haven't had a chance to work in the shop much at all. Finally got the SCARA robot set up on the table again at the new house, and I have an electrician coming next week to set up power.

One nice thing is that the ceiling is slightly higher in this house so the cable bundle can move freely without striking any ductwork which really increases the working area of the robot.




I still plan to try out the idea of controlling this from CNC software but just need to find the time.


----------

