Archive Page 2

Coasty the Coaster Toaster

Overview

This is a just a silly little project that can only do one thing. It laser etches or cuts drink coasters.

I was interested in learning Grbl’s new laser features, so I bought a small laser module. We have a monthly-ish Hardware Happy Hour meetup in Chicago. We drink beer and show off our projects. My typical projects are big motion control/CNC stuff, so for the first few meetups, I could not bring anything. I challenged myself to design something interesting for each meetup. Here are my criteria…

  • Must fit in a commuter sized backpack.
  • Must be battery or USB powered.
  • Can only scare the bar staff a little.
  • Learn something new.

Parts

Most of my design choices were based on materials I had left over from other projects. The parts I needed to buy for this project were these…

  1. ($99) 3.5 watt / 2.5 watt continuous laser module with power supply
  2. ($26) Small 2 axis motion controller.
  3. ($9) A backlash resistant leadscrew nut. (small size/diameter was important)
  4. (($10 for 50) O-Rings for the drive wheels.

 

Enclosure

The enclosure is 3D printed in 2 parts. The chassis is quite complex, but prints easily without support. It should fit on most printers. It takes about 12 hours on my Taz 6. The second part is a simple hinged door.

X-Axis

The required width was hard too reduce too much.  You are stuck with the width of the coaster and the width of the laser module.  The beam is in the center of the module, so you need room for the rest of the laser module to fit within the width as it travels to the edges.

I tried the design with the motors inside the box with belts. Getting the motor pulley, the idler pulley and a belt attachment method into that minimum width was not working out well. I decided to use a Tr8-8 lead screw instead with the motor outside the case. A tr8-8 is pretty common and easy to buy. It is 8mm diameter it is 2 mm pitch with 4 starts (independent threads) so this will cause a travel of 8mm per turn.

The linear bearing uses (2) 8mm rods and 2 double wide ball bearings. The leadscrew attachment was a bit of a hack. I drilled a hole down the center of one end and epoxied it to the inserted motor shaft.

Y-Axis

The Y axis uses feed rollers to move the coaster.  This allowed me to make the machine smaller in depth than the coaster. A 1″ O.D. x 1/8″ rubber oring is driven by a large axel. The coaster runs over some small bearings where it is pinched by the o-ring. The coaster slides over a large platform.  This allows it to drag along cutouts pieces pretty well.

Z-Axis

The nice thing about limiting it to printing coasters is that you only need to deal with 2 axes. The focus length never changes. No Z provisions required.

Home Switches

Each axis has a home switch.  The Y home switch is triggered by the top coaster as it slides in.  The X home switch is triggered by an adjustable screw on the X carriage.

Electronics

I used a super cheap 2 axis CNC controller called the EleksMaker Mana SE. It uses 2 stepstick stepper drivers and a Arduino Nano. Both of those items were included in the price. It is designed to run Grbl for simple pen plotters, egg bots and lasers. It can control the laser via PWM and also has a servo connector. The board is not open source, so it was a little tricky to figure some things out. I’ll do some future posts about all the details.

I also added 2 fans. The laser generates a bit of smoke while cutting the coasters.  The fans wisk it out the back.

I need to measure the current better, but the values below are a good estimate.  The controller has a switch on the 12V that turns almost everything off, but the Arduino will stay on while plugged into USB.  I typically turn off the 12V after each job. I want to make sure the laser never fires accidentally between jobs.

  1. 2 amps peak when cutting at full power
  2. 0.3 amps when idle.

Software

I tried several things, but ultimately settled on Laser Grbl.  It is open source and quite simple. It is written in C#, so it is windows only. I was able to easily recompile it and try a few tweaks.

A full cut through job like the “Coasty COASTY” coaster takes about 4-5 minutes. I run at about 250mm/min for those. For bar use I think it is quicker just to do outline engraves.  I run at about 1000-1200 mm/min for those and they typically take less than a minute. Full solid engraves are pretty smoky and take a long time.

Safety

I have no idea if this is safe, so I supervise its use pretty closely.  The chassis and cover block direct viewing of the beam unless you really try to peer into some holes at sharp angles.  The vents on the door angle so you can’t see through them. There is always the chance the coaster could catch fire, but that is not a lot of fuel. The cover is not interlocked, but it does bolt shut. Most DIY lasers like this are just run in the open.

Future

Here are some things I am thinking about.

  • Add another row of drive wheels on the other side of the laser.  This should increase the work area if the coaster transfers from one set to the other to get to the top and bottom edges. I would also like to reduce the diameter of them to make the machine a little smaller in depth.
  • Cover the electronics.  The electronics are a little vulnerable to damage and not quite ready to be tossed into a backpack.
  • Add a filter to reduce the smoke smell.  I bought a big sheet of carbon filter material. I would like to test it’s effectiveness.
  • I would like to try some new ideas for a belt driven X axis.  It would run faster and quieter. I think I could put the motor on the side like the Y motor. Currently drilling out the center of the TR8-8 leadscrew is requires a lathe.
  • When cutting through something the laser energy has to be blocked by something.  Right now there is a thin metal strip under the coaster where the beam goes. I would like to try moving the strip to the bottom of the device further away from the focal point.  The beam would eventually cut a thin  line through the enclosure until it hits the metal. The thinnest interruption in the base in best for dealing with cutout pieces. The beam will have some distance to diverge before bouncing off the metal.

Automatic Tool Changer Logic

I have been working on adding Automatic Tool Changer (ATC) functions to Grbl (more on that soon).  First, I wanted to put in some basic safety logic that will not allow the ATC to open when the spindle is on or even spinning down. If that were to happen it could be dangerous and it would damage the ATC. By “logic” I mean logic gates outside of the firmware.  This would backup the firmware and prevent a bug or weird state from activating the ATC. This is quite easy with a custom component in PSoC.  This logic will still function if the firmware has a bug, the firmware locks up, of even while stopped during debugging.

Right now I have 2 signals I can work with. One is the enable signal going to the spindle. The other is the output that signals the ATC to open.  Eventually I would also like to incorporate a tachometer signal from the spindle, but I don’t have a spindle with a tachometer yet.  The logic is relatively simple.  If the component sees that both signals exist at the same time, it will disable both and raise a fault signal. To prevent any timing issues I will also incorporate a spindown delay with the spindle and a shorter ‘settling’ delay for the ATC air valve. Under normal conditions it simply passes the spindle or ATC signals to the outputs.

Here is what the component looks like in PSoC creator.

Inputs

  • Spindle_In: The spindle enable signal goes in here.
  • ATC_In: The signal to open the ATC goes here.
  • Clock: This is used to count down the spindle spindown and ATC settling time.
  • Reset: In a fault condition, this is used to reset the fault.
  • Parameters:
    • Spindown: How many clock cycles will be used for the spindown.
    • ATC Settle: How many clock cycles will be added after the ATC is closed before the spindle can turn on..

Outputs

  • Spindle Out: The spindle enable signal will come out here.
  • ATC Out: The ATC open signal will come from here and go to the pin for this.
  • Fault: If anything goes wrong, this will go high.  It would typically connect to an interrupt.  This must be cleared with a reset.

Test Circuit

I tested this out on a CY8CKIT-001 with a PSoC5 module installed. This made it easy to connect to switches to simulate the input signals and LEDs to easily view the output signals.

Note: In the test there is only one line of firmware. It initializes the PWM component. The rest is done in discrete logic.

  • There is a switch to to simulate the spindle output from the firmware.  This goes through a not because it switches to ground on this dev board.  It then splits to turn on the PWM and go to the ATC_logic component. This simulates Grbl’s Spindle enable and Spindle PWM signals. The PWM was set with a 10% duty cycle so the dimmer output is easily noticed.
  • There is a switch for the ATC signal.
  • There is a switch to reset the component if if latches with a fault.

 

Here is a picture of the setup.

Here is a video of the testing.

Here is the Verilog code for the component.


//`#start header` -- edit after this line, do not edit this line
// ========================================
//
// Open Source Creative Commons 4.0 Attribution, Share Alike. 
//
// ========================================
`include "cypress.v"
//`#end` -- edit above this line, do not edit this line
// Generated on 06/15/2017 at 18:36
// Component: atc_logic
module atc_logic (
	output  reg ATC_out,
	output  reg fault,
	output  reg spindle_out,
	input   ATC_in,
	input   clock,
	input   reset,
	input   spindle_in
);
	parameter atc_settle = 3;
	parameter spindown = 10;

//`#start body` -- edit after this line, do not edit this line

//reg spindle_enable;
    
    reg [15:0] atc_count;
    reg [15:0] spin_count;
    reg [1:0] latch;
    
    //assign spindle_out = spindle_in & spindle_enable;
    //assign spindle_out = spindle_in;
    
        
    always @(posedge clock or posedge reset)    
    begin
        if (reset)
            begin
                latch = 0;               
            end
        else if (   ((ATC_in  || (atc_count > 0))     &&     (spindle_in || (spin_count > 0))) || latch   )
            begin
                ATC_out = 0;
                spindle_out = 0;
                fault = 1;
                latch = 1;
            end
        else
            begin
                fault = 0;                
                
                if (spindle_in)
                    begin
                        spin_count = spindown;
                        spindle_out = 1;
                    end
                else if (spin_count > 0)
                    begin
                        spin_count = spin_count - 1;
                        spindle_out = 0;
                    end
                else
                    begin
                        spindle_out = 0;
                    end
                
                
                    
                if (ATC_in)
                    begin
                        atc_count = atc_settle;
                        ATC_out = 1;
                    end
                else if (atc_count > 0)
                    begin                
                        atc_count = atc_count - 1;
                        ATC_out = 0;
                    end    
                else
                    begin
                        ATC_out = 0;
                    end
                
                
            end
            
    end    

//`#end` -- edit above this line, do not edit this line
endmodule
//`#start footer` -- edit after this line, do not edit this line
//`#end` -- edit above this line, do not edit this line

 

 

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

 

 

 

6 Axis Grbl Port on PSoC

If you have done any extensive poking around the Grbl source code you will eventually come across this line in nut_bolts.h.

#define N_AXIS 3 // Number of axes

It would be so easy to just change that to 4 or 6 and have some fun, right?  No, unfortunately it is not that easy.  With a little work though, it is not too hard to add those extra axes to Grbl. I decide to try this with my PSoC port of Grbl.

ABC Axes

Typically the axes after X,Y, and Z are labeled A,B, and C and are often rotary axes. Here is a simple 4th rotary axis.

4axis

Things get more complicated when you add more axes.  Here is an example of a 5 axis upgrade for a 3 axis machine.

aaxis

N_AXIS

While simply changing N_AXIS does not suddenly make the extra axes work, it does do a lot of the work. I found it used over 80 places in my port.  It will do virtually all of the major code work.  I just needed to do the following…

  • Read the ABC parameters in the gcode.
  • Add additional $$ settings for steps/mm, speed and acceleration for the A, B, and C axes.
  • Add homing code for A,B, and C.
  • Adds some #define statements to make it easier to configure between the axis counts.

As I was working on this I stumbled upon a few other people working on this.  This code I found was especially helpful.

Configuring I/O

Grbl uses 1 byte byte each for axis step, direction and limits switches.  Those bytes are used with a mask (to say with bits are actually used) and applied directly to an I/O port.  This is a very efficient way of doing it, but it forces you to put all axes on one I/O port for each of the step direction and limit switch functions.

My port to PSoC uses Control Registers to output the step and direction signals and Status Registers to read the limits switches.  These registers can be ‘wired’ directly to I/O pins.  There are several advantages to this, but the main ones in this context are, you don’t need to map them to the same I/O port and you only have to connect the ones you want to use.  Here I have defined all 6 bits on the Control Register, but have only connected the I/O pins I am using.

controlregister

 

To make the PSoC port easier to maintain as Grbl changes, I did not change the Grbl method to much.  The mask is still applied, but the mask is hard coded.

The homing switches work in a similar fashion. Here is a 4 axis setup.

limits

EEPROM

The storage of the steps/mm, speed, and acceleration will increase the amount of EEPROM required.  The PSoC has plenty, but keep in mind every time you change the axis count, you will need to reset the EEPROM because the locations will get shuffled and the restore from EEPROM will not work the first time you start under the new axis count.

Status

The status is going to report the extra axes, so I assume it will break a few senders.

?
<Idle|MPos:1.680,4.568,-0.900,0.664,0.428,0.984|FS:0,0>
ok
$#
[G54:0.000,0.000,0.000,0.000,0.000,0.000]
[G55:0.000,0.000,0.000,0.000,0.000,0.000]
[G56:0.000,0.000,0.000,0.000,0.000,0.000]
[G57:0.000,0.000,0.000,0.000,0.000,0.000]
[G58:0.000,0.000,0.000,0.000,0.000,0.000]
[G59:0.000,0.000,0.000,0.000,0.000,0.000]
[G28:0.000,0.000,0.000,0.000,0.000,0.000]
[G30:0.000,0.000,0.000,0.000,0.000,0.000]
[G92:0.000,0.000,0.000,0.000,0.000,0.000]
ok

Sending the GCode is pretty easy, but I don’t know of any basic gcode senders that support more than three axes.

My personal sender uses regular expression to do the basic parsing of the status. This is a robust way to to handle status that can change formats as long as it is predictable.   I send the position data to a function that splits it into a string array.  I’ll just need to add some DROs for the extra axes if it detects them.

Testing

I don’t have a 4 or 6 axis CNC, so I built a little test rig with 6 axes.  I used a Gecko G540 and 2 single axis drivers.  Each stepper has it’s own home switch triggered by a cam on limit switches with roller actuators.  This allows the switches to be triggered , but allows the steppers to run continuously in either direction.  The homing sequence is quite fun to watch. Building this test rig took about as much time as the firmware changes.

testrig

 

Here is a YouTube video of it.

Next Steps

I want to do a lot of testing, then build a machine to do some real world testing.  I currently don’t have any decent CAM software over 3 axes, so I will need to deal with that. I will then add it to my GitHub repo for this.

 

Lost PLA Casting

cast2

We recently did some aluminum casting at the Inventables Beer and Making night. The primary mission was to do some lost foam casting, but I wanted to try lost PLA.

Beer and Making is typically a gonzo/hackathon type event, so we deliberately try to use materials on hand and try to learn for ourselves. We used pink insulation foam because it could be easily hand carved during the event. This was the first time for everyone, so I was quite happy with our success.  I’ll point out some areas where we probably could have done better.

The furnace

One of the perks of working at Inventables is our personal Exploration and Project budgets.  We all get a budget for personal exploration and making things. The furnace was recently purchased by Jon, one of the fulfillment team members, with some of his budget. This furnace runs off standard 110V and can heat the material up to 1150°C.  We set it for about 1000°C for the aluminum.

furnace

 

The Model

sprues

 

The model I used is the unofficial mascot for the CNC build Club, the CNC Ninja Squirrel.  I tried to use as little PLA as possible.  I used 2 perimeters and 5% infill.  There are a few steep overhangs, so I typically need at least 2 perimeters for success with this model. I didn’t use any special filament, just the PLA was in the printer at the time.

The model will be buried in the sand.  You need to create a couple of channels (sprues) to reach the surface for the casting process.  The channels have several functions.

  • Provide a place to pour the aluminum.
  • Provided an escape path for the air and other gasses created when the material is burned out.
  • Provide a a source of aluminum for the part to draw from when it shrinks.

I created the channels from pink foam and hot glued them onto the PLA model.

The Sand

We used what we could find quickly.  We used about 9 parts of a play sand and pool sand mixture and 1 part of bentonite power (the Tait mix).  We added just enough water to make it clump a little.

The Setup

cast1

We got a large metal metal tray and put some dry sand on top.  This was a bit of a fire pit in case of any spills or fires.  You can see the size of the crucible in the foreground and the tongs that came with it.

We made a small enclosure out of MDF.  We filled it half way with the sand mix. We placed 3 items to cast in it.  We then covered the items in sand.  We added the sand slowly and packed it down with a rod at several levels.  We poured each of the 3 items with separate pours.  We wanted to make sure each item got a lot of aluminum.

We used scraps of MakerSlide as the aluminum to melt.  We cut the pieces to the length of the crucible.  We would add a piece at a time as they melted.  It took about 30 minutes for the first batch and about 10 minutes for the other batches.

Pouring

IMG_1722

The pouring was pretty exciting.  Some of the aluminum ran to the MDF sides and started a little fire.  We had a fire extinguisher ready, but simply put a cover over the box to kill the flames. Most of the flames you see in the image are the foam being burned away.

Results

We did three separate parts.  2 were foam and 1 was PLA.  The PLA probably had the best quality finish, but the part came out noticeably darker.  It was easy to clean up with a stiff wire brush.

Next Time

  • The first change I would make is to use something non flammable for to hold the sand.  I think a ceramic flower pot might be good.
  • Build up the sand around the sprues to keep the aluminum from spreading.
  • Cover the part in dry wall paste.  This creates a thin shell between the part and sand to get a better finish.
  • Get some better sand and a little fire clay to make a better sand mix.
  • I might try to model the sprues onto the part in PLA
  • Mark the in and out sprues, so you know what side to pour into.
  • The smoke and fumes were pretty nasty, especially the MDF.  Do this outside!

 

 

Digital vs. Analog Servos

wiggles

There is quite a bit of wiggliness on my drawing bot. While it is a bit adorable as it draws, I wanted to see if I could improve the line quality. I thought increasing the the rate at which I updated the position would make it smoother. I took it all the way up to 48Hz, but was not getting much better quality than I did at a 1/4 of that.

Analog Servos

I little research into analog servos brought some possible solution to light. Analog servos are controlled with a PWM signal.  The PWM pulse should be between 1ms and 2ms and repeat at 50Hz.

servo_timing

The basic technology inside an analog servo has been around longer than I have. The circuit converts the signal pulse into a voltage based on it’s length.  The output shaft is coupled to a potentiometer which also outputs a voltage. These two voltages are compared to produce an error voltage.  The error voltage would be positive or negative based on which direction off the output shaft potentiometer is from the input signal voltage.  This voltage is sent through an amplifier and then to the motor.  The motor turns in the proper direction until the error voltage is zero.

aservo

One problem with this method is the voltage to the motor is proportional to the error voltage.  The motor will have very little torque when the error is small, as would occur with small moves.

To keep the servo from being overly sensitive to small changes changes in the pulse length, the servos have a deadband.  Over sensitivity would cause jittering and use a lot of power. The deadband is expressed in microseconds (us). Analog servos typically have a 5us deadband. If the error is less than the deadband, the servo will not move.

If the servo pulse range is 1ms to 2ms or a 1000us range, then this causes the second problem. A  1000us range divided by the 5us deadband is 200.  This means I basically have to move more the 1/200 of the usable range to get it to move.  The full range is 180° so I have roughly 1° resolution.  That will cause lines to look very jittery.

Try this to get a feel for an analog servo.  With the servo receiving a commanded position, attempt to rotate the output.  You will notice two thing. First you will notice the strength of the servo is proportional to how far you twist it off the commanded position. The second thing to notice is noise and vibration.  That vibration is the 50Hz PWM period.

Digital Servos

Digital Servos use the same same basic input method (1ms to 2ms pulse) to preserve backward compatibility, but everything is done digitally.  Additionally, most of the servo’s parameters can be programmed. The digital circuit does not need to be limited to the 50Hz period and the control loop can be more sophisticated than simply using the error voltage.

The two immediate things I can take advantage of is lowering the deadband.  I can program it down to 1us or on some servos even lower. This give me a 5x improvement in resolution.  The other thing is the higher torque at small moves.

Try this to get the feel for a digital servo.  With the servo receiving a commanded position, attempt to rotate the output.  You will notice two thing. First you will notice the strength is very strong regardless of how far you twist it. The second thing to notice is noise and vibration.  That vibration is going to be a much higher pitch.

The results.

digital_wiggles

The results are subtle, but I think it is better.  With no changes to the firmware it got a little better.  I changed the update rate from 50Hz to 200Hz and it got a little better again.

I used Hitec HS5055MG servos.  I wanted a brand name servo, I know I could program.  Out of the box the servo only had about 90deg of rotation.  I was able to up that to about 178.  I was quite surprised I could not get 180°.  That needed to be accounted for in the kinematic or the shapes are distorted.

I think if you want the best, go for the digital, but in my opinion, the improment in quality did not justify the cost.

 

 

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.

 

Line-us Clone Controlled by Easel and Grbl

Last week I made a Line-us drawing robot clone.  Unfortunately I had no good way to make it draw easily.  I thought I would give the CNC toolpath a shot.  My goal is to have a super portable thing to generate conversation at meetups. If I used Easel it would allow anyone with a web connection to easily make something.

2dbenchy

Grbl

Grbl Logo 250px

The most compact machine controller is Grbl and I have a lot of experience with it.  Grbl is designed to send step and direction signals to stepper motors.  The draw ‘bot uses hobby servos.  The nice thing about hobby servos is they don’t need to be homed.  They have feedback to tell them where they are. They also don’t care about speed, acceleration or steps/mm.  They just go wherever you tell them as fast as they can go. It occurred to me, the easiest way to hack this into Grbl was to not modify the Grbl code at all.  I would let Grbl think it is using stepper motors.  I would just add some extra code that runs on regular interval to tell the hobby servos where the stepper motors are in 3D space and they would be told to go there.  I played around with some intervals and 8 times per second (8Hz) seemed to work pretty well.  The ‘bot uses machine coordinates. The work coordinates are offset to the left because the ‘bot cannot draw at 0,0.  The pen would crash into the frame.

PSoC

I recently port Grbl to PSoC. I used (3) 16bit PWM components to control the hobby servos.  See this blog post on how I did that.  I then attached a 8Hz clock signal to an interrupt.  The interrupt sets a flag when it is time to update the servos.  When the main code sees this flag it does the calculations and and sets the PWM values.  Keeping the code out of the interrupts gets Grbl happier.

servospwms

Easel

Easel is already setup to use Grbl.  You can either import gcode or create a design right in Easel.  I started out with importing gcode because the Benchy design was not in a format I could import. I created a template that shows the allowable work area. This will allow anyone to quickly create a drawing.

easel_template

2D Benchy

I wanted to have a little fun with the first print.  “Hello World” was not good enough.  3D printers use benchmark prints, so I thought I would do a 2D version of the classic 3DBenchy.  To get a 2D drawing of 3DBenchy, I traced over an image with the line tool in CorelDRAW.  I then exported a DXF of that.

trace