me too i want one but it is going to have to go on the wish list for now.
So basically the same movie scene you were talking about, only the victim was strapped to the table face down.
This thing really has software thatâs top of the line. You can get cheap Chinese laser cutters off EBAY for about half the price and a bigger cut area. If you splurge you can even get one with a z axis. But, and it is a big but, the software that controls these things is awful. And none of them have any auto-alignment or auto-outlining or any of the cool features that the Glowforge has. Itâs probably worth it to get the Glowforge, but I wish theyâd made it with a bigger cut area and have a 60W or 80W option.
Not the bigger area but the K40-III is really pretty decent for the price.
Totally agree. The MoshiDraw crap is an utter abomination.
You can throw out the original controller board and retrofit it with one compatible with LinuxCNC or Mach 3. The steppers are quite small, I think similar to NEMA 17, so maybe even the controller boards with Arduino for 3d printers could do a good job here with just a small if any reconfiguration. Throw in a Raspi for good measure, and you can have camera and computer vision built right in.
A K40-III with lousy software and a handful of wart that we can afford is vastly better than a Glowforge we cannot afford.
The injury was compounded when she, enraged at the hapless ĂŠstheticianâs clumsiness, demanded that the salon manager âfire that asshole.â
Unfortunately, the data on their site make it remarkably unclear how well, or ill, this system works without âThe Cloudâ being involved.
They mention support for a variety of input formats(assorted standard 2d vector and raster), which is good; and mention plugins being available for assorted 2d design software; but there is a big difference between âyou can upload Standard Format X to our Laser Cloud and it will mogrify it into our proprietary control language and spit it back to your printerâ and âOur printer interprets Standard Format Xâ. Even the features like âtrace modeâ, where you just draw on the target material and the camera guides the laser, could be implemented either locally or by sending snapshots up and commands back down.
Nothing I could find definitively excludes the possibility of local operation; but nothing explicitly promises it, either; and apparently much of the new-and-cool about this device is in its control and feedback systems, so I could see aâŠtemptationâŠto keep the secret sauce in the cloud, rather than spending more on a beefier onboard controller and putting my fancy software in ROM where my competitors can trivially look at it. Even if that is the case, there might still be a degraded-offline-mode; but they donât say one way or the other.
Itâs a pity. Looks like a really cool device; but theyâll be skiing in hell before I buy something that wonât work without âthe cloudâ(unless itâs with the purpose of getting a good deal on hardware that I think can be brought back to the light by installing DebianâŠ)
If I can get some clarity on this âcloudâ business, Iâd definitely be interested, Iâve been coveting a laser cutter; but so long as that remains hazy, no dice.
I didnât even realize these little beasties are about $366!!! If itâs 40W, that means it has the raw capability to cut anything any other 40W can. The difference is going to be in air evac of burnt materials and the optics. If the optics are unfocusable, then itâll suck. But the price is right. I wish we could have the Glowforge for this price, or even double and it would be a deal.
Maybe @deanputney can clarify for us? Because I feel the same way.
Late last night, after the CEO was watching social media, he announced the firmware would be GPL, released along with the device, in order to ensure that should the âCloudâ vanish, youâre not left with a $2k paperweight.
http://glowforge.com/gpl-licensed-open-source-firmware-for-glowforge/
Hackernews had a thread where a lot of concerned folks echoed the same sentiment, and they announced that pretty quickly.
The creator of the thing also mentions that the laser they use is a Mode 0 (I think?) and that this allows a tighter beam than those used on many cutters. His argument is that a relatively small number of watts in a very, very small space cuts just a well as a much larger (but more diffuse) laser can.
So itâs a bit like looking at the output of lightbulbs only by their wattage and not by the lumens produced (the reason a 60 watt incandescent can be bested by a 6.5 watt LEDâŠ)
Grain of salt, YMMV, IAMAL, etc etc.
Mode 0 means that the energy density in the beam is Gaussian. Most in the center, less at the edges. That should be the case of any laser. If not, the resonator has to be adjusted. The sealed CO2 laser tubes should be already adjusted from the manufacturer, the resonators are their integral parts and the setting is not changeable.
The focus is the major issue here. With CO2 lasers, with their 10.4 ”m wavelength, the diffraction limit becomes a big problem. In practice, focusing to a spot less than 0.1 mm in diameter is pretty difficult to achieve.
If you want a finer resolution, you have to go for a shorter wavelength. Nd:YAG is the common choice, with its 1064 nm. Same limit applies in principle, just 10 times smaller. A 404 nm diode laser can be even finer, see the feature size on a Blu-Ray disc. With the Nd:YAG one you can frequency double or even triple it, to the well-known 532 nm green or 355 nm. With Q-switching you can shorten the pulses a lot, and get more ablative effects for less thermal effects as the energy comes too fast to the workpiece to be conducted away, even if it is fewer joules in pulse than when not Q-switched.
âŠand so onâŠ
Thatâs the major advantage of such device, and a long-term guarantee that the thing will be workable and serviceable.
Could be also possible to retrofit for other laser cutters on the market. (Read: hopefully my one.)
If the software shows up on github, even if itâs in parts and hard to use, I can foresee many nights up late hacking it into another laserâŠ
The alternative is using the Marlin firmware, with a couple mods, and with one of the Arduino-based controller boards. Very popular for 3d printers, shouldnât be difficult to reimplement for a conceptually fairly simpler laser engraver/cutter. There may be minor problems with the scanning/engraving mode, but that should be possible to alleviate by a long G-code command where the pattern for the scan line is submitted as a hex or base64-encoded string. If thereâs not enough RAM in the ATmega chip, an external SPI RAM could be used to buffer it; then there could be possibly enough space to even regulate the beam power in real time, for engraving reliefs.
Hey, we should test this. Is it easy to get a dump of what your laser receives? What are the specs on your laserâs board? That thing canât have a ton of RAM.
Itâs some microcontroller. The red-colored variant of the board used for the K40-III lasers. Used to be controlled via a parallel port, now reengineered to USB by adding a USB-parallelport chip. The chipâs datasheet will be the low-level protocol, then USB analyzer would tell more. But that may be needlessly complicated when just replacing the board for something better may solve several problems at once with less work because protocol analysis is somewhat tedious work.
The thing of course doesnât have that much RAM. I however like to have some wiggle space as I am getting older and lazier (which feels like more tired), hence the SPI RAM proposal; may not even be needed. And it is better to have a simple clean code than hyperoptimized clever one. The latter needs less resources, but is harder to maintain and modify and port.
Also, buffering the entire line will allow virtually no dependence on the host computerâs timing. If it gets too slow, nothing worse happens than a bit more delay between the scan lines.
We may be rounding the wheel. Hersâs another even simpler idea. Donât even mess with it. By that, I mean take the jpeg (or whatever raster image) and convert it to stl. Slice it and make sure thereâs just one layer and 100% infill, parallel lines. Then feed the laser the gcode, just like normal. Wonât even have to worry about a raster->3D processor. Do it in software and give the card what itâs already designed for.
Generating the g-code from the bitmap is the easy part, just go line by line. But we need to get the head moving in a steady speed, to have guaranteed energy delivery amount and rate to the workpiece. No acceleration nor deceleration within the head swing, and it goes fairly fast so the acceleration is needed. So accelerate to working speed, then once the line start is reached send the sequence of on/off commands with proper timing for the laser, then decelerate and advance to next line and repeat.
In principle, the direct g-code way would work. In practice, I have my doubt; it may work but it will be likely prone to all sorts of effects from the host computer speed to the individual machine type peculiarities. Better hack the firmware source and have a robust command for engraving.
Yeah, it is a different style of printing than vector. Maybe we could hack up old dot matrix controller code. If not, thereâs got to be a way. It canât be that hard. (famous last words)
Likely to be quite more difficult than just slapping a buffer into Marlin with a pointer that gets incremented and the bufferâs position value outputted to the laser for every n stepper motor steps.