Ketan's Home

January 30, 2019

3D Printed Wheels Get Some Much Needed Grip

Filed under: Uncategorized — ketan @ 8:15 PM

You’d be hard-pressed to find more ardent supporters of 3D printing then we here at Hackaday; the sound of NEMA 17 steppers pushing an i3 through its motions sounds like a choir of angels to our ears. But we have to admit that the hard plastic components produced by desktop 3D printers aren’t ideal for a number of applications. For example, the slick plastic is useless for all but the most rudimentary of wheels. Sure there are flexible filaments that can give a printed wheel a bit of grip, but they came with their own set of problems (not to mention, cost).

In the video after the break, [Design/Forge] demonstrates a clever method for fitting polyurethane rubber “tires” onto 3D printed hubs which is sure to be of interest to anyone who’s in the market for high quality bespoke wheels for their project. The final result looks extremely professional, and while there’s a considerable amount of preparation that goes into it, once you’re set up you should be able to pump these out quickly and cheaply.

The process begins with a 3D printed mold pattern, which includes the final tire tread texture. This means you can create tire treads of any design you wish, which should have some creative as well as practical applications. The printed part is then submerged in silicone rubber and allowed to cure for 8 hours. Once solidified, the silicone rubber becomes the mold used for the next steps, and the original printed part is no longer needed.

The second half of the process is 3D printing the wheels to which the tires will be attached. These will be much smaller than the original 3D printed component, and fit inside of the silicone mold. The outside diameter of the printed wheel is slightly smaller than the inside diameter of the mold, which gives [Design/Forge] the space to pour in the pigmented polyurethane rubber. The attentive viewer will note that the 3D printed wheel has a slight ribbed texture designed into it, so that there will be more surface area for the polyurethane to adhere to. Once removed from the mold and cleaned up a bit, the final product really does look fantastic; and reminds us of a giant scale LEGO wheel.

Whether you’re casting metal parts or just want a pair of truly custom earbuds, creating silicone molds from 3D printed parts is an extremely useful skill to familiarize yourself with. Though even if you don’t have a 3D printer, there’s something to be said for knowing how to mold and cast real-world objects as well.

[Thanks to Itay for the tip.]

from Hack a Day

How to use Windows 10’s built-in OpenSSH to automatically SSH into a remote Linux machine

Filed under: Uncategorized — ketan @ 8:02 PM

In working on getting Remote debugging with VS Code on Windows to a Raspberry Pi using .NET Core on ARM in my last post, I was looking for optimizations and realized that I was using plink/putty for my SSH tunnel. Putty is one of those tools that we (as developers) often take for granted, but ideally I could do stuff like this without installing yet another tool. Being able to use out of the box tools has a lot of value.

A friend pointed out this part where I’m using plink.exe to ssh into the remote Linux machine to launch the VS Debugger:

"pipeTransport": {

"pipeCwd": "${workspaceFolder}",
"pipeProgram": "${env:ChocolateyInstall}\\bin\\PLINK.EXE",
"pipeArgs": [
"debuggerPath": "/home/pi/vsdbg/vsdbg"

I could use Linux/bash that’s built into Windows 10 for years now. As you may know, Windows 10 can run many Linuxes out of the box. If I have a Linux distro configured, I can call Linux commands locally from CMD or PowerShell. For example, here you see I have three Linuxes and one is the default. I can call "wsl" and any command line is passed in.

C:\Users\scott> wslconfig /l

Windows Subsystem for Linux Distributions:
Ubuntu-18.04 (Default)
C:\Users\scott> wsl ls ~/
forablog forablog.2 myopenaps notreal test.txt

So theoretically I could "wsl ssh" and use that Linux’s ssh, but again, requires setup and it’s a little silly. Windows 10 now supports OpenSSL already!

Open an admin PowerShell to see if you have it installed. Here I have the client software installed but not the server.

PS> Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

Name : OpenSSH.Client~~~~
State : Installed

Name : OpenSSH.Server~~~~
State : NotPresent

You can then add the client (or server) with this one-time command:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~

You’ll get all the standard OpenSSH stuff that one would want.

OpenSSL tools on Windows

Let’s say now that I want to be able to ssh (shoosh!) into a remote Linux machine using PGP keys rather than with a password. It’s much more convenient and secure. I’ll be ssh’ing with my Windows SSH into a remote Linux machine. You can see where ssh is installed:

C:\Users\scott>where ssh


Level set – What are we doing and what are we trying to accomplish?

I want to be able to type "ssh pi@crowpi" from my Windows machine and automatically be logged in.

I will

  • Make a key on my Window machine. The FROM. I want to ssh FROM here TO the Linux machine.
  • Tell the Linux machine (by transferring it over) about the public piece of my key and add it to a specific user’s allowed_keys.

Here’s what I did. Note you can do this is several ways. You can gen the key on the Linux side and scp it over, you can use a custom key and give it a filename, you can use a password as you like. Just get the essence right.

Below, note that when the command line is C:\ I’m on Windows and when it’s $ I’m on the remote Linux machine/Raspberry Pi.

  • gen the key on Windows with ssh-keygen
  • I ssh’ed over to Linux and note I’m prompted for a password, as expected.
  • I "ls" to see that I have a .ssh/ folder. Cool. You can see authorized_keys is in there, you may or may no have this file or folder. Make the ~/.ssh folder if you don’t.
  • Exit out. I’m in Windows now.
  • Look closely here. I’m "scott" on Windows so my public key is in c:\users\scott\.ssh\ Yours could be in a file you named earlier, be conscious.
  • I’m type’ing (cat on Linux is type on Windows) that text file out and piping it into SSH where I login that remote machine with the user pi and I then cat (on the Linux side now) and append >> that text to the .ssh/authorized_keys folder. The ~ folder is implied but could be added if you like.
  • Now when I ssh pi@crowpi I should NOT be prompted for a password.
  • Here’s the whole thing.

    C:\Users\scott\Desktop> ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (C:\Users\scott/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in C:\Users\scott/.ssh/id_rsa.
    Your public key has been saved in C:\Users\scott/.ssh/
    The key fingerprint is:
    The key's randomart image is:
    +---[RSA 2048]----+
    | . .... . |
    |..+. .=+=. o |
    | .. |
    C:\Users\scott\Desktop> ssh pi@crowpi
    pi@crowpi's password:
    Linux crowpi 2018 armv7l

    pi@crowpi:~ $ ls .ssh/
    authorized_keys id_rsa known_hosts
    pi@crowpi:~ $ exit
    Connection to crowpi closed.
    C:\Users\scott\Desktop> type C:\Users\scott\.ssh\ | ssh pi@crowpi 'cat >> .ssh/authorized_keys'
    pi@crowpi's password:
    C:\Users\scott\Desktop> ssh pi@crowpi
    pi@crowpi: ~ $

    Fab. At this point I could go BACK to my Windows’ Visual Studio Code launch.json and simplify it to NOT use Plink/Putty and just use ssh and the ssh key management that’s included with Windows.

    "pipeTransport": {
    "pipeCwd": "${workspaceFolder}",
    "pipeProgram": "ssh",
    "pipeArgs": [
    "debuggerPath": "/home/pi/vsdbg/vsdbg"


    NOTE: In my previous blog post some folks noted I am logging in as "root." That’s an artifact of the way that .NET Core is accessing the GPIO pins. That won’t be like that forever.

    Thoughts? I hope this helps someone.

    Sponsor: Your code is bad, but that’s ok thanks to Sentry’s full stack error monitoring that enables you to track and fix application errors in real time. Stop garbage code from becoming garbage fires.

    © 2018 Scott Hanselman. All rights reserved.


    from Hanselman

    January 21, 2019

    Manual Bean Definitions in Spring Boot

    Filed under: Uncategorized — ketan @ 8:59 PM

    Suppose you want to use Spring Boot, but you don’t want to
    @EnableAutoConfiguration. What should you do exactly? In an
    earlier article
    I showed that Spring is intrinsically fast and lightweight, but one of
    the short pieces of advice improve startup time was to consider
    manually importing the Spring Boot autoconfigurations, instead of
    sucking them all in automatically. It won’t be the right thing to do
    for all applications, but it might help, and it certainly won’t hurt
    to understand what the options are. In this piece we explore various
    ways of doing manual configuration and assess their impact.

    Full Autoconfiguration: Hello World WebFlux

    As a baseline, let’s look at a Spring Boot application that has a
    single HTTP endpoint:

    public class DemoApplication {
      public Mono<String> home() {
        return Mono.just("Hello World");
      public void main(String[] args) {, args);

    If you run this app with all the tweaks suggested in the earlier
    article it should start in round about a second, or a bit longer
    depending on your hardware. It does a lot in that time – sets up a
    logging system, reads and binds to configuration files, starts Netty
    and listens on port 8080, providing a route to the @GetMapping in
    the application, and also provides default error handling. If the
    Spring Boot Actuator is on the classpath, you also get a /health and
    an /info endpoint (and it will take a bit longer to start up because
    of that).

    The @SpringBootApplication annotation, in case you didn’t know, is
    meta-annotated with @EnableAutoConfiguration and this is what
    provides all that useful functionality for free. That’s what makes
    Spring Boot popular, so we don’t want to lose any of it, but we can
    take a closer look at what is actually happening and maybe do some of
    it manually, to see if we learn anything.

    if you want to try this code out, it’s easy to get an empty
    WebFlux app from the Spring Initializr. Just select
    the "Reactive Web" checkbox and download the project.

    Manual Imports of Autoconfiguration

    While the @EnableAutoConfiguration feature makes adding features to
    an application easy, it also takes away some control over which
    features are enabled. Most people are happy to make that compromise –
    the ease of use outweighs the loss of control. Potentially there are
    performance penalties – the application might start a bit slower
    because Spring Boot has to do some work to find all those features and
    install them. In fact there is not a significant amount of effort
    involved in finding the right features: there is no classpath scan,
    and condition evaluation is extremely fast, after careful
    optimization. The bulk (80% or so) of startup time for one of this
    application is taken up by the JVM loading classes, so practically the
    only way to make it start up quicker is to ask it to do less, by
    installing fewer features.

    Autoconfiguration can always be disabled using the exclude attribute
    in the @EnableAutoConfiguration annotation. Some individual
    autoconfigurations also have their own boolean configuration flag that
    can be set externally, e.g. for JMX we could use
    spring.jmx.enabled=false (as a System property or in a properties
    file, for example). We could go down that road and manually switch off
    everything we didn’t want to use, but that gets a bit clumsy and
    doesn’t stop additional things being switched on if the classpath

    Instead, let’s see what we can do using the existing autoconfiguration
    classes but just applying the ones we know we want to use,
    corresponding to the features we like. We could call this the "a la
    carte" approach, as opposed to "all you can eat" that comes with full
    autoconfiguration. Autoconfiguration classes are just regular
    @Configuration so we can @Import them into an application that
    does not @EnableAutoConfiguration. For example, here is the
    application above, with all the features we want (excluding

    public class DemoApplication {
      public Mono<String> home() {
        return Mono.just("Hello World");
      public void main(String[] args) {, args);

    This version of the application will still have all the features we
    described above, but will start faster (probably by 30% or so). So
    what did we give up to get that faster start up? Here’s a quick

    • The full features set of Spring Boot autoconfiguration includes
      other stuff that might actually be needed in a real application, as
      opposed to the specific tiny sample. In other words, the 30% speed up
      is not going to be available for all applications, and your mileage
      may vary.

    • The manual configuration is brittle, and hard to guess. If you wrote
      another application that did slightly different things, you would need
      a different configuration import. You can mitigate this by extracting
      it into a convenience class or annotation, and re-using it.

    • An @Import does not behave the same way as
      @EnableAutoConfiguration in relation to ordering of configuration
      classes. The order is important within the @Import in case some
      classes have conditional behaviour that depend on earlier
      classes. To mitigate you just have to be careful.

    • There is another ordering problem in a typical real-world
      application. To mimic the behaviour of @EnableAutoConfiguration you
      need the user configurations to be processed first, so that they can
      override the conditional configuration in Spring Boot. If you use
      @ComponentScan, you can’t control the order of the scan, or the
      order those classes are processed compared to @Imports. You can
      mitigate this by using a different annotation (see below).

    • The Spring Boot autoconfigurations were actually never designed to
      be used this way, and doing so might introduce subtle bugs in your
      application. The only mitigations for this are exhaustive testing that
      it works the way you expect, and being cautious about upgrades.

    Adding Actuators

    We can also add the actuators if they are on the classpath:

        HealthIndicatorAutoConfiguration.class, HealthEndpointAutoConfiguration.class,
        InfoEndpointAutoConfiguration.class, WebEndpointAutoConfiguration.class,
    public class DemoApplication {
      public Mono<String> home() {
        return Mono.just("Hello World");
      public void main(String[] args) {, args);

    This app starts even faster comparative to the full
    @EndpointAutoConfiguration application (maybe even 50% faster),
    because we only included the configuration relevant to the two default
    endpoints. Spring Boot activates all endpoints by default but does not
    expose them to HTTP. If we only care about /health and /info that is
    wasteful, but of course it also leaves a lot of really useful features
    on the table.

    Spring Boot may well do more in the future to disable actuators
    that have not been exposed or have not been used. E.g. see issues on
    (which is already in Spring Boot 2.1.2).

    What’s the difference?

    The manually configured application has 51 beans, while the fully
    leaded autoconfigured application has 107 beans (not counting
    actuators). So it’s maybe not a surprise that it starts up a bit
    quicker. Before we move on to a different way to implement the sample
    application, let’s take a look at what we have left out in order to
    get it to start up faster. If you list the bean definitions in both
    apps you will see that all the differences come from the
    autoconfigurations that we left out, and which would not have been
    conditionally excluded by Spring Boot. Here’s the list (assuming that
    you are using spring-boot-start-webflux with no manual exclusions):


    So that’s 12 autoconfigurations that we didn’t need (yet anyway) and
    which led to 56 additional beans in the autoconfigured
    application. They all provide useful features, so we might want to
    include them again one day, but for now let’s assume that we are happy
    to live without whatever they are doing.

    spring-boot-autoconfigure has 122 autoconfigurations (there
    are more in spring-boot-actuator-autoconfigure) and the fully leaded
    autoconfigured sample application above only used 18 of them. The
    computation of which ones to use takes place very early and most of
    them are discarded by Spring Boot before any classes are even
    loaded. It’s very fast (a few milliseconds).

    Spring Boot Autoconfiguration Imports

    The ordering issue associated with the difference between user
    configuration (which has to be applied last) and autoconfiguration can
    be addressed partially by using a different annotation. Spring Boot
    provides an annotation for this: @ImportAutoConfiguration, which is
    from spring-boot-autoconfigure but used in the
    features that ship with Spring Boot Test. So you can replace
    the @Import annotation in the examples above with
    @ImportAutoConfiguration and the effect is to defer processing of
    the autoconfigurations until after all the user configurations
    (e.g. picked up via @ComponentScan or @Import).

    We can even go a stage further than that if we are prepared to curate
    the list of autoconfigurations into a custom annotation. Instead of
    just copying them into an explicit @ImportAutoConfiguration, we can
    write a custom annotation like this:

    public @interface EnableWebFluxAutoConfiguration {

    The main feature of this annotation is that it is meta-annotated with
    @ImportAutoConfiguration. With that in place we can add the new
    annotation to our application:

    public class DemoApplication {
      public Mono<String> home() {
        return Mono.just("Hello World");
      public void main(String[] args) {, args);

    and list the actual configuration classes in /META-INF/spring.factories:


    The advantages of doing this are that the application code no longer
    has to manually enumerate the configurations, and also that the
    ordering is now taken care of by Spring Boot (the properties file
    entry is sorted before it is used). The disadvantage is that it is
    only useful for applications which need precisely these features, and
    has to be replaced or augmented in any application that wants to do
    something a bit different. It is still fast though – Spring Boot does
    a little bit of extra work for the book keeping (sorting and
    ordering), but not really very much. It will probably still start in
    less than 700ms on the right hardware, with the right JVM flags.

    Functional Bean Definitions

    In the earlier article I mentioned that functional bean definitions
    would be the most efficient way to get an application started with
    Spring. This is still the case, and we can squeeze an extra 10% or so
    out of this application by re-writing all the Spring Boot
    autoconfigurations as ApplicationContextInitializers. You could do
    that manually, or you could use some initializers that have already
    been prepared for you, as long as you don’t mind trying out some
    experimental features. There are 2 projects currently active exploring
    the idea of new tools and new programming models based on functional
    bean definitions: Spring
    . Both provide at least a minimal set of functional bean
    definitions replacing or wrapping the Spring Boot
    autoconfigurations. Spring Fu is API (DSL) based, and doesn’t use
    reflection or annotations. Spring Init has the functional bean
    definitions and also has a prototype of an annotation-based
    programming model for "a la carte" configuration. Both are covered
    in more detail elsewhere.

    The main point to note here is that functional bean definitions are
    faster, but if that is your main concern, remember that it is only a
    10% effect. As soon as you put all the features back in the
    application that we stripped down above, you are back to loading all
    the necessary classes and back to roughly the same approximate startup
    time as well. To put this another way, the cost of the
    @Configuration processing at runtime is not completely negligible,
    but it also isn’t very high (10% or so in these tiny apps, or maybe

    Summary and Future Directions

    Here’s a graph summarizing some benchmark results from a different
    application, the Spring PetClinic:

    Figure 1. Petclinic Startup Time (Seconds)

    It’s not a "real" application, but it is heavier than the simple
    sample, and uses a lot more features at runtime (like Hibernate for
    example), so it is somewhat more realistic. There are two
    versions, "demo" and "actr", where the latter is just the same but
    with Actuators. For both samples, the fastest startup time is the
    yellow dot, which is functional bean definitions, but only 10% behind
    that (about 200ms in this app) are the "a la carte" options (green and
    red). Green uses a custom annotation like the
    @EnableWebFluxAutoConfiguration one above. Red is a different "a la
    carte" option where groups of autoconfigurations can be imported
    together via a different custom annotation, currently named
    @SpringInitApplication and being prototyped in Spring Init. Blue is
    the fully leaded autoconfiguration (out of the box Spring Boot).

    Spring Boot autoconfiguration is hugely convenient, but can be
    characterized as "all you can eat". Currently (as of 2.1.x) it is
    maybe providing more features than some applications use or
    require. In the "a la carte" approach, you can use Spring Boot as a
    convenient collection of prepared and pre-tested configurations and
    choose which parts you use. If you do that then
    @ImportAutoConfiguration is an important part of the toolkit, but
    exactly how you should best use it might change as we research this
    topic further. Future versions of Spring Boot, and possibly other new
    projects like Spring Fu or Spring Init, will make it easier to narrow
    the choice of configurations used at runtime, either automatically or
    by explicit choice. At the end of the day, @Configuration processing
    at runtime is not free, but it isn’t particularly expensive either
    (especially with Spring Boot 2.1.x). The smaller number of features
    you use, the fewer classes are loaded, which lead to faster
    startup. At the end of the day we don’t expect
    @EnableAutoConfiguration to lose its value or its popularity.

    from Spring

    January 7, 2019

    Sugar As A Bed Adhesive For 3D Printing

    Filed under: Uncategorized — ketan @ 12:14 AM

    3D printers, like most CNC machines, reward careful thought and trial and error. It’s important to use the correct machine settings and to prepare the build environment properly in order to get good results. Fused Filament Fabrication printers rely on melting plastic just so in the production of parts, and have their own set of variables to play with. [Mysimplefix] has been exploring various solutions to bed adhesion and found something that seems to work perfectly, right in the pantry.

    That’s right, this solution to the problem of bed adhesion is more commonly stirred into your coffee every morning – it’s sugar. [Mysimplefix] shares their preferred process, consisting of first mixing up a sugar/water solution in the microwave, before applying it to the bed with a paper towel and allowing the water to evaporate off.

    Several test prints are then shown, with major overhangs, to show the adhesive capabilities of the sugar. The results are impressive, with parts sticking well while the bed is hot, while being easy to remove once cool. The video deals with PLA, but we’d be interested to see the performance with other materials as well.

    It’s a tidy solution, and we’d love to know your thoughts and experiences in the comments. We’ve had a good long think about adhesives ourselves, too.

    [Thanks to Baldpower for the tip!]


    from Hack a Day

    January 2, 2019

    Arduino and Pi Share Boardspace

    Filed under: Uncategorized — ketan @ 12:00 AM

    Arduino and Pi Share Boardspace

    A Raspberry Pi Zero (W) and Arduino are very different animals, the prior has processing power and connectivity while the latter has some analog to digital converters (ADCs) and nearly real-time reactions. You can connect them to one another with a USB cable and for many projects that will happily wed the two. Beyond that, we can interface this odd couple entirely through serial, SPI, I2C, and logic-level signaling. How? Through a device by [cburgess] that is being called an Arduino shield that supports a Pi0 (W). Maybe it is a cape which interfaces with Arduino. The distinction may be moot since each board has a familiar footprint and both of them are found here.

    Depending on how they are set up and programmed, one can take control over the other, or they could happily do their own thing and just exchange a little information. This board is like a marriage counselor between a Raspberry Pi and an Arduino. It provides the level-shifting so they don’t blow each other up and libraries so they can speak nicely to one another. If you want to dig a bit deeper into this one, design files and code examples are on available.

    Perhaps we’ll report on this board at the heart of a pinball machine retrofit, a vintage vending machine restoration, or maybe a working prop replica from the retro bar in Back to the Future II.

    from Hack a Day

    Blog at