FreeCAD Is Near 1.0

The open-source parametric 3D modelling software, FreeCAD, is out in a release candidate for version 1.0.  If you’ve tried FreeCAD before and found a few showstoppers, it might be a good time for you to test it out again because the two biggest of them have been solved in this latest version.

First, version 1.0 finally implements a solution to the “topological naming problem”. Imagine you want to put a hole into a surface. The program needs to know on which surface to put the hole, and so it refers to this surface by name / number. Now imagine you subdivide the surface, and both subsections get new names. Where does your hole go now?  If you want to dig into the issue, the inimitable [MangoJelly] has a great video about the topo naming problem. Practically, there were workarounds, like only adding chamfers after the main design has stabilized, but frankly it was a hassle to remember all of the tricks. This is a huge fix.

The second big fix concerns assemblies.  Older versions of FreeCAD were great for making single parts, but combining them all together inside the CAD program was always janky.  Version 1.0 combines the previous two patchwork assembly workbenches into one, and it’s altogether more pleasant to use. The constraints of how two parts move when held together with an axle just works now, and this is a big deal for multi-part models.

If you’re coming from any other parametric CAD program, most of FreeCAD will seem familiar to you, but there will also be workflow differences that will take some getting used to. In trade, what do you get? Scriptability in Python, real open source software, and all of the bells and whistles for free. Now that its two biggest pain points have been addressed,  FreeCAD has become a lot easier to love. We’re looking forward to some good V1.0 tutorials in the future, and we’ll keep you posted when we find them.

The Surprising Effects Of Fast Food Kiosks

For as long as there have been machines, there have been fears of machines taking your job. One of the latest incarnations of this phenomenon is the fast-food ordering kiosk. No longer will you have some teenager asking you if you want fries with that. These days, you are more likely going to find the question on a touch screen. So, are those poor kids out of an entry-level job? Apparently not, according to a recent CNN story.

According to McDonald’s, a business that embraces the kiosks, the new technology increases sales and creates more jobs, albeit more jobs further behind the counter. Part of the reason is that while “Do you want fries with that” is a cliche, it is also a sound business practice. Cashiers should try to upsell but don’t always do so. The kiosk always remembers to offer you an apple pie or whatever else they want to move today.

Continue reading “The Surprising Effects Of Fast Food Kiosks”

When Raw Network Sockets Aren’t Raw: Raw Sockets In MacOS And Linux

Raw network sockets are a curious beasts, as unless you have a strong urge to implement your own low-level network protocol, it’s a topic that is probably best left to the (well-paid) experts. That said, you can totally use raw sockets in virtually every operating system, but one should be aware of a few things, the lack of portability being one of them. This is what tripped [Swagnik] up while trying to write a low-level network ping (ICMP) utility, by reading the Linux socket documentation while testing on MacOS. It’s all BSD-style sockets, after all, right?

As it turns out, the network stacks in Linux and MacOS have some subtle differences, which become apparent when you read the friendly manuals. For Linux, the raw(7) man entry for IPv4 sockets make it clear that the IP_HDRINCL socket option is default by default for IPPROTO_RAW sockets. This is different from MacOS, which is effectively FreeBSD with glossy makeup. Like FreeBSD, the MacOS man page makes it clear that the IP_HDRINCL option is not set by default.

So that’s easy, right? Just fire off a setsockopt() call on the raw socket and that’s done. Not quite. The Linux man page notes that it cannot receive all IP protocols, while the FreeBSD/MacOS version makes no such exceptions. There is also the issue of endianness, which is where [Swagnik]’s blog post seems to err. The claim is that on MacOS the received IPv4 raw socket header is in host (little endian) order, while the documentation clearly notes that these are in network (big endian) order, which the blog post also shows.

Where things get really fun is when moving from IPv4 raw sockets to IPv6 raw sockets, as [Michael F. Schönitzer] covered for Linux back in 2018 already. IPv6 raw sockets drop IP_HDRINCL and requires a whole different approach. The endianness also changes, as IPv6 raw sockets under Linux must send and will receive data in network byte order, putting it in line with FreeBSD raw sockets.

Linux, Now In Real Time

Although Linux runs almost every supercomputer, most of the web, the majority of smart phones, and a few writers’ ancient Macbooks, there’s one major weak point in the Linux world that will almost always have developers reaching for a different operating system. Linux is not a real-time operating system (RTOS), meaning that it can’t respond to requests in the real world within a set timeframe. This means that applications needing computer control in industry, medicine, robotics, and other real-world situations generally need a purpose-built RTOS. At least, that was true until recently when an update to the Linux kernel added real-time capabilities.

The feature, called PREEMPT_RT, forces the Linux kernel to respond to certain request within a set limit of time. This means that a system with this support built into the kernel can “preempt” any current task, stopping everything else a computer is doing in order to execute that task right away. There are some existing solutions to getting a functional equivalent system working with Linux now, but they can be clunky or inelegant, requiring the user to install patches or other software to get it to work. With the support built directly into the kernel this will become much less of a pain point for anyone who needs this functionality going forward.

This feature has been in the works for around two decades now, so with this entering general use now we would expect to start seeing it show up in various projects as well as in commercial offerings soon, especially since other RTOS solutions can be pricey. Don’t recompile the kernel in your desktop for this feature just yet, though; real-time function can cause some unintended consequences with normal use you’ll need to account for. There’s some more discussion on this in the /r/Linux subreddit and there are some other real-time operating systems available for computers not typically capable of running Linux to take a look at as well.

Jumperless Breadboard V5 Readies For Launch

When are jumper wires on a breadboard entirely optional? When it’s the latest version of [Kevin Santo Cappuccio]’s Jumperless, which uses a bunch of analog crosspoint switches (typically used for handling things like video signals) to create connections instead of physical wires. There’s even an RGB LED under each hole capable of real-time visualization of signals between components.

If this looks a bit familiar, that’s because an earlier version took second place in the 2023 Hackaday Prize. But things have evolved considerably since then. There are multiple programmable power rails, ADC channels, a rotary encoder, and much more. The PCB design itself is fantastic, including the probe which acts like a multi-function tool for interacting with the whole thing. The newest version will make its debut on Crowd Supply in just a few days.

It’s open source and made to be hackable, so give the GitHub repository a look if you want a closer peek. You can watch it in action in a brief video posted to social media, embedded below.

Continue reading “Jumperless Breadboard V5 Readies For Launch”

Against Elitism

A while back we got an anonymous complaint that Hackaday was “elitist”, and that got me thinking. We do write up the hacks that we find the coolest, and that could lead to a preponderance of gonzo projects, or a feeling that something “isn’t good enough for Hackaday”. But I really want to push back against that notion, because I believe it’s just plain wrong.

One of the most important jobs of a Hackaday writer is to find the best parts of a project and bring that to the fore, and I’d like to show you what I mean by example. Take this post from two weeks ago that was nominally about rescuing a broken beloved keyboard by replacing its brain with a modern microcontroller. On its surface, this should be easy – figure out the matrix pinout and wire it up. Flash in a keyboard firmware and you’re done.

Of course we all love a good hardware-rescue story, and other owners of busted Sculpt keyboards will be happy to see it. But there’s something here for the rest of us too! To figure out the keyboard matrix, it would take a lot of probing at a flat-flex cable, so [TechBeret] made a sweet breakout board that pulled all the signals off of the flat-flex and terminated them in nicely labelled wires. Let this be your reminder that making a test rig / jig can make these kind of complicated problems simpler.

Checking the fit with a 3D printed PCB

Once the pinout was figured out, and a working prototype made, it was time to order a neat PCB and box it up. The other great trick was the use of 3D-printed mockups of the PCBs to make sure that they fit inside the case, the holes were all in the right places, and that the flat-flex lay flat. With how easily PCB design software will spit out a 3D model these days, you absolutely should take the ten minutes to verify the physical layout of each revision before sending out your Gerbers.

So was this a 1337 hack? Maybe not. But was it worth reading for these two sweet tidbits, regardless of whether you’re doing a keyboard hack? Absolutely! And that’s exactly the kind of opportunity that elitists shut themselves off from, and it’s the negative aspect of elitism what we try to fight against here at Hackaday.

Steel Reinforcement Toughens Cracked Vintage Knobs

Nothing can ruin a restoration project faster than broken knobs. Sure, that old “boat anchor” ham rig will work just fine with some modern knobs, but few and far between are the vintage electronics buffs that will settle for such aesthetic affrontery. But with new old stock knobs commanding dear prices, what’s the budget-conscious restorationist to do? Why, fix the cracked knobs yourself, of course.

At least that’s what [Level UP EE Lab] tried with his vintage Heahkit DX60 ham transmitter, with pretty impressive results. The knobs on this early-60s radio had all cracked thanks to years of over-tightening the set screws. To strengthen the knobs, he found some shaft collars with a 1/4″ inside diameter and an appropriate set screw. The backside of the knob was milled out to make room for the insert, which was then glued firmly in place with everyone’s go-to adhesive, JB Weld. [Level UP] chose the “Plastibonder” product, which turns out not to be an epoxy but rather a two-part urethane resin, which despite some initial difficulties flowed nicely around the shaft collar and filled the milled-out space inside the knob. The resin also flowed into the channels milled into the outside diameter of the shaft collars, which are intended to grip the hardened resin better and prevent future knob spinning.

It’s a pretty straightforward repair if a bit fussy, but the result is knobs that perfectly match the radio and still have the patina of 60-plus years of use. We’ll keep this technique in mind for our next restoration, or even just an everyday repair. Of course, for less demanding applications, there are always 3D printed knobs.

Continue reading “Steel Reinforcement Toughens Cracked Vintage Knobs”