A clutch player in the knifemaker’s shop, the tire hammer gives more control than other D.I.Y. power hammers.

Like a variable-speed hand drill, your backyard power hammer should be able to run slowly, at full speed or in between, depending on the task. The simplest way to guarantee it does this is to use a slipping clutch.

There are two main designs of slipping clutch. One uses a slack belt, a flywheel and pulleys. The drive pulley rotates within a slack belt. The foot pedal linkage pushes an idler wheel into the slack belt, increasing the belt tension to the point that the belt begins to turn the pulley on the flywheel.

Another design uses a tire clutch, where the foot pedal linkage pushes a drive wheel into an automobile tire, with the hub of the tire serving as the flywheel. The most common “tire hammer” design uses a similar clutch but turned the other way and connected to a linkage. Your available parts will dictate your design. 

Why A Clutch

A function of the clutch is to reduce the RPM of the motor speed to get the hammer rate of beats per minute (BPM) into a safe and useful range. You want the hammer rate to generally end up between 150 and 250 BPM, though many variables change with each hammer. In general, a heavier tup (aka hammer head assembly) requires a slower BPM, whereas a lighter hammer can have a higher BPM. You do not want your hammer running faster than you can control it, nor so fast that the inherent forces tear it apart. My hammer uses a 24-inch tire and a 3-inch drive wheel for an 8:1 reduction of a 1750 RPM motor, yielding a calculated 218 BPM at full speed. Your hammer will run differently depending on your motor RPM, your drive and driven wheel diameters, and the hammer’s overall design. I rarely run my hammer full speed during general forging work, and the tire clutch gives good speed control. Full speed works acceptably well for drawing out damascus billets or breaking down large stock.

My tire clutch has an integral flywheel bolted to the hub. On the flywheel I welded several different nuts for attaching the pitman arm (for more on the pitman arm, see part three last issue). Each nut is a different distance from the center of the hub. This allows me to vary the length of the stroke, in my case between 6.5, 7 and 7.5 inches, based on where I connect the arm to the flywheel. Coupled with an adjustable-length pitman arm, this setup allows a degree of tuning to get the hammer hitting in a way that transfers the power directly to the workpiece with efficiency, yet in a way that doesn’t place undue stress on the hammer itself.

Choosing A Motor For Your Tire Hammer

As for motors, the size may vary a bit depending on the overall tup weight of your hammer. For most homebuilt hammer sizes, a 1 or 1.5 HP motor is plenty. My 40-pound hammer uses a 1.5 HP motor running on 110v and does not trip a standard 15-amp breaker, suggesting that 1.5 HP is more than plenty for a 40-pound head. Whether the motor runs on 110v or 220v will depend on your shop setup and what you have available, but you’d be best served either way with a motor that runs in the 1700 RPM range, not one that runs in the 3400 RPM range. There’s no need to go three phase or variable speed unless you’re already set up for either.

You will need an on/off switch for your motor. To run the hammer, turn the motor on, then use the foot pedal linkage to engage the clutch.

Sourcing Dies

Most power hammers have a set of dies in between the anvil and the hammer shaft. Dies may be built in a variety of shapes and sizes, depending on how you want your hammer to move the metal. Two basic die designs are flat and crowned. Flat dies move the metal somewhat equally in all four directions, while crowned dies will draw out the length of your workpiece perpendicular to the crown on the dies. Some smiths design their hammers to accommodate various top or bottom tools, or spring swages as well.

On my personal hammer, the dies are built out of 1.5-inch square 4140 steel bar stock, heat treated and ground essentially flat, with slightly radiused corners. Some hammers are set up with dies that are interchangeable but mine is not. Full disclosure: My die attachment is one point of weakness in my design. I ultimately welded my bottom die plate straight to the anvil, and I’ve had to reinforce the top die connection and re-weld it several times. Perhaps a more skilled welder could have done better!

Creative Necessity

I can’t emphasize enough the creativity necessary to build a functioning power hammer from scrap. It’s one thing to watch a YouTube video and think, “It must be nice to have a power hammer.” It’s another thing entirely to watch the same video and try to discern how the rocker arm connects to the center post, or how the tire clutch axle is set up.

At the time of my hammer build, there was an online gallery hosted in Czechoslovakia that had hundreds of pictures of various homebuilt and factory built hammers. I couldn’t have built mine without those examples. I don’t speak Czech but the pictures tell the story well.

Read More On Power Hammers:

In April, Microsoft announced that it would stop selling Microsoft-branded computer peripherals. Today, Onward Brands announced that it’s giving those discarded Microsoft-stamped gadgets a second life under new branding. Products like the Microsoft Ergonomic Keyboard will become Incase products with "Designed by Microsoft" branding.

Beyond the computer accessories saying "Designed by Microsoft," they should be the same keyboards, mice, webcams, headsets, and speakers, Onward, Incase’s parent company, said, per The Verge. Onward said its Incase brand will bring back 23 Microsoft-designed products in 2024 and hopes for availability to start in Q2.

Incase also plans to launch an ergonomic keyboard that Microsoft designed but never released. Onward CEO Charlie Tebele told The Verge that there’s "potential" for Incase to release even more designs Microsoft never let us see.

Licensing deal

The return of Microsoft peripheral designs resurrects (albeit in a new form) a line of computer gear started in 1983 when Microsoft released its first mouse, the Microsoft Mouse.

Neither Onward nor Microsoft shared the full terms of their licensing agreement, but Onward claims that Incase will leverage the same supply chain and manufacturing components that Microsoft did, The Verge noted.

"Microsoft will still retain ownership of its designs, so it could potentially bring back classic mice or keyboards itself in the future or continue to renew its license to Incase," The Verge reported, pointing out that Onward isn’t licensing every single one of Microsoft’s computer peripherals. Some classics, like the Intellimouse or its modern iterations, for example, don’t make the Incase reboot list.

For its part, Microsoft is still "convicted on going under one single" Surface brand, Nancie Gaskill, general manager of Surface, told The Verge.

That said, in Microsoft’s old designs, Incase, whose website is currently filled with backpacks, bags, and laptop and AirPod cases, suddenly finds itself selling keyboards, mice, and other peripherals. Onward’s other brands, Griffin, Incipio, and Survivor, also don’t sell the types of products that Incase is licensing here. If all goes well, Incase could build its own computer accessories portfolio.

Microsoft’s initial departure from Microsoft-brand peripherals meant it would only focus on more expensive, higher-end designs worthy of Surface branding. But that left a gap for the numerous users who felt satisfied with Microsoft’s various designs that were simpler and more affordable. Incase’s venture could help serve those customers, while Microsoft’s legacy with such products can continue without major investment from the tech giant.

Here’s a full list of the Microsoft-designed peripherals that Incase plans to bring back in 2024:

Keyboards

• Bluetooth Keyboard
• Bluetooth Number Pad
• Designer Compact Keyboard
• Ergonomic Keyboard
• Sculpt Comfort Desktop
• Sculpt Ergonomic Desktop
• Sculpt Ergonomic Keyboard
• Wired Desktop 600
• Wired Keyboard 600
• Wireless Comfort Desktop 5050 AES
• Wireless Desktop 850
• Wireless Desktop 900

Mice

• Bluetooth Ergonomic Mouse
• Bluetooth Mouse
• Mobile Mouse 1850
• Modern Mobile Mouse
• Sculpt Ergonomic Mouse

Audio

• Audio Dock
• Modern USB Headset
• Modern USB-C Headset
• Modern USB-C Speaker
• Modern Webcam
• Modern Wireless Headset

In this tutorial, we’ll create a Laravel application that interacts with an external API to fetch and display a paginated list of posts. We’ll also implement buttons that trigger delete and update calls to the external API. Calling external APIs allow us to integrate with any third parties that exposes their functionality accordingly.

Note the data will be fetched externally but the updates and deletes will be simulated since the test API (jsonplaceholder.typicode.com) we’re using is read-only.

We will be using the Laravel built-in Http facade to send the API calls. While you could also use Guzzle to do this, using the Http facade is the recommended way to go about it. Using the Http facade offers a concise syntax that is in line with Laravel and adds more features like mocking HTTP responses for automated testing.

Let’s get started!

Step 1: Set Up Your Laravel Project

Create a new Laravel project or use an existing one:

laravel new blog-cms
cd blog-cms

Step 2: Create Controller

Create a controller by running:

php artisan make:controller PostController

Step 3: Add Controller Code

Now let’s add code to the PostController to implement methods to show, update, and delete posts by triggering calls to the external posts API:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;

class PostController extends Controller
{
 public function index()
 {
 $response = Http::get('https://jsonplaceholder.typicode.com/posts');
 $posts = $response->json();

 return view('posts.index', ['posts' => $posts]);
 }

 public function edit($id)
 {
 $response = Http::get('https://jsonplaceholder.typicode.com/posts/' . $id);
 $post = $response->json();

 return view('posts.edit', ['post' => $post]);
 }

 public function update(Request $request, $id)
 {
 // Simulates update logic for a real application (not supported by this API)
 $response = Http::put('https://jsonplaceholder.typicode.com/posts/' . $id, [
 'title' => $request->input('title'),
 'body' => $request->input('body'),
 ]);

 // Simulated response for successful or failed update
 if ($response->successful()) {
 return redirect()->route('posts.index')->with('success', 'Post updated successfully!');
 } else {
 return redirect()->route('posts.index')->with('error', 'Failed to update post. Please try again.');
 }
 }

 public function destroy($id)
 {
 // Simulates deletion logic for a real application (not supported by this API)
 $response = Http::delete('https://jsonplaceholder.typicode.com/posts/' . $id);

 // Simulated response for successful or failed deletion
 if ($response->successful()) {
 return redirect()->route('posts.index')->with('success', 'Post deleted successfully!');
 } else {
 return redirect()->route('posts.index')->with('error', 'Failed to delete post. Please try again.');
 }
 }
}

Step 4: Define Routes

Define routes for post actions in routes/web.php as follows:

use App\Http\Controllers\PostController;

Route::get('/', [PostController::class, 'index'])->name('posts.index');
Route::get('/posts/{id}/edit', [PostController::class, 'edit'])->name('posts.edit');
Route::put('/posts/{id}', [PostController::class, 'update'])->name('posts.update');
Route::delete('/posts/{id}', [PostController::class, 'destroy'])->name('posts.destroy');

Step 5: Create a Base Layout

Let’s use a simple layout that is based on bootstrap 5 that can show any content along with any success or error message that may occur. Create a file resources/views/layouts/app.blade.php and add:

<!DOCTYPE html>
<html lang="en">
<head>
 <!-- Other meta tags -->
 <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet">
 <link href="https://cdn.jsdelivr.net/npm/bootstrap-icons/font/bootstrap-icons.css" rel="stylesheet">
 <!-- Other CSS -->
</head>
<body>

 <div class="container mt-4">

 <!-- Display success or error messages -->
 @if (session('success'))
 <div class="alert alert-success">
 
 </div>
 @endif

 @if (session('error'))
 <div class="alert alert-danger">
 
 </div>
 @endif

 @yield('content')

 </div>
</body>
</html>

Step 6: Create a View to Show Posts From API

Generate a Blade view to display the paginated list of posts. Create a file resources/views/posts/index.blade.php and add:

@extends('layouts.app')

@section('content')
 <div class="container mt-4">
 <h1>Posts</h1>
 <div class="table-responsive mt-3">
 <table class="table table-striped">
 <thead>
 <tr>
 <th>Title</th>
 <th>Body</th>
 <th>Actions</th>
 </tr>
 </thead>
 <tbody>
 @foreach($posts as $post)
 <tr>
 <td></td>
 <td></td>
 <td>
 <div class="d-flex">
 <a href="" class="btn btn-sm btn-primary me-2">
 <i class="bi bi-pencil"></i>
 </a>
 <form action="" method="POST">
 @csrf
 @method('DELETE')
 <button type="submit" class="btn btn-sm btn-danger">
 <i class="bi bi-trash"></i>
 </button>
 </form>
 </div>
 </td>
 </tr>
 @endforeach
 </tbody>
 </table>
 </div>
 </div>
@endsection

Step 7: Create Blade View for Edit Post From API

Create a Blade view for the post edit form in resources/views/posts/edit.blade.php. Include the form with populated data, the correct action/route, and @csrf:

@extends('layouts.app')

@section('content')
 <div class="container mt-4">
 <h1>Edit Post</h1>
 <form action="" method="POST">
 @csrf
 @method('PUT')
 <div class="mb-3">
 <label for="title" class="form-label">Title</label>
 <input type="text" class="form-control" id="title" name="title" value="">
 </div>
 <div class="mb-3">
 <label for="body" class="form-label">Body</label>
 <textarea class="form-control" id="body" name="body"></textarea>
 </div>
 <button type="submit" class="btn btn-primary">Update</button>
 </form>
 </div>
@endsection

Step 8: Test the Application

Run your Laravel server using php artisan serve and navigate to http://localhost:8000 in your browser. You’ll have a paginated list of posts with functional delete and edit buttons, and an edit form ready for updates.

Note: The buttons will work to show edit form and trigger updates as well as deletes calls to the external API. However, the data in the API will not actually change since it is a public read-only API made for testing purposes.

Conclusion

Good job! You’ve successfully created a Laravel application that fetches and displays posts from an external API. You’ve also added buttons to delete posts and update by sending the respective API calls from your controller. I’ve also covered some basic error handling that redirects with either a success or an error message whichever applies.

While the placeholder API I showed here is read-only and the edits and deletes have no effect on the data, the principle is the same for a real API.

With this knowledge you can go ahead and start integrating real-world REST API’s into your Laravel application. Happy coding!

References: