HeyLaughingBoy

Exactly! It might be a "dangerous fallacy" (?) but people will still do it and you can't stop them.

I think you might be surprised to find out how many "real businesses" can't "just reinvest capital" and have to keep struggling on with what they have.

I'm going to forget some details, but he was not using hobby level CNC products. I still have a Kollmorgen AKD motion controller that he sent me as a test bench. Most of the old tools were using 0-10V sawtooth analog outputs for motor position and, IIRC, their preferred controllers didn't support that. The initial version of the box I made took that 0-10V and pretended to be a resolver so the AKD could control the motor.

Like I said, I don't remember all his design decisions, but they wanted to retain the original position sensors.

Have you ever written online about your projects? This stuff is endlessly fascinating to me. And your suggestion about a webcam makes me think about a problem a client and I had a couple of years ago that was never solved. It would be a completely controlled visual environment, so an ESP-cam just be the ticket if he's still interested.

Thank you for posting this, it reaffirms what I've been thinking for so long. There are many opportunities to retrofit old systems of all types with modern low-cost embedded technologies.

Around 2019 or so I was approached by an engineer who had a small business retrofitting very old machine tools with modern motion controls. Think very large lathes and planers. The problem they had was that in order to get these systems working with newer controls, they had to make time-consuming modifications to the old machines, in some cases modifying the axis motors and that cost added up quickly. The engineer realized that it was theoretically possible to take the old analog position signals and convert them into something a modern motion controller could read. That converter box would make the retrofit pretty much plug & play, but he didn't have the programming expertise to make it happen.

We probably built the first iteration of the converter for under $50 in parts and less than 50 hours of development time. That had me searching for other similar opportunities. I have found a few, but they tend to be one-offs that aren't worth the time unless you're already building something similar. Either that or my ability to see opportunity sucks!

If you're interested in the day to day of where the hobby goes, I recommend a browse around /r/projectcar. It's a mix of first time builders, people thinking of getting started, and the old hands doing some absolutely amazing builds.

That sounds odd. The way it was done in every place I worked, is that a set of changes were approved for a release before they were planned and implemented. We organized the work as expected: each bug/feature on its own branch, with its own set of unit tests, etc., and automated testing applied on each commit. These branches are then merged to the integration branch once they are known good. Before the release process starts, QA would get a copy of the integration branch and test that.

The dependency problem doesn't exist, because all the features were already approved to be in the release. The only way there would be a problem is if someone decided late in the game to pull a feature and that feature was a dependency to something else.

So, the fix to one bad regulation is another one?

ROFLMAO

Not all buyers are using loans. First house I sold was to someone who refused title insurance because in his words, "that house has been sold 3 times in 10 years, the title's fine."

As an aside, I'm told that Title companies make absolute bank. Most buyers get title insurance, but the insurer very rarely ever has to make a payment.

Aren't they already on Terra, or did I miss something?

The problem is that everyone is having that idea at the same time! Posts on /r/embedded asking a related question keep being shut down because there are so many web developers now asking daily how they can get into embedded systems because of a perceived lack of LLM penetration.

No such thing! Companies that aren't already actively using AI for embedded development are looking closely at it and experimenting with procedures to incorporate into their workflow. Why anyone would think that a company would ignore a potential improvement to their bottom line is beyond me.

Yeah, it might take a while, but it will happen faster than you think.

TIL. Thanks!

Custom machine building is a very difficult business to be in. As you mentioned, it's hard to scale. I knew of a particular service provider (custom motion systems) whose philosophy was to break even on the first job and profit on any followups.

There are many, many, many solutions like this on YouTube from all over the world. I have to admit that there do seem to be more Russian ones than anyone else, but maybe they're just better at posting video. I've seen an insane amount of homebuilt tractors and offroad vehicles coming out of russia.

Not avionics, but I've spent most of my career in medical devices. A project's Design History File would indeed have the detailed design documentation of the system. The problem would be that word "detailed." The relevant standards state that the documentation should be sufficient for a normally-skilled engineer to recreate the (software) system, but how stringently that is applied can be very hand-wavy. And then there's the problem of drift where the software changes and the docs are updated, but perhaps not as precisely as they should be, and different people have different levels of documentation rigor. Well, you can see how it ends up 20 years later.

I'm actually dealing with exactly this problem on an old project right now :-(

> conformal coating (which I hate for reverse-engineering), which is usually omitted from prototypes

Bad memory from a couple years ago. Debugging a machine under development at a customer site, which was luckily only a few blocks from the office, since I was there a lot, I would get random resets, hangs, and loss of debug information from the SWD probe. Swapping boards, debug probes, nothing we could think of fixed it and it was so random it was hard to track down.

Long story short, after it happened on one occasion when the project EE was also debugging something and he touched one of my probes, we found that there was conformal coat residue on some of the debug pins and the probes would occasionally vibrate onto an insulated section, causing loss of signal.

No idea why the board house put it on a prototype, but we probably lost a few dozen hours due to that one problem.

How did you power it?

It's been long enough ago that I don't use it as an interview answer anymore, but one of the most interesting things I built (technique-wise) was a Z-80 based serial multiplexer with no RAM. The only volatile memory it used was the device registers. The fun part was handling subroutine calls without a stack. The Z-80 has an indexed jump mode, so before calling a subroutine, I'd fill the jump register with the statement after the subroutine call, and when the subroutine was done, execute the jump with the (return) address prefilled.

Anything to save a few bucks on a 6264 SRAM component :-)

Really? that's a bit over 30 miles each way. It doesn't sound at all unusual to me.

People move around: that's what cars are for. Trucks may not be "designed for urban areas" (whatever that means), but they certainly go into them on a daily basis.

With a range of 77 miles, I wouldn't make it to work and back. Everyone I know (yes, it's anecdotal, but a widely-shared one) has to commute on roads where the average speed is well above 30mph.

This is a non-starter for the US.

For a significant segment of the US population, that thing wouldn't get them to work and back, so they'd have to charge it both at home and at work. And in many cases, forget running any errands, picking up kids from daycare, etc.

And minimum speed on US interstates is typically 40mph, so that reduces its usability even more.

I remember your blogabond posts from way back when on HN. I think you were the first to really popularize the "coding while traveling" idea.

It's very dated by now, but The Control System Design Guide by George Ellis is a pretty good hands-on book about designing and analyzing control systems. It goes well beyond the basic PID stuff, but I found it very helpful when I was getting a Mechatronics certificate 20+ years go. TBH, it's the most accessible book on the subject that I've ever read.

> we will replace most PIDs with a small neural network for almost all industrial applications

A similar argument was made in the early 90's/late 80's for using Fuzzy Logic (https://en.wikipedia.org/wiki/Fuzzy_logic) instead of classical control algorithms, including PID.

I'm sure many here will remember the late Bob Pease of National Semiconductor writing articles[1] against this, mainly due to the inability of the designer to predict the behavior of the system. Believe it or not, being able to logically reason about how an algorithm that's controlling tens of thousands of $$$ of product in process is actually important.

[1] https://www.electronicdesign.com/technologies/embedded/digit...

A lot of this is simply due to environment that they live in.

When I was in nautical school, I was taught to always be aware of sea state regardless of where I was/what I was doing so I'd get in the habit of always knowing what the sea was doing.

Now I live on a farm. We are always very aware of the weather and instinctively comparing what we see around us to what the forecasts say.

When I lived in a city, I was barely aware of even if it was supposed to rain later or not. Going from your climate-controlled house to your climate-controlled car, to your climate-controlled job, you simply don't notice those things except superficially.

Maybe they learned from the aliens?

LOL. 1987 is just about when I stopped using emacs. Suddenly, I feel really old...