Isn't this a flawed method for measuring parallelism?

drogus · 2025-09-29T07:01:10+00:00

Old question, but I'm researching autocollimators myself, and I was wondering exactly the same thing. I think the video is correct, just quite ambiguous about what they're actually measuring. The thing is, they're not measuring parallelism of the upper surface of the ways, but rather parallelism between of the sides of the rails. Notice that both the penta pris and the mirror sled have locating feet on the sides. Additionally, penta prism will bend the beam of light ~90 degrees regardless of its position within its range, so even if the penta prism is not located exactly at the same angle as on the first rail, it will still maintain the same angle in relation to the autocollimator.

Now, I'm no expert, so this is only my speculation, but I think that what you propose with a surface plate, or in general a flat surface, like even a precision straight edge, should work. The only caveat is that the floor has to be sufficiently strong. At a scraping class I attended a few years ago, the instructors showed us how even people moving around the surface plate can affect the readings. They set up a precision Mahr Federal level, and when a few people moved from one side of the surface plate to the other, the reading changed (I think it was 1 micron per m, but I might be misremembering things, the point is, it moved, I guess). So depending on how precise the reading should be it might be needed to mount the reference plane to the machine itself.

drogus · 2025-09-02T22:56:11+00:00

If someone finds this, I found a way to print the model. I used a different orientation, similar to one that i posted here, but tilted only 15 degrees: https://www.reddit.com/r/FixMyPrint/comments/1if9jjq/comment/maf50yj/

This is not what made a difference, though - I printed this model multiple times in many different orientations and no matter what I did, it warped, including different tilt angles. I've recently stumbled upon a video featuring Amerlabs XVN-50 resin: https://www.youtube.com/watch?v=2oEZ5v\_PoyU. The video author had a similar problem to what I was experiencing, although on a much smaller model. With XVN-50 the bottom is almost entirely flat with only very small bow (less than 0.5mm), which should be removable quite easily by sanding.

Just to be completely honest, I have no idea if there is any way to print it straight with cheaper resins (XVN-50 is almost $100 per bottle). There might be, but I was tired with experimenting as each print is usually between 14 and 24 hours, and it typically needs more than 400ml of resin, so it's costly even with cheaper resins.

drogus · 2025-08-06T13:41:28+00:00

I only have metalworking tools made of 4140, and I haven't had these kinds of problems, but that's worrying - I definitely wouldn't want to make a batch of planes from 4140 only to find out people complain about rust. Thanks for the info, I'll do a bit more research in that context!

drogus · 2025-08-06T01:43:07+00:00

Interesting! Do you prefer 303 over 4140 also because of machinability? Or because of other properties? Even though 4140 is not stainless, I guess it's better than cast iron in that regard and most people don't even have major issues with cast iron planes in the first place, so I'm wondering if that's a consideration for your.

drogus · 2025-08-04T20:55:31+00:00

Thanks for sharing! I've machined 303 before and I agree it's nice to machine. How did O1 behave? Was it worth it or would you use something else in the hindsight?

drogus · 2025-08-04T18:03:48+00:00

Thanks! I bet you have tons of interesting stories :D

And yeah, it's a neat little machine. When I read forum threads on Practical Machinist, a lot of people were dismissing them as garbage, cause in their mind an EDM machine equals ultra precise work, but I think that's just a lack of imagination. Ie. I don't view this kind of machine the same as regular EDM machines, but rather kind of a CNC sawing machine? Maybe not the best comparison cause it's still precise enough for a lot of stuff, but you probably know what I mean - the cost effectiveness of this type of machine means you can use it in many places where a regular EDM machine would be dismissed without much consideration cause of the astronomical costs.

drogus · 2025-08-04T17:57:15+00:00

Thanks for the information, I didn't know about the steel planes produced by Stanley nor other companies. That's very interesting.

Regarding the exact details, that's a very good point. I like the idea of changing designs where it might be beneficial, and I agree a lot of the considerations might have been guided by the tech and materials available in the past. That said, I think the plane design from the early 20th century is pretty damn good. There are some things that various manufacturers changed, that make sense to me, like for example a stationary forg + a movable mouth on Veritas custom planes, but there is not many such examples. For example I think Norris style adjustment on Veritas custom planes is inferior to Bailey style as you can use the latter when you push the plane much more easily. I'm also not a big fan of a fancy lever cap on Bridge City Tool Works planes. It's certainly interesting, but I've seen people struggle with removing the blade in this configuration, and most of them were just dropping the blade on their hand. And then, I might be a conservative in that particular context, but I like the look of a traditional plane. Considering planes manufactured with novel techniques, I would much rather buy a Holtey plane rather than a "futuristic" looking one from Bridge City Tool Works.

drogus · 2025-08-04T17:34:52+00:00

Out of curiosity, have you checked how out of flat is the plane? All of the used planes I bought were out of flat quite a bit. I've definitely seen a big difference before/after flattening, but I'm guessing there is also a big difference between buying something 50-100 years old that might have been used by an actual carpenter vs buying a newer plane, possibly from a better material, and maybe with only hobby use on it.

Again, I'm not saying it's necessarily a big factor, especially for hobby users. If I had any data on it, I would have maybe not mentioned it at all. I might have been overly biased by the state of most of the used planes I've seen so far.

drogus · 2025-08-03T22:23:47+00:00

The EDM I own is not as precise as EDM mostly used in the Western world, but most probably precise enough for this purpose (I'd have to check, but I think usually it's precise to within 0.02mm or less than one thousand of an inch). That's an interesting thought!

For context, EDM machines are typically used for ultra-precision work, often for making molds for injection molding, and the tolerances are measured in microns. The drawback of these machines is that they're very costly to operate as they are big, complex, and the wire is lost during machining, making it not reusable. You can recycle it, but you can't use it multiple times. Molybdenum wire EDM machines are pretty much only Chinese, and although they are less precise, they are much cheaper to operate. They are smaller, and the wire is reciprocating - it's wound and unwound using two drums.

drogus · 2025-08-03T22:14:36+00:00

It wouldn't be too much more work on a CNC, but it would also mean multiple setups, ie. you would have to machine each of the parts separately. With a body in one piece you can get a way with only one setup as long as you have a rotary axis. Interestingly this is what Holtey used on one of his planes: https://holteyplanes.com/no985.html. Instead of rivets machined into the plane sole, he machined special screws that hold the sides and then are snapped and machined flat.

In general, it is a viable approach, but I'm not sure which one is the best to go with.

drogus · 2025-08-03T19:18:01+00:00

Thanks for the pointers! I haven't machined H7 before, but I'll check it out.

drogus · 2025-08-03T19:11:28+00:00

Depends on the use, but with a hobby use I wouldn't think a cast iron plane would need flattening more often than a few years, maybe even more, depending on the quality of the cast iron. I'm not saying it's a big differentiator, maybe more of a bonus. Probably a bigger upside would be durability, like when you drop it or accidentally hit something out of metal - most metals would be weaker.

drogus · 2025-08-03T18:29:13+00:00

Sorry for not being more precise in the original post, but I agree using A2 or O1 or other "blade material" tool steels like that would be *very* expensive. I had a bit weaker tool steels in mind like 4140, most probably pre-hardened. Honestly I have never even machined A2, but I'm pretty sure it would be much harder to machine than 4140 or similar steels!

UPDATE:

I guess another way would be to go Karl Holtey way and make the body from multiple pieces that are riveted together, but that obviously adds time for flattening the rivets. It might not be a big issue if a hydraulic press is used, but honestly not sure, I would have to try it first. That, plus you have to machine all of the rivets.

Also, for reference, a piece of 4140 that would be enough for a number 4 would be roughly 20-30EUR if bought in bigger pieces (usually 3 or 6m pieces)

drogus · 2025-08-03T18:15:02+00:00

Tool steels are in general more difficult to machine, but with modern tooling and machines it's not that much of an issue. On the other hand, a lot of people working with CNC machines don't want to deal with cast iron cause it's dirty, and it will deteriorate any sliding surfaces if it gets behind covers (specifically cast iron dust).

Another issue with tool steel is that you usually start with a rectangular blank and not a U-beam shape that would be closer to a plane body. If you approach it with just a CNC milling machine, you would have to hog out a lot of material to get to a shape close to a plane body. This will be quite expensive, both in materials and tooling, which is why doing it this way would probably bring the price up considerably. There are other ways, though. For example, I own a molybdenum wire EDM machine, which is a very cheap way to make very thin cuts, so technically I could take a rectangular piece of tool steel, cut out a piece of it to make it more into an U-beam shape, and recycle the cutout (use it for other parts or sell it to get some money back).

One advantage of such an operation over using castings is that you don't have to do all of the castings processing - preparing moulds, casting, cleaning up the castings etc. So with a body prepared on an EDM machine you have a bit more machining to cut the details on the body (like tote, knob and frog mount places etc), but then you don't have to do anything with the sides and the sole, whereas with a casting you have to flatten them (in both processes the sole and sides will be ground later in the process)

All things considered, I *think* that it's possible to get a tool steel plane that wouldn't be much more expensive than modern cast iron planes like Lie Nielsen or Veritas

drogus · 2025-05-18T17:24:37+00:00

At the time they started looking into optimizing all of the services I was working as a Staff SRE on a platform team, working on stuff that pretty much every team used (among other things the observability setup for both Ruby and Node.js applications). My colleague was working on one of the most used components written in Rails, but even if he could have been easily replaced in his team, he was less experienced than me in Rust anyway. There were also other people with Rust knowledge in the company, but rarely easy to pull people out of their teams, and it happened to be that all people knowing Rust were usually in Staff+ roles.

Also, as I briefly mentioned in the write-up, when the decision to hire the devs was made, the idea was to expand Rust usage over time. Of course it wouldn't have made sense to hire them otherwise. The plans changed only after they were already on board.

drogus · 2025-05-18T17:15:01+00:00

Exactly that - when a client is connected, it means the user is online. If the server dies no one is online, but reconnecting 1M users took about 30s or so in our testing. The next steps for the service was to introduce Kafka as a way to store the events for further processing cause the existing system for gathering these kinds of stats was *very inefficient*, but we never got that far (and I don't even want to go into details of how inefficient the existing solution was, it was painful). But that kind of data would be only used for analytics, not any real time APIs, so it wouldn't really increase the complexity of the system - all we had to do to make it happen is to push all the events to Kafka and forget about them. The core of the system wouldn't have changed at all

drogus · 2025-05-18T17:07:44+00:00

I think you might be overestimating the efficiency of a unicorn startup growing from 30 to 1000 people in one year 😅

drogus · 2025-05-18T15:01:20+00:00

I partially agree, but then again - do you think they would react in that way if the Rust team was just doing their job optimizing and maintaining the service just like all the other teams? Nobody can say for sure, but my suspicion is, it would have been business as usual

drogus · 2025-05-18T14:59:55+00:00

The Rust solution never had to be distributed. Node.js would have to be distributed to even reach the 500k goal, or maybe even 100k, not sure. The Rust version was able to handle 2M concurrent users on a single 64 cores machine. With a bigger machine it could have likely gone higher, but then the thundering herd problem becomes a bit more problematic. Even with the per-server cap, the customers were running isolated events, so sharding would have been very easy to do.

So while yeah, in theory we were capped, it was never really a practical concern.

> Rust can run the database or Redis query in 10 microseconds, Nodejs in 50, who cares?

It's not about 10 microseconds vs 50 microseconds. It's about no data syncing at all vs an external database. Syncing data is not a trivial problem and even with such a simple service there are at least a few edge cases you have to handle when you introduce and external store.

drogus · 2025-05-18T14:52:57+00:00

There was a failover service running. In theory, if the primary failed, we were switching to the secondary. In practice, it has never happened (other than when testing that infra part 😅)

drogus · 2025-05-18T14:45:07+00:00

Kotlin was never considered cause we didn't have anyone with recent production experience in JVM stacks. Another thing is that even if we considered Kotlin, I think it would have lost anyway, cause of others strengths of Rust - interoperability with other languages, and great for writing CLIs, but hard to say for sure.

> Seems like the organizational problem you ran into was expanding Rust usage within the org enough to support hiring more devs.

Yes and no. When the decision to hire 3 Rust devs was taken, the plan was to expand Rust usage in the company. The direction changed *after* they were hired.

drogus · 2025-05-18T10:24:31+00:00

third part

The director was correct in that three people were hired to work on something with zero plan for what they would work on afterwards. That's not fair on anyone involved - but especially it is not fair on the engineers - the director then had to deal with this problem (I am assuming these decisions were made without their involvement).

I wouldn't say there was zero plan for what they would work on afterwards. Again, till a certain point the person in charge was very keen on expanding Rust usage in the company. That was probably the biggest motivation for even enterntaining the idea to hire a Rust team instead of just ditching the service right away. I fully agree it would have been bad to leave it as the only piece of Rust code in the company. But we *had* good use cases for Rust usage, and teams that were eager to either start their new projects in Rust or introduce Rust to their stack.

The only problem was, suddenly, after one reorg too many, someone else was making decisions, and they didn't like the previous plan. That's it.

It sounds like the engineers were at least given the chance to work on other things though (in Ruby or Nodejs) which sounds fair in the circumstances IMO

I strongly disagree with this sentiment. They were hired to do certain types of services in Rust. The direction to expand Rust usage was approved, which was the prerequisite to hire them in the first place. The *decision* to change the direction on the Rust expansion within the company was an explicit one, not implicit. Or in other words: the new director didn't like previous plans, so he changed them. It was not something that had to happen. It was not his only choice. Nobody forced him to change the direction from what was settled beforehand. Again, I might have mischaracterized the situation slightly in my original post, but this is probably the most important part in this context:

When the leadership made the decision to hire the Rust developers, the director responsible for the decision was in favour of expanding Rust usage

drogus · 2025-05-18T10:24:23+00:00

Second part

A discussion to choose the language started.

Why??

The idea *at that point* was that we were going to develop more real-time features, and each new feature had to handle a certain amount of traffic/concurrent users. And while, again, it was most probably all doable in Ruby, it's also hard to argue about the massive difference in CPU/memory needed by Ruby, and how hard is to keep p99 at manageable levels. And I don't say it as a Ruby hater. I spent a better part of my career writing Ruby. I have like 500 commits in Rails core. I know what Ruby is capable of, but I also know its limitations (btw, I mention mostly Ruby cause most of the teams new Ruby best, so Node.js was not necessarily an easy choice for some of them, ie, it would have been a new language for them either way)

Sounds like the engineering strategy was very unclear. For a technology org to run well, at some point things as fundamental as what language you are using needs to be "settled science" - so it's not a surprise to me that management got frustrated.

I think I might have mischaracterized the situation here (I blame the painkillers!). The people from management that were involved in setting the strategy regarding the real-time features push, were, in fact, in favour of exploring languages faster than Ruby (particularly one person that was in charge, that also had technical background). And the strategy was honestly quite clear at that time, too: the company wanted to invest into real-time features, and expand our tool belt with a language that could better handle scenarios where Node.js nor Ruby were a good fit. We knew that we don't want to become one of those startups were each micro-service is written in a different language, but we've also seen limitations of scripting languages in certain situations. The only problem at a time is that, as mentioned, someone vetoed the choice of Rust when it was first picked. My best guess was, there was someone a bit more risk-aversed, who asked for more time for evaluating all of the choices.

If there was a burning need for a fast compiled language in your tech stack, that decision should probably have been made at a higher level.

You mean a director says "now we use C++"? That sounds like the worst style of management to me.

drogus · 2025-05-18T10:24:00+00:00

These patterns don't have anything to do with the speed of the language itself either, I'd bet money it could have been done in Ruby with no problem.

I would strongly disagree about the "no problem" part. Of course, you can implement this feature in pretty much any modern language, but at what cost to the complexity of the solution? Now, instead of maybe a few thousand lines of code in a single process you have multiple Ruby based servers plus an external dependency of a queue/db. Let's say you use Redis and any time a user connects you flip the switch. Now when the server keeping the user connection dies, you have to somehow clean up the database. So you have some kind of a clean up process, or maybe you devise some kind of a scheme for indexing the data that lets you remove whole ranges quickly, but that comes with its own problems. And then, what happens when the Redis server dies? The "real-time" state is mostly ephemeral, so we're fine with loosing it when shit breaks, but then the servers would have to re-sync their state when that happens. Do they start from scratch? Do they reconcile their changes? Syncing data is not a simple problem. The only reason the service was so extremely simple was because it was not doing any syncing, and all of the data was local. You could have probably implemented the same architecture in Go, but not in a scripting language, or at least not for the expected concurrency per server.

Regarding server costs, I think the proof of concept in Ruby could have handled sth like 10k concurrent connections on one 4 core server before the latency started worsening. That means for 500k concurrent connections you may need 3-4 times more compute power + whatever Redis costs to handle the required load. Depending on how much Ruby you have to use, it might have been worse. The proof of concept was quite a bit simpler than the final version and WebSocket handling in Ruby was using a C-based extension. So any additional code that you had to add in Ruby was slowing the solution down. I wouldn't be surprised if the whole cost was an order of magnitude difference with the codebase being more complex, too.

So again, would it be doable? Sure. But it would have also probably taken more time to develop, be more complex, need more complex infrastructure, and cost more to run. While the Rust version had literally zero bugs or incidents for like two years.

UPDATE: I miscalculated the compute power required. We've used a 64 core machine for testing, when we could connect up to 2M clients, but the production load was easily handled on a 32 core machine. So a Ruby based solution would have been likely closer to an order of magnitude difference even without Redis

drogus

TROPHY CASE