Manufacturers of 3D printers have a lot to do before they catch up with makers of the cheapest 2D, paper-based printers. If you’ve ever taken an inkjet apart, you’ll most likely find some sort of closed-loop control on at least one of the axes. The 2D printer will tell you when you’re out of ink, when a 3D printer will go merrily along, printing in air without filament. File formats? Everything is Gcode on a 3D printer, and there are dozens, if not hundreds of page description languages for 2D printers.
The solution to some of these problems are drivers – software for a 3D printer that slowly consumes the slicing of an object, printer settings, and placing an object on the bed. It’s coming, and the people who are responsible for making your 2D printer work with your computer are busy at work messing up the toolchain for your 3D printer.
The latest version of CUPS (C Unix Printing System) adds support for 3D printers. This addition is based on meetings, white papers, and discussions in the Printer Working Group (PWG). There has already been a lot of talk about what is wrong with the current state of 3D printer toolchains, what can be improved, and what should be completely ignored. Let’s take a look at what all of this has accomplished.
Continue reading “Drivers for 3D Printers and Why We Need Them”
If you haven’t been paying attention, FTDI, makers of one of the most popular USB to UART chips out there, really screwed up last October. They released a driver to Microsoft that would brick unauthorized clones of their chip by setting the USB PID pair to zero. This renders the chip unusable by any computer. That Windows driver has been fixed by now, but there’s probably still a good number of bricked FTDI chips out there. [Tony G] figured out how to fix it, and it only requires a few lines in the console of a proper OS.
The bricking Windows driver worked by setting the USB PID on fake chips to 0000. Luckily, there are ways to reprogram these chips. [Mark Lord] released a set of tools that will reset the USB PID. This unbricks the chip, fixing whatever device it’s attached to. It’s also a great reminder to either update or roll back your Windows drivers.
The old gen 1 Kinect has seen a fair bit of use in the field of making 3D scans out of real world scenes. Now that Xbox 360 Kinects are winding up at yard sales and your local Goodwill, you might even have a chance to pick one up for pocket change. Until now, though, scanning objects in 3D has only been practical in a studio or workshop setting; for a mobile, portable scanner, you’d need to lug around a computer, a power supply, and it’s not really something you can fit in a back pack.
Now, finally, that may be changing. [xxorde] can now get depth data from a Kinect sensor with a Raspberry Pi. And with just about every other ARM board out there as well. It’s a kernel driver that’s small, fast, and does just one thing: turns the Kinect into a webcam that displays depth data.
Of course, a portabalized Kinect 3D scanner has been done before, but that was with an absurdly expensive Gumstix board. With a Raspi or BeagleBone Black, this driver has the beginnings of a very cheap 3D scanner that would be much more useful than the current commercial or DIY desktop scanners.
Machinist, electronics engineer, programmer, and factory worker are all skills you can wield if you take on a project like building this omniwheel robot (translated).
The omniwheels work in this tripod orientation because they include rollers which turn perpendicular to the wheel’s axis. This avoids the differential issue cause by fixed-position wheels. When the three motors are driven correctly, as shown in the video below, this design makes for the most maneuverable of wheeled robots.
An aluminum plate serves as the chassis. [Malte] milled the plate, cutting out slots for the motor with threaded holes to receive the mounting screws. A few stand-offs hold the hunk of protoboard which makes up the electronic side of the build. The large DIP chip is an ATmega168. It drives the motors via the trio of red stepper motor driver boards which he picked up on eBay.
So far the vehicle is tethered, using a knock-off of a SixAxis style controller. But as we said before, driving the motors correctly is the hard part and he’s definitely solved that problem.
Continue reading “Omniwheel robot build uses a bit of everything”
The LED signs sitting idle on the left are brought to life by an Arduino replacement driver shown to the right. The big one is made by Signature Electronic and used as an advertising display like you would see in front of a business. [Bob Davis] picked it up on eBay being sold as non-working. After some power supply repair he set to the task of driving them with his own hardware.
The images he shared give us a good look at the parts used on the sign. The display area is made up of a set of eight 8×5 pixel LED modules. Each module has a key and slot in the top and bottom to help align the rows properly when building a larger array. They use TPIC6B595 shift registers (the same ones seen in yesterday’s low-res gaming hack) and 74HCT138 decoders to multiplex the pixels. Most of this info is shared in the second part of his post.
He hasn’t quite gotten the larger sign to run properly. Each row displays the same data but one pixel lower than the last. If you’ve got some insight on why this is happening we’re sure he’d like to hear about it.
[via Dangerous Prototypes]
Way back in March [Ch00f] took on a for-hire project to make a suit that lights up to the music. He decided to build something based around a pulsating EL panel. He’s put a lot of time and tried of a few different techniques, but he finally has a working EL panel dimmer.
This is a saga we’ve kept our eye on. The fall seems to have been good to him, after a failure using TRIACS he managed to adjust the brightness of some EL wire by messing with the current going to the driver’s oscillator. Standing on the shoulders of that success he designed the board seen above by getting serious about audio signal processing. There’s a microphone on the board which picks up sound which is then processed into a signal responsible for the brightness of the EL panel.
There’s a demo video after the break, but you’ll want to dig into his article to get all the gritty details.
Continue reading “Months of failure lead up to this EL panel dimmer that pulses to the music”
For those that grabbed one of these TM1638 UI boards you can now easily use it with your Stellaris Launchpad. [Dan O] took it upon himself to publish an ARM library for the UI board.
There’s not a lot of new stuff to talk about here. We’ve already seen this being driven by an FPGA. [Dan] also links to both an Arduino and an MSP430 library for the board. The one thing that is good to know is that the board seems to run fine from the 3.3V supplied by the Stellaris Launchpad.
The ARM chip has four different hardware SPI modules which could have been used to drive this display. But [Dan] opted to bit bang instead. This give him more flexibility, like easily changing the pin mapping and foregoing the need for external components. All it takes is direct connections from three I/O pins which are used for clock, data in, and data out. We’ve embedded the obligatory demo video after the break.
Continue reading “Stellaris Launchpad library to drive the TM1638 UI board”