Archive for the 'CNC' Category

Using The midTbot Controller

The midTbot Controller is a controller for midTbot pen drawing machines. It is sold on my Tindie store. When fully populated, it has the following features.

  • (2) Stepper Motor Drivers for the X and Y axes with microstepping selector jumpers
  • Servo Connector for Pen Lift
  • Arduino Nano Controller
  • 5V power supply
  • (2) Homing switches
  • Bluetooth connector for HC-05 or HC-06 module.
  • Aux power connector for easy access to 5V and 12V power.

Power Supply

You will need a 12V DC power supply with at least 3A of power. The DC plug should be a coaxial 5.5mm x 2.1mm type with center positive. This type of plug is the most common type and should be pretty easy to find.

Microcontroller.

You should use an Arduino Nano compatible controller. The controller bootloader will need to be changed to the smaller Arduino UNO bootloader in order to fit the firmware. I have instructions on how to do this here. If you would like to buy one already modified, I sell them on my Tindie store. Be sure to install the controller in the correct orientation. The USB connector should face the edge of the controller as noted on the silkscreen of the controller PCB.

Stepper Drivers

You will need 2 stepper driver modules. I recommend ones based on the Allegro A4988 controller or the TI DRV 8825 controller. The drivers often come with heatsinks. The current will typically be set low enough that heatsinks are not needed.

You will need to set the microstepping level. I recommend using 1/8 microstepping. That gives a good balance of accuracy, smoothness and speed. You set this using the jumper blocks. Each stepper driver type has its own configuration. Here are the jumper setting for A4988 and DRV8825

Microstep ResolutionA4988 JumpersDRV 8825 Jumpers
FullNoneNone
1/2MS1MS1
1/4MS2MS2
1/8MS1 + MS2MS1+MS2
1/16MS1+MS2+MS3MS3
1/32Not AvailableMS1+MS2+MS3

Note the MS1, MS2 & MS3 labels next to the jumpers.

The orientation of the drivers is very important. You will break the drivers and likely other parts if you insert them wrong. Most drivers have the pins labeled and the the controller PCB has the corner pins labeled. Be sure the labels match. Here are the correct orientations for the A4988 and DRV8825.

You should set the stepper driver output current to the level required by your stepper motors. The midTbot does not need a lot of power. If you set the power too high, the motor could get hot and damage the 3D printed part it mounts to. You set the current by adjusting a potentiometer and reading a voltage. The drivers need to be powered when you do this. You can install them and power the board to do this. Do not connect the motors when adjusting the potentiometer. Each driver will have a small hole with exposed metal. This is the measurement point. The metal adjustment screw of the potentiometer is also a place you can measure. The reference voltage to current formulea are here.

DRV8825 Current = VREF * 2   (Example 0.4V = 0.8A current)

A4988 is a little more complicated because there are different versions. See this page.

Stepper motors:

The controller is designed for NEMA14 motors. Be sure to get 4 wire motors. Just about any size should work, but I prefer to use smaller ones to keep the size and weight down. You will need to attach connectors to them.  Trim the wires to the correct length so they reach the board connectors when installed. Wires colors should be installed as shown.

The wiring legend on the board that shows where to plug in the motors might not be right. It depends on the way the motor manufacturer wired the coils and which stepper drivers you use. You may need to swap them or rotate the connectors 180° if your axes are moving the wrong way. Here is a photo of how mine are wired. Try this first. Note the wire colors and which motor goes to which connector.

Bluetooth

You can add an HC-05 or HC-06 Bluetooth module. They have different connectors, but just match the pin names on both sides. You will need to setup the module to have a baud rate of 115200, N,8,1. I have detail on how to do that here (HC-05, HC-06).

 

 


If you want to be notified of future blog posts, please subscribe.

Bus Servo Draw Bot

I wanted to complete a start to finish project with the LX-16A bus servos to do a complete review of their viability for the type of mechatronics projects I do. The low price of the LewanSoul bus servos make them a competitive option over digital servos. I chose to do a remake of the Line-Us clone drawing machine because I would not need to spend too much design time and it would be a good 1:1 comparison with digital servos. Since the bus servos are quite a bit larger, I decided to scale up the machine by 1.5x.

Made My Own Brackets.

I started by buying one servo and it came with brackets. When I went to get more, I noticed the price was lower. I did not realize I was getting these without brackets. These are the brackets you get with the more complete kit.

I requested some 3D models from LewanSoul. They were only able to provide 2D DXF files, but they were easy to convert in Fusion 360. This allowed me to 3D print some brackets. It actually worked out quite well because I was able to thicken up the brackets and integrate some captive square nuts.

They mounted easily to the servos and were plenty strong for this project.

Servo Arms

I made two arms and one short cam for the Z. They were about 4mm thick and had a little pocket that slid over the standard round actuator. They screwed on with the screws that come with the servos. Before mounting anything I turned on the servos and moved them to the center of the range. This put the arms at a known angle.

Support Bracket and Base

The support bracket holds all three servos and there are 2 pockets on the bottom for some shaft bushings.

The base has two shafts pressed into it.

The shafts slide into the bushings and there is a spring to hold the parts together.  The spring prevents the pieces from separating and also provides a little extra pull down force in case the shafts bind a little. The cam provides about 6mm of lift.

Final Assembly

The servos are mounted to the support bracket.

The wires are connected to the servos. They just daisy chain from one servo to the next.

The remaining links are then connected.

Testing

Here is a video of the first run.

Results

I think these are a good alternative to digital servos. They are very strong, easy to mount and accurate. Depending on the design of the controller, using a simple UART might be easier than having multiple PWM signals or extra hardware. The servo’s size might be larger than some machines need but that comes with the higher power.

Source Code

Some people have asked for the source code. Here is what I have. I just tweaked something I had to be good enough for this demo. I can’t offer support for it other than a few quick questions asked on this blog post.

Assembly Model

all I have is this partial STEP File

 

 


 

If you want to be notified of future blog posts, please subscribe.

LewanSoul Lobot LX-16A Serial Servo Review

I stumbled upon these LewanSoul LX-16A Servos the other day on Amazon while searching for standard digital servos. These servos are digital serial bus servos. That means they use a serial protocol on a bus rather than a PWM signal. I have used bus servos before, but the $12 price got my attention. That competes well with plain old PWM servos.

Serial bus servos have some real advantages over standard PWM servos.

  • Wiring: The wiring can be a lot simpler because you can put all your servos on a single 3 wire bus. Each servo has 2 connectors to make daisy chaining easier.
  • Higher resolution: The resolution is typically higher. It depends on the way they sense position. These use a high accuracy potentiometer and list 0.24° as the resolution.
  • You can set the speed: You can set a destination and speed for each move.
  • Set the range: You can limit the range of the servo. This is great if the using the full range would crash a joint on your machine.
  • Continuous turn mode: There is a speed adjustable continuous rotation mode on these, but absolute distance moves cannot be done.
  • Motor On/Off: Turn the motor off for manual movement.
  • Feedback: The communication is bi-directional so you can query a servo for…
    • Position: If you manually move a servo, you get its position. This is great for recording “poses” or setting range limits.
    • Temperature: You can read the current temperature of the motors.

Compared to Robotis

I have used the Robotis Dynamixel XL320 servos before but these are a lot stronger and the XL-320 has a weird, plastic rivet, mounting systems that I am not fond of.

Here is a size comparison with a XL-320.

Specs

Spec LX-16A XL-320
Max. Torque 17 kg-cm 4 kg-cm
Resolution 0.24° 0.29°
Range 240° and Continuous Rotation 300° and Continuous Rotation
Speed 62 RPM 114 RPM
Weight 52g 16.7g

Usage

To use the servos you need to use one of their controllers. The most basic controller just converts a USB or TTL serial signal to their protocol. The controller is small and low cost ($10). You can send commands via a USB (Com Port) or via the TTL pins.

Setup Program.

They have a setup program.  The program is Windows only and I had to run it in Administrator mode to get it to work. This makes setting up the servos easy, but you could write your own program if you don’t want to use theirs.

TTL Control

They also provide some Arduino Sketches. They worked fine and are a good place to grab some code if you are writing your own program.  The sketches use the Arduino hardware TX and RX pins. That conflicts with uploading, so you need to disconnect the controller every time you upload. I edited the sketch to use SoftwareSerial on some other pins and that made playing with the code a lot easier.

First Impressions

I found the servos very easy to use and they appear to be strong and responsive. I think they will be a good option for my on my machines.

Next Steps

I want to test these in a real machine. I thought I might try to make a slightly larger version of my Line-Us clone. That would be a good comparison of accuracy. I might try one day build on it tomorrow.  I can probably get a machine designed and built in a day, but the controller programming would need more time.

 

The Polar Coaster – A Drink Coaster Drawing Machine

I designed this machine to draw custom, round drink coasters. I already have a laser cutter for square coasters and I wanted to try something unique for round coaster.

The Base

The base of the machine has two stacked 5mm bearings in the center for the bed to rotate on. There are (3) 3mm bearings on the bed perimeter that provide support and keep it level. They have little shafts that snap into the base.

The Bed

The bed is  a 156 tooth GT2 pulley. It has little springy fingers that grip the coaster when it is on the bed. The bed connects to the motor pulley with a closed loop belt.

The Radial Arm.

This is a belt driven, cantilevered arm that uses 6mm shafts and linear bearings. The belt is a cut pieces with the ends clamped at the carriage. It has a slotted mounting hole that lets the arm rotate. The pen must be adjustable to get to the exact center of the coaster or the drawing will be distorted. There is a limit switch on the top.  This is the only axis that needs to be homed. To setup the machine you home it and jog the pen until it is exactly over the center of the bed. You then set the work zero for X (Gcode: “G10 L20 P0 X0”). This only needs to be done once. If you use different types of pens, the center should be rechecked.

The Z Axis

The Z axis uses a micro servo and a cam to control the height of the pen. The firmware is setup to only have (2) Z positions, pen up and pen down. It uses 3mm rods and tiny little 3mm linear bearings.  There is a compression spring on one of the rods that applies a little pressure to the pen, and allows the pen to float a little on uneven coasters.

The Controller

I used my Grbl HAT controller. It is a bit overkill for this project but works perfectly.  It is attached to a Raspberry Pi in this photo, but I have not been using the Pi in this project yet. I just connect directly via USB.

Kinematics and Pre-Processin

See this blog post on how it was done. The pre-processor is written in C#, but it is rather simple and you could probably read the source file and convert if you cannot deal with C# on Windows.

Firmware

I use a modified version of Grbl 1.1f.  Grbl does not support servos, so I needed to hack that in.  I used the PWM that is normally used for the spindle speed to control the servo. I turned off the variable speed spindle option and streamlined the spindle functions to the bare minimum I thought Grbl needed.  I adjusted the PWM parameters for use with a servo and added pen_up() and pen_down() functions. I tried to put as much of the custom code into one file spindle_control.c. I had to add a few lines in stepper.c to look at the current machine Z height and apply the correct pen up/down function.

CAM

You can use anything to generate the gcode that works with Grbl. The pen will go up when the Z is above zero and down when it is below zero. Therefore, you want the Z movement as short as possible to speed up the drawing and not have the pen dwell on the material and bleed.  I make the depth of cut 1mm and the z clearance 3mm.

CAD Files.

The design was done using PTC CREO 3.0.  A STEP version of the design is linked at the end of the post.

Performance

It does a great job. Here a recent coaster. This was done from a rasterized bitmap image found online (searched: circular Celtic braid).

Here is a Fat Tire beer themed coaster.

Coasters are made to be super absorbent, so larger tipped felt pens tend to bleed a little too much. I like to sketch with Micron pens and the thinner ones really work well on this machine.

Build You Own?

The build is not difficult, but covers a lot of areas. You should know how to work with STEP files and compile firmware.

The design is open source with no commercial restrictions, so feel free to use any part of my work. I found most of the parts on Amazon and eBay. I bought the belt from Stock Drive Products. The polar motor pulley is 36 tooth and the arm pulley is 20 tooth.  Cutting the shafts requires an abrasive cutoff wheel.

Please post any questions in the comments section and I will try to address them.

Links

 

I sell on Tindie

 

 

 

Polar Pen Machine Kinematics

When you have a round work piece like a drink coaster, it makes sense to have a round work area.  A round work area works best with a polar coordinate system. A polar coordinate system uses an angle and a distance from a center point to define a point in 2D.

The problem is that most drawing and CAM programs work in Cartesian (X,Y,Z) coordinate systems. My machine controller firmware, Grbl, also works in normal linear X,Y, and Z. The process of converting one system to another uses Kinematics.

 

The Firmware

The firmware is side is actually quite easy. I defined the X axis as the distance in mm from the center (the radius). The Y axis will control the angle. The Y axis is setup so that millimeters will equal degrees. If I tell the Y to move 360mm, it will actually rotate the work area by 360°.  I could have used radians, but my brain works a lot slower in radians.

The machine will only need to home on the X axis. It needs to know where the exact center of the work area is. The starting angle does not matter because the coaster is a circle.

The conversion from X, Y to polar is probably won’t fit in into the firmware, so the X, Y conversion is done in a preprocessor software program. The X,Y gcode is output from normal CAM programs, then run through a conversion program.

The Conversion Program

The program reads the X,Y gcode, converts any X or Y coordinates into polar coordinates and outputs a new gcode file. The sender simply sends the new files.  The math is actually quite simple.

Typical Gcode sends line data by giving the end points of lines. You simply draw from one point to the next, unfortunately this creates a few problems with a non linear machine.

The basic non-linearity problem

If we were trying to draw the green square centered on the work area, the generated gcode would basically send the corner points. Each corner point has an equal radius to the center. Therefore, the pen will never change radius when going to the next point. This will result in a circle. We want the green square, but we get the red circle.

We need to calculate each point along the way to stay on the desired path. The preprocessor divides the line into tiny segments. Each segment has the same problem, but at a scale you won’t be able to see.

The Spiral Problem

If we are drawing a shape that crosses the 0° angle we don’t want the angle to spin the wrong way. If a point is at 350° and the next point is 10° (crosses over 0) we don’t want it to spin backwards from 350° to 10°. We want it to go to 370°.  It happens anywhere the angle difference between 2 points is greater than 180°. The program will choose the shortest direction even if that means going above 360° or below 0° degrees.

The Feed Rate Problem

Feed rate, in CNC terms, is the speed of the tool across the material. The CAM software is setting the feed rate as if this were a Cartesian machine. On this machine, if you were drawing a circle, you would simply move 360 units in Y. Without compensating feed rate, the pen would move across the work piece faster for larger diameter circles. I want to do some sort of compensation to help with this. The coasters are very absorbent, so the  lines look thicker if the speed is slower. A consistent speed will help the quality of the work.

Since the lines are all very short, the easiest way to compensate for feed rate is to use the current radius. With a simple circle, Grbl thinks the machine moved 360mm. The real distance is easy to to calculate from the perimeter of that circle.

We can compare it to the 360mm (full circle) and apply the ratio to the desired feed rate from the CAM program.

polarFeedrate = cartesianFeedrate * 360 / (2 * pi * radius)

 

Video

Here is a video of it. The machine is rerunning a file to see the repeatability.

Next Steps.

I would like to automate the preprocessor.  I think a Raspberry pi, might be an easy way to do this.  It would sit between the sender and the controller.

 

 

 

Coasty Update

Here is a quick update on Coasty. Several people have asked if I am releasing the source files or selling a kit. I am adjusting the design to make that more viable.  The original version was made with parts I had laying about and not necessarily the best design choices for an open source project.

X Axis.

Originally I used an TR8-8 ACME thread lead screw. It was mounted to the motor by drilling a hole in the lead screw and epoxying it to the motor shaft. This worked well, but you needed a lathe to drill the hole and a special low backlash nut. The axis was also a little loud with and all metal design.

I changed to use a GT2 open belt cut to length.  Belts and pulley are really easy to get and don’t cost too much.

Electronics

Need to shorten some wires after testing.

There were some issues with the EleksMaker electronics that I did not like. The laser circuit did not appear to have a pull down on the signal and it tended to fire if the Arduino was not pulling it low. This would happen during reboot and other scary times. The wiring was also quite a pain. There were no connectors for the limit switches so you had to directly solder to the Arduino Nano.

I changed to use a custom PCB that is the entire rear panel. This contains all of the circuits including the limit switches. Building a Coasty was a little like building a ship in a bottle. Now the bottle has no bottom and there are less parts inside.

Front Door.

The front door now has a window. This makes the machine more fun to watch and no glasses are required.

Next Steps.

I have one build and am testing it for a while. If all goes well, I will release the source files and consider a kit.

 

PSoC 5 Daughter Card for XCC

I finished a PSoC 5 daughter card design for X-Controller-Controller project.  10 boards should arrive in about a week. This will clean up all the wiring from the breadboard testing I have been doing. My goal is to have a clean development platform for me and possibly others to work with.

The design has the following features.

  • Mounts CY8CKIT-059 dev board directly
  • Mates directly to the X-controller-Controller
  • Independent control of 4 axes.
  • Connector for X-Controller button panel
  • Connector for  X-Controller power supply PCB
  • Connector for a Serial LCD panel (Itead Studio Nextion style)
  • PSoC controlled stepper motor current.
  • PCoC controlled idle current.

Here is an image of the CYC8CKIT-059 development board.  The CPU is a PSoC 5LP.  The price is only about $10.  It comes with a built in programmer, debugger, and USB/UART. This can be snapped off.  To fit into the X-Controller, I snap off the programmer and mount it in another location.  The connections are made on the PCB.  I plan to use stackable headers so all of the pins are still easily accessible.

Links

Please subscribe to me on YouTube or follow me on Twitter.

 

Step Pulse Extender – PSoC Style

The TB6600 stepper drivers I have in the X-Controller have a “Torque” feature.  You set the motor current with a reference voltage and the torque feature allows you to easily switch between that current and 1/3 third of it. This is typically used for an idle current reduction feature at the system level.

tq_schm

Why Idle Reduction?

Stepper motors have a lot of hold torque, but that torque quickly falls off with speed.   Therefore you typically size a stepper motor and set the current for your maximum cut or rapid speed.  This means your motors will have excess torque when idle and will tend to run hottest at idle.  You basically the the current as high as possible until the motors get too hot.  If you could reduce the current at idle, you would reduce the temperature and could set the current higher than normal when spinning.

This is great, but the machine will never be in idle during a long job.  At least one of the motors should always be running. If you could figure out when each individual motor was idle, you handle each motor independently.  That is not easy in firmware, but there are tricks to do it in hardware.  You could tie the feature to the step pulse.  Whenever the step pulse is active, the full torque could be active.  That has two problems. The step pulse is extremely short, in the range of a few microseconds.  The other is you might want the current high for a a short bit after the motor goes idle just to make sure the machine is stable in the new position.

The trick is to use the step pulse, but extend it to the desired duration.  It should stay on through all the step pulses and extend the last pulse.

Discrete Hardware Solution

The X-Controller uses a discrete logic chip to do this. It uses a retriggerable monostable vibrator (74HC123D).  The R/C circuit on the right of the schematic snippet sets the duration. It works great, but this adds a lot of parts and things are locked down and not easily adjustable. If you needed to override this function, you have to break out the soldering iron.

PSoC Solution

With PSoC, when you hear “discrete logic” you should know there is probably a good way to do it on the chip. In this case I designed a custom component using verilog.

The verilog code is quite simple.  The best part is none of this is done on the CPU, so there is no impact on the motion control performance. What the video to see the details.

 

X-Controller-Controller (X-Controller minus controller)

MakeMag_0527

I am very happy with the X-Controller.  It packs everything you need to run Grbl into a clean little package.  It is super easy to hook up and move between machines. With that said, I had a quite a bit different idea in mind when I began the design.

The X-Controller was designed to be the motion controller for the X-Carve. The “X” in X-Carve was meant to signify that it was sold through a configurator and there were a lot of options. The X-controller was going to follow the same concept. It would support Grbl, Beaglebone Machinekit, Smoothy, and others. Additionally, alternate stepper driver PCBs might be developed.

To enable the configurability, the stepper driver section would be separated from the controller section. Every feature the stepper drivers supported would be available to the controller. The plug in controller PCB would control the features via firmware or jumpers and pots, depending on the power of the controller. The current X-controller has 4 stepper drivers, but (2) are wired together. In the split concept the controller card would decide how that was done.

At the time Easel was starting to get some real traction and Easel only supports the Grbl protocol. We decided that it was best to pick the easiest solution for our customers and make the X-Controller Grbl only.

My experiments in Beaglebone and PSoC have been such tangled messes of wires. I always wished I had that disconnected stepper PCB. I finally decided to make one.

xcc1

The XCC Stepper Driver PCB uses the same Toshiba TB6600 drivers as the X-Controller. It fits in the X-controller just like a stock PCB, but it is quite a bit shorter.  The interface side of the PCB has (1) 2×5 right angle header connector for each axis. Brought out the the connector are…

  • Step
  • Direction
  • Torque  (high=full current, low=1/3 current)
  • Enable
  • Micro-stepping selection
  • VRef (sets the motor current)
  • Ground and VMot

xcc2

 

For this version, I put a current selection pot and micro step selection jumpers for each axis to simply testing.  These function should be on the controller board, so most of these will be built without those installed.   The PCB also needs 12VDC to 40VDC power for the motors.  Each driver has a small 5VDC supply built in, so an external source is not needed.

xcc3

Here is a snapshot of the schematic.  This is just 1 of the 4 identical sections.

 

schem

Here is snapshot of the layout. I was able to get everything on 2 layers.

layout

 

It fits into the X-Controller great.  I used a small piece of black acrylic to fit the gap due to the shorter length.  It is working perfectly.  I have been testing it with my PSoC port manually wired in.  A PSoC5 controller will probably be the first controller card I will have made.

xcc4

xcc5

 

 

 

Yet Another Way to do the Kinematics

image1

Paul Kaplan, originator of the Easel project, came up with another way to do the kinematics for the Line-us Clone. My method used intersecting circles. His method uses the Law of Cosines.

The Law of Cosines relates the lengths of the sides of a triangle to the cosine of one of its angles.

Triangle_with_notations_2.svg

lawofcosines

 

This can be used to find the angles of the servo arms.

(Click on the images if you want a larger view)

The Goal

goal

The goal is to find the two angles, A1 and A2, of the servo arms

Known Values

  • Px is the desired X location of the pen
  • Py is the desired Y location of the pen
  • L1 is the length of the upper servo arm (50mm)
  • L2 is the length of the end of the Pen Arm (50mm)

Step 1

Find the distance “D” of the pen to hub using the Pythagorean Theroem and the angle T1 using arctangent.

Px2 + Py2 = D2

rewritten … D = Sqrt(Px2 + Py2)

step1

 

T1 can be found using the arctangent or inverse tangent formula. Note: When programming use the atan2(x,y) function to preserve the quadtrant.

T1 = atan2(Py,Px)

Step 2

step2

 

Find T2 using the Law of Cosines

L12 + D2 – L22 = 2 * L1 * D *cos(T2)

rewritten …  T2 = acos( (L12 + D2 – L22) / (2 * L1 * D))

Step 3

step3

 

Find T3 using the Law of Cosines. We want the left one of the two T3 angles, but since the linkages form a parallelogram that same angle shows occurs in several places.  We will use the right one and the dimensions associated with it.

L12 + L22 – D2 = 2 * L1 * L3 * cos(T3)

rewritten … T3 = acos( (L12 + L22 – D2) / (2 * L1 * L2))

Step 4

step4

 

Determine A1 and A2 from the angles we figured out.

A1 = T1 + T2

A2 = A1 + T3

Conclusion

I think I will switch the code to use this method. I think I can optimize it better in C code. The speed of the code is important.  The faster it runs, the most times per second we can run it.  The more often we run it, the smoother it will run.