Since I got a beta version of Hephestos 2 from BQ before its launch, I have been using that printer more and more. After the initial annoyance about doing things on a certain way (like heating the extruder before performing a home move on an axis) I have got used to these details and I do not care anymore.
And with a few exceptions were a part bottom failed to stick to the bed (nothing that a bit of hairspray could not fix) the printer has been delivering consistently quality prints. Z-axis became a bit noisy on long moves but I have no other complaints.
However, all the time I have been using PLA or Filaflex on a cold bed. There is no provision for a heated bed add-on so I had a look around for a stand-alone temperature controller. I have found a simple pcb unit with display that controls a relay for a heating load up to 20A. Not sure how long that relay could last but for less than $5 I am going to give it a try.
Next the bed, I do like aluminium beds with power resistors epoxied to the bottom. In this case care is needed to take advantage of the holes in the bed holder parts so that space could be used by the resistors without losing more than a few millimetres of print height.
Just for testing I fixed the bed using kapton tape. I was not sure on whether to use the same clamp mechanism used for the standard bed, so I reckon I will use metal bulldog clips on the sides. This new bed being metallic too works ok with the inductive probe used for automatic bed tramming.
The only other change needed was to adjust the bed offset for the new bed before starting to print. Next PLA printing at 50C worked without any trouble.
And so did the first sample print I did on ABS. But I have to kill that after a few layers because the bed was wobbling back and forth as only a few kapton tape was fixing it to the bed holder. Next day I will fix the bed properly to the carriage.
Of course for this bed, equipped with 4 25W power resistors, and disipating around 120W an additional power supply is needed. I used a 12V 300W power supply I had around. 12V are needed to power the temperature controller and I am using 12V for the heating element too.
No electrical or logical connection with the Hephestos 2 electronics is needed. Of course that also means that nor the printer nor the host software has a way to switch on or off the bed or of adjusting the temperature. All of this has to be done manually by the user.
I am working on an Art project that requires some radio-reception capability on a Raspberry Pi. I available online. But given the local nature of the data I need to treat this time I have to use a local receiver.
have used in the past some interesting website that feature an SDR device whose reception is
One suitable device I found very inexpensive are DVB-T USB dongles originally intended for watching Digital TV on a computer. These dongles can be had for less than $10 on eBay. The good thing is that the chipsets employed are Linux supported and there is a bunch of usefulsoftware that can use them as a Software Defined Radio (SDR).
What is SDR? Well, basically it can act as a multipurpose radio scanner for many different purposes as spectrum usage recorder, amateur radio receiver or just listening to FM radio or airplane ADS-B transponders. For that latter purpose there is a cool program called dump1090 that will receive and decode the messages of the airplanes' transponders reaching your receiver.
After watching a video of a new pen plotter made by Evil Mad Scientist we wanted to have a similar device.
And having a 3D printer at hand plus some CAD software like Onshape or Fusion 360 it was a good exercise to design the whole thing.
As usual the process was not completely straightforward, as initially it was more about copying the model we saw but as things were coming together some new ideas were explored. So while the first mock-up was based entirely on laser-cut parts (some of them glued together to make them thicker as the crappy laser I have access to is really depth limited as it is low-power). Why laser-cut? Well because it was faster (or so it was supposed, but don't get me started on that).
Once the first model was put together several ideas pop up: First, motors are in the way of carriage motion and reduce a bit carriage travel along smooth rods. Second, motors require another part that could be fused with the machine feet and rods support. Third, the initial belt path created non-parallel belt runs that will cause poor accuracy and variable belt tension, so central carriage needs to be revised.
Eventually, the model became more and more made of printed parts and once published there have been more ideas pouring in from some of the readers, like an easier to orient pen holder that already replaced the original one.
My initial approach was to try to imitate the design and tools of AxiDraw but then I learned they use a PIC-based board that I do not have around and that it will take a while till I get one, but I had Arduinos laying around instead, so it was settled my plotter would be operated by Arduino. A CNCshield a friend gave me away (thanks Ernes) could hold a couple of stepper drivers to control the machine.
A logical choice was to use GRBL firmware but a few details needed to be solved: this contraption is not a regular cartesian design but it uses a single belt configuration called H-bot. From the math point of view h-bot and corexy work the same so I was happy to learn the latest versions of GRBL do in fact support corexy. That was one thing solved. The next one was that I needed to control a servo por pen-up and pen-down movements. For doing that I learned that robottini's version of GRBL could do that too. So another need was solved too and firmware was settled. You can use mine. Servo is controlled by M3 and M5 commands.
So my drawing machine will receive drawing commands as g-code but, how is that drawing code being created. I looked around and what was designed for AxiDraw was an Inkscape plugin that would create code suitable for the board they sell which is nothing similar to the g-code mine uses, so I had to use something else.
I learned about several projects for outputting g-code for laser cutters from Inkscape. I settled with one plugin that seemed very powerful not only cutting but doing raster images too, but intended for a laser cutter. The good thing was that output was g-code, so I had to hack my way to adapt it to draw with a pen. After some struggle I manage to get a stable response.
The problems I faced were that pen up and pen down commands took time and I needed to add an extra delay so drawing would be ok. Where original plugin controlled the laser output power I just needed to set the pen down so lines would be printed. It took a while but now it is working nicely.
If you wonder why there is a 608 bearing on the pen carriage which is not present in the CAD files it is because it adds a bit more weight so the ball-pen will draw a more consistent line.
Once the g-code files are obtained, in my case using the Inkscape plugin, another tool is needed to send the file to the drawing machine. I am using a Java-based program called Universal Serial Sender that does the job brilliantly and it includes a preview and a live view of the print too.
That makes the whole workflow based on open source software that can run on any operating system you are using.
Some of you asked me why the 4xiDraw name: well, AxiDraw is a registered trademark and FreeDraw was already taken too.
While the Wire library allows you to get I2C working right off the bat with Arduino, there are times when the built-in Wire library does not do it. For some people this happens because they need to do a repeated start condition or to receive a large number of bytes, tasks that seemed to be not possible with Wire library. But for me the problem this time is a bit odd: I had to overcome the limitation of each I2C device to have a different address.
It turns out that I am using a magnetic encoder chip that responds to a given address that cannot be changed. Because I want to be able to access at least two similar encoders from on Arduino board I find myself in the unlikely situation where I have to use two different I2C buses, one per device. However, I2C interface was designed to do the exact opposite thing, allowing several devices to communicate over the same bus (provided each one had a different address of course).
As second detail I have been interested is to speed up the communication, as the current request takes almost 1 millisecond (to read a 16 bit number). It may not seem much but as I wanted to keep a constant frequency of 1Khz on my main loop, that reading time was definitely too long. When using the Wire library I learned that setting TWR=1 will offer me the fastest communication of about 170 microseconds, so that problem was also taken care of. But I still needed to get a I2C second bus running.
There are several Soft I2C libraries for Arduino, but the one that worked for me is the SoftI2CMaster, which I could see is available as simple C library or as C++ class wrapping it all nicely. I settled with the former that hopefully gives me an edge in communication time. It all should had been very simple if somebody told me I should shift left one bit the address value, but because I did not know that, I wasted a couple of hours till I figured that out.
Once set properly, the library allowed me to read one sensor value in 164 microseconds. The code below reads one angle value from the AS5600 sensor using this library.
So now, even if I read two values, one from each sensor, it will take me less that 400 microseconds, leaving room for additional processing while still keeping my 1Khz loop time. Now I only need to figure the same out for other platforms like ESP8266, Nucleo STM32 and MKR1000.
A recent update of Chrome brought me some trouble with various web content, including PDF viewing. Apparently some change in how layers are handled makes the viewing of PDF content almost impossible: you see some bars of the underlying PDF file but only as a flicker while you scroll down the document, as if some black layer was on top of it.
A quick check online revealed that many people using OSX versions before El Capitan were complaing about exactly that same thing. And while Google seemed not to be offering a solution at the moment (and upgrading to El Capitan was not something I would like to do right now) some users suggested that disabling hardware acceleration in the browser would help.
However, disabling hardware acceleration might solve this issue but create other problems with other content or just degrade browsing performance, so I did not want to go that way either.
Finally, another user suggested the install of a browser extension (in fact replacing Chrome's built-in PDF viewer) for PDF content. I selected the most popular one, called Kami, and not I am capable of watching PDF files again. Not ideal but at least it did not take me forever to get a fix.
And if Chrome engineers are listening, please fix this ASAP as PDF viewing is an integral part of most modern browsers.
Unfortunately, there are some videos from a newspaper that are experiencing the same type of problem, luckily most of them are for advertising so I will not miss them, but I know there are other problems related to the same cause that might become a problem soon. Update: I have just installed Versión 49.0.2623.108 (64-bit) that fixed the problem.
A couple of ideas for right corners with 20x20 extrusions
Some aluminium extrusions are quite convenient for building various types of structures. Manufacturers usually have a lot of choices when it comes to making unions. However, you not always have the time to wait for a part to be shipped to make a connection. Other times it can be done more cheaply and easily if you can use a drill.
For certain 20x20 profiles, I have used an M6 screw to make right angle joints. The inside hole of the extrusion needs to be tapped and an additional hole will help for tightening the screw with an allen tool:
For my closed-loop control project I considered brushless motors to be a superior choice but the lack of affordable models in the marketplace let me down a bit.
I was able to find some cheap models on eBay but those were lacking of built-in encoder and my attempt to add them one was a bit of a mess: the optical disk and sensor require better alignment that my poor skills could provide, so it ended up not being reliable. On the other hand, most DIY can get a small part 3D printed and my previous tests with magnetic encoders encourage me to use them more often. So I took some time to tinker with a motor from Nidec and how I could get an encoder attached in a simple way.
The end result is what you can see in the picture below, that just consist of a 3D printed part with three fingers that attach to the back of the motor's plastic cover notches.
You can see in the picture below the hole in the plastic box through which a small plastic part holds the magnet to the motor's shaft (a drop of superglue helped here). A small carrier board in the center of the plastic box keeps the sensor IC close to the shaft's magnet.
One of the unexpected benefits of using a brushless motor is that this one came with a built-in driver, so there is no need of additional electronics besides the loop controller. In this case I keep on using the ESP12E (or NodeMCU) that Mauro Manco kindly provided me a few weeks ago. But this time the part gave me some pain too. It turns out that PWM was not always giving the right output. it is is a software-based PWM and I was getting all the outputs for 8-bit PWM right except the value for 254 that turned out to be the same output as 0. That won't be a bit problem unless your motor's PWM input is inverted, like this motor I am using. Long story short, I had to lower PWM frequency to 10Khz to get it working ok.