Member Since: December 18, 2009

Country: United States

  • That was the best filament review… … … …In the world.

  • And, another +1 for 1.75mm. Some of us have less expensive (Actually homebrew or very nearly to it) printers (I’ve a Prusa i3 variant made in China with a 1.75mm hotend.) The benefit to 1.75 is “bowden tube” type extruders and/or smaller steppers for filament feed. (More accuracy, better at fine detail because it requires less tweaking and has a higher extruder “traverse"speed. And is less likely to jam and strip the filament.)

  • Windows for my primary desktop (games and such) and my CNC mill’s controller, Debian (KDE, not GNOME) for my laptop and almost everything serious.

    If I had to pick a favorite? Linux. Being able to configure it (once.) and not to have to reboot twice every day (W10, I’m looking at you.) or after an in-place upgrade is nice. I only use windows because developers of certain pieces of (alternativeless) software and hardware (I’d buy one of your DSOs, but Linux support is “LOLNOPE”, especially when it comes to “But we need a custom driver, because of Windows”. WINE may not be an emulator, but it also Is Not an Alternative, in that case.) who w/don’t target Linux.

    But for most desktop stuff? I’ve even got my 55 year old father on Linux. He hasn’t managed to mess it up yet. He used to come to me every couple of months (“It’s broken.”) for a windows reinstall.

  • Try a kitchen range hood. Some idiot designed what could be done using 6 transistors, an LCD clock and a handful of other discretes (3 latches, basically) with a little MCU instead. For a two-speed range hood fan and light with a clock. Go to turn it on while cooking dinner; nothing. Clock frozen, steam condensing on the walls and ceiling. I had to go toggle the kitchen breaker because they left out a reset button.

    That’s rather unacceptable. Ask yourself while designing two additional questions: Can I X? and: Should I X?

    Yes, you CAN use an MCU for a range hood. No, you probably SHOULDN’T.

    Design perfection is not when there is nothing left to add, it’s instead when there is nothing left to take away.

  • Depending on the weight of the unit, I’d build the RC helicopter/plane/tank of doom. Failing that, I’d probably attempt conversion to {L,C}NG and find the generator head that matches it and have a decent backup power source. (LNG is cheaply delivered in my area.)

    Also, +1 for the safety enclosure. Turbines letting go at 50k RPM have a high likelihood of being lethal or permanently injurious to bystanders. Some of those fragments could have vastly more kinetic energy than a rifle bullet or a machete swung with intent to maim. If the compressor blades are longer than the width of appendages you’re not willing to part with, stick it in a box constructed of a minimum of half-inch thick steel. I’d also recommend carrying a pre-made tourniquet (like the Army’s “Combat Application Tourniquet”) so you can slip it over the stump of your leg/arm and torque it down to keep you from bleeding out if/when your turbine decides to take offense to being poked with a stick. Or the blades decide that they’ve had enough.

  • What, no development server and database cloned from the current live server+database just for testing? It’s not like you are using someone else’s bleeding-edge software product. Think of it this way: SparkFun Inc. is currently using SparkFun Inc’s Developers AG’s software product. Does this make sense? You’re using an internal product with what appears to be minimal testing. Things under development should never go live as the core of your business model without testing it until you know it’s right and reliable. By having an internal-only beta server that is being actively hacked on, you can do off the wall things like try a different DB, simulate purchases and so on, and do everything that the production server does currently without actually doing it for real. You test it by shadowing the current activities by the main server on the development server. That’s the best test, shadowing live usage and seeing if the results agree. Smaller changes and verification of correctness are important. smaller unit tests of one-shot changes are important. Not testing is nearly unforgivable for a developer. That’s like soldering up a PCB and wiring up a circuit that you know will be plugged into a wall and draw a couple dozen amps without first checking for shorts.

  • PattonBot mk1 shot himself with the one and only portable shrink ray prototype. As such, the robotic revolution will be postponed until next Friday.

  • Fall time checks could also mean the ability to detect captive coins. (thread tied to a small hole in the coin)

  • And what percentage of those products are faulty?
    Very few. The point I was trying to make was not that RoHS is not the way to go (far from it) but that it only takes one high-profile issue to cause backlash from the public. This would be exacerbated by a critical application failure, especially in a health care or other mission-critical context.
    Where the system is mission critical, the use of ‘Fail
    Safe’ PLC’s with double, or triple backed up control
    hardware is the protection mechanism… You think the
    early nuclear plants don’t get hardware failures?
    The point I was making is that the manufacturers of such items don’t, and didn’t, go with leading-edge technology because it needed to mature a little before making its way into those applications.
    The key problem is that they didn’t know how it would age, how it would perform, how reliable it would be, etc. There are regulatory compliance issues and safety certifications in that sector that require knowledge that was, at the time, unavailable.
    Like I said: RoHS is good for the environment, good for the collective health of the public, and the exemptions aren’t going to be there forever, since the body of research on RoHS failure modes is growing daily.

No public wish lists :(