One of the most unpleasant experiences with computers is having to solve a problem you already fixed when you
realize the old solution is no longer working for reasons unknown.
The problem this morning was quite silly, actually. One piece of code created a text file. I did not care much about the way newlines were represented but when I sent the file to to a colleague that uses Windows he complain notepad was making a mess out of it.
It was clear notepad was doing this because my file, created on a unix system, did not honor Windows end of line convention of CR plus LF characters (0x0d + 0x0a). I have solved that in the past just changing the System property called line.separator. You could do that with System.setProperty("line.separator","\r\n") but apparently not anymore. Of course, no error message or exception is raised, so you are left alone, in the dark, trying to figure out what is wrong and why what worked before does not work now.
I could not make much sense out of it, but I hate these changes that make me waste my time for no known good reason. It just seems the JVM ignores my changes to the property, still named the same way, for the same purpose. It vaguely mentions that a SecurityManager might be needed but I did not explore the problem further, I just learned that, without changing the code, I could use java -Dline.separator=$'\r\n' MyProgram to get it working with the new value for line separator property, so I did and got the problem solved, or almost all.
A few lines of my text file came from a configuration file that, again, did not follow Windows convention. So as I wanted to get the problem sorted out for all the lines and not only those generated from Java code, I had to figure out how to, easily, use vi to replace the LF end of lines by the real deal CR LR. I guess I did that once or twice years ago but I could not remember how to do it now. Long story short: %s/\n/\^M\r/gand please note that for obtaining ^M you need to press Ctrl+V and then Ctrl+M. I am thankful the backslash preceding ^M was mentioned in stackoverflow as its need was unclear to me.
A simpler way of getting a Windows-friendly text file from vi is to use the command :set fileformat=dos
When I was a teenager I was an avid reader of electronics magazines. What was available at home at first and later what I could afford. I remember that my favorite ones was Elektor magazine, that grew from a German-only magazine to be distributed to other languages and countries, mine included. They have this great summer edition that included over a hundred different small circuits.
Over the years I have almost stopped buying magazines (not because they are bad but because they use shelf space and I have not much time to read them). The last paper copies I bought were from Circuit Cellar Ink, but these same guys decided that a digital edition will ease their business, and for those abroad it will be be much cheaper. Selling bits is a good idea that seems to be making Google and many others much good. I even wrote several articles for Circuit Cellar magazine about different projects I made.
A few years ago I learned that Circuit Cellar Ink was acquired by a European group that handled Elektor magazine too. I was invited to a couple of meetings in Germany, together with other international authors, where the future of magazines was discussed. I guess there is an ongoing battle between paper and digital copies, the latter being painfully easy to copy. But at the same time, I found myself not very happy with the way I would browse a digital magazine.
Business like Zinio pop up, offering a better protected distribution than just a bare PDF, but as a I user I always felt these DRM platforms will make my accessing to the content I paid more difficult should I have to renew my computer.
When nobody expected the iPad, the tablet revolution brought a new type of computer that was definitely more friendly to be used for browsing magazines. Apple saw the opportunity and created their own news stand on the Apple store. Later with iBooks they offer an easy tool to create richer documents, but being old fashion I am closer to PDF format for magazine contents. Google did a similar thing for Android.
For me, what is wrong with browsing a magazine in my computer screen is the latter, I mean the screen, which is exactly the wrong format for portrait magazine content. Unfortunately, the first iPad did not worked well with the PDF files that I was receiving from Circuit Cellar magazine at the time.
But I am writing this today because I found myself browsing an Elektor magazine PDF on a not so new Samsung tablet with no problem at all, while sitting on the coach. It is definitely a much better experience than using a modern laptop with a beautiful display but with the wrong format for the content.
So for me, the tablet is the right interface for magazine content and I love it because no matter how many issues are stored, it does not grow my shelf space needs!!
I was asked to be a beta-tester of this new machine sold in kit form by Spanish firm bq. It's a bit hard to keep the experience to myself while the testing was taking place. I won't say it is great and rosy but their approach was a bold one and I think it stands out of the crowd.
So what is it?
Hephestos 2 is a 3D printer kit to be assembled by the user. While it might find its routes in Josef Prusa iteration 3 model, this time it is just a faded image. That was entirely the case with the former Hephestos that shared most of Prusa i3 features with a few of exceptions: no heated bed, a couple of cable chains and a very well engineered extruder/hotend combo.
But the Hephestos 2 breaks with the Reprap tradition and includes no printed parts and a body made of powder colored folded metal parts. Only Y-axis uses 8mm diameter smooth rods and linear bearings but Z and X-axis use miniature Hiwin linear rails for extra accuracy. A new electronics board integrates an ATmega 2560 plus five DRV8825 drivers with electronic current control (no potentiometers to fiddle with) and a large LCD monochrome graphic display that enables autonomous printing off an SD card.
Not having a heated bed keeps the power supply requirements low so a brick type power supply comes with the kit. By the way, the bed is A4 size (297x210mm) and max print height is said to be 220mm (I haven't printed parts that tall).
Firmware is based on Marlin and source code should be available and it uses a custom-developed inductive bed sensor for automatic bed calibration (tramming).
How it works?
The machine prints PLA very nicely at 40mm/s and Filaflex at 25mm/s. Both speeds can be increased by a fair amount and still get decent prints. The machine insists on doing things its own way so those of you with another printer may wonder why homing requires heating up the nozzle, but these are minor details (that are in fact done for a reason).
Printing quality has been great in my opinion but what captured my attention mostly was the extruder/hotend combo that is even better than the former Hephestos, now with a dual hobbed gear (a la Bondtech, but direct drive).
Printer is not noisy but at a point extruder fans are.
There are some quirks in the beta firmware that made the time between prints not not very reliable, but once a part started printing it always finished ok. I have been using hairspray on the glass bed with great results, but I have not attempted parts with are really large base. I would prefer to have a choice of heating up the bed but I have got excellent results with the cold bed.
What about the build process?
Let me start by saying that my build was a bit of a mess because it started before the manual was available, so I made a few wrong guesses that I needed to undo later in the build. I have been told a trained person can do it in less than two hours (and this has been shown in the product presentation) but I would say it can be done in a morning or evening by one person, though it is always better if you get some help (I was lucky my friend Ruben helped me out and despite all my mistakes the printer was finished in less than four hours).
I cannot elaborate on the final user manual but the document I used was very detailed so I guess people would have no trouble building the printer.
The electronics is well thought out and using a combination of color coded calbles and different types of sockets we got a working printer at the first attempt (almost, I messed up the z-probe, but that was again my mistake).
I just loved the fact all the wires were already inserted into the cable chains. The bed is held by two quick-fit levers (getting them into the threads was most likely the more difficult part of the build).
I will not doubt for a second to name the Hephestos 2 a quantum leap from its predecessor. It feels solid, it looks good and, specially, it prints beautifully.
Bed is large and that allows large objects to be printed but it means more mass is moving too, and it is not light, so the machine will not be a speed demon. The printer looks good and has a clean design, electronics uses no fan and it can print from SD or from USB.
Unfortunately I have not been able to use it with Pronterface or Slic3r but used Cura instead that was the manufacturer's software of choice. I tried not to create more noise during the beta testing of the firmware but I hope the final version will play nicely with these fine programs too.
Did I say it prints Filaflex great, let me say it again. If you are for printing flexible parts mostly, look no further, this is your printer!
The code I developed a while ago for using a DC motor (or a BLDC) to replace a stepper has got quite an interest among youmagine users. Over time I realized that some of the quick and dirty things I did were preventing the easy exploration of system parameters for users. Using different PID parameters required a recompile and of the sketch.
I recently received a Printrbot Simple from Brook Drum with the goal of testing with that printer my closed-loop solution. As usual, simple things (in theory) become tougher that initially expected. First of all, it took forever for the printer to clear through customs and while Printrbot provided and shipped the printer for free, the taxman wanted its cut no matter what, and it took more than too weeks for that to be worked out.
We settled on the Simple because it had more room for the motors to fit in though carriages might be heavier than the Play.
At the time I did not know the CAD of both models was available on Youmagine, so I only had a vague idea of the potential problems of fitting the DC motors I was planning to use on each model.
Once I downloaded the Simple CAD model and imported into Onshape I was able to redesign one of the plates so it will fit the DC motor instead of the stepper.
That part will help attaching the motor to Y-axis of the Simple but there was no may I can make that while I keep Z-axis threaded rod in place. They do that with the stepper because it has a long shaft but that is not the case with the DC motor I am using. Ok, time to think about it. Maybe I will use some fishing line and a couple of pulleys to have a crane-like Z-axis. For now, let's focus on the drive. While the original part was made of metal, I though I will save some time just 3D printing that part. On hindsight that was not a wise move as the plastic part does not help motor heat to spread to the rest of the metal body, so heat becomes a problem.
I knew that the axis was heavy so the first test was to determine whether or not the motor could handle the load. I learned that 12V might be a bit on the low torque side but a few more volts in the supply voltage will make the same tiny motor to get much more authority. Same driver electronic could do with a higher voltage so no big deal.
Next problem was to replace the axis belt as unfortunately my motor came with MXL pulley. I managed to get an acceptable setup, but due to my pulley lacking a belt guide I later needed to add a big washer to one of the bearings so the belt could not derail on fast moves.
But once everything was up and running I realized how inconvenient was to need a recompile every time I wanted to test a new set of PID parameters. So what I did was to include some additional serial commands so I could set parameters on-the-fly using the serial port.
And then, I realized that once you have set the right set of values, it will be great if you can save them so they are not lost when you power cycle the controller. EEPROM was the logical choice and after a bit of fiddling with the EEPROM library (as I have an old iMac I cannot update due to a SMART harddisk error, which forces me to still using an old Arduino IDE) I get the thing working nicely.
Not only you can select P, I and D values, but you can also check current encoder value, output value and target location, command manual moves or set a sequence of random moves, plus you can store current parameters into Arduino EEPROM so next time you power it on it will remember them.
While all previous code was just uploaded to youmagine, this time I created a github repository so hopefully that will make collaborators life easier.
Meanwhile I still need to figure out how to get another DC motor to X-axis.
One of my current projects requires to run two, maybe more in the near future, DIY CNC machines. Machine controller is USB-based and a PC could be used to send g-code to machine controller.
However, we have tried a different approach that proved successful: using a cheap tablet instead of a PC.
It all started by testing the excellent program GCodePrintr by Mathias Dietz. This software is designed so people can use a 3D printer directly from a tablet. You can stream a g-code file for printing to the printer plus you can do all the usual manual functions of moving the axis around. Besides, a graphical simulation of the print is represented on the display. And in the few tests I did, printing speed did not seemed to be compromised because the lower tablet performance (compared to a PC).
However, uploading a file from Dropbox or using some FTP app for sending g-code files to the tablet was not very convenient as required user time spent at the tablet. But one feature of GCodePrintr came to the rescue: There is a Network Receive feature you can use to send a g-code file to the app. It needs to be enabled in the program configuration and it uses TCP port 53232. Once that feature is enabled you can send your file to the app and in a few seconds it can be received via wifi.
That was almost all we needed. However, the app will show a dialog box after receiving a file from the network asking the user whether they want to start streaming the file to the printer right away. That was a problem because still some user action was needed at each tablet. I suggested the developer that a welcome feature would be to add some special data to g-code file so the user intervention could be removed at will. Fortunately for me, that was something it was already taken care of in the software. I just needed to send some magic bytes before my g-code file for triggering the automatic start feature (now without user intervention).
So what was left was to create a simple way for the operator to send files to our two machines. Operator was using a Windows computer (not my choice though). So I created a couple of bat files on the desktop in such a way that operator will drop the desired g-code file on the desired machine's .bat file (named after the machine).
What each .bat file does is to send the file contents using ncat software (netcat did not work reliably for us) and it inserts a new record in a sqlite3 database to keep track of each one of the files being processed for accounting purposes.
So now the operator just replaces the stock material on each machine and drags a new file onto the machine icon to get a new job started. Database registers the start time-stamp of each job so a good estimate of each job duration can be obtained.
Initially the program, being designed for 3D printing, did not allow "bed" sizes large enough for our needs nor it will properly draw G0/G1 non-extruding moves. However all this has been fixed as the developer has been very receptive to these suggestions for this new use case of the app.
A similar solution could have been done using Raspberry Pi using Octoprint but without an additional keyboard and local display the manual operations, when needed, could not easily be done locally.
Please note that a 3D printing farm could use the exact same approach, just connecting a 3D printer to the OTG USB adapter of each tablet.
I needed for a project some metal holder plates for nema 23 motors. As I have in the lab a Chinese 6040Z CNC router I thought it will be an easy thing to do. Oh boy, how wrong I was.
They project was a simple plate (very easy to sketch using OnShape).
Once it was sketched a 3D part could be created by simply extruding it, which may come in handy if some drawing assembly needs to be done for documentation purposes.
However, for 2D projects a 3D model of the part is not really needed for the process of creating 2D machining code. There are different solutions out there that are free, but one that I like because it is very simple to use and it is on-line is makercam.com but for that you will need an SVG file instead of the DXF that OnShape can easily produce.
I usually use Inkscape software for converting to and from SVG and DXF. I did so in this case and it work as expected.
So, once I have got the SVG file I can feed Makercam.com I need not to forget to change the default dpi value from 72 to 90 otherwise my part scale would be wrong. You need to select each line to decide which machining operation you need to perform. For this part I chose inside profile operations for all the holes and one outside profile operation for the outer profile of the part (it is important that one is done at the end, other wise your part will be cut loose and you will be in trouble with the rest of the machining until figure out a way to keep the part still).
With the profiles select you perform the desired operations and eventually generate on or more machining (g-code format) files. These will represent all the different movements of the cutting tool. Here you specify the height of the stock material and the depth of every cutting action. You will specify the feed-rate for cutting and non-cutting moves too.
Finally, using some software to send the g-code to your CNC machine you command the cutting tool to do exactly what the CAM software planned and, if you are lucky, you will obtain the desired part out of your stock material. In my case I was using aluminium and a CNC machine controlled by LinuxCNC software.
Unfortunately it was a no go, as something in the computer would make the x-axis motor to stop working every now and then (I was told maybe the BIOS setting of the port was wrong, but I gave up and use another computer).
Second computer was using Windows and Mach3 software and though it gave me some trouble with the larger holes (where my tool would be caught and x-axis would lose steps, but somehow I managed to fix it on the fly). But at the end I finished the parts with some sense of achievement.
Even when the parts were finished from the CNC machine some other manual processing was still pending like taping some holes and filing the edges. But all in all, it was a good experience.
I do have some CNC routers using Arduino Mega and Marlin as pulse generators and g-code interpreters. Usually they are connected to a computer for selecting and streaming g-code files to the machine.
Lately I was testing a new machine and I found an old Android tablet laying around, so I wondered if it could be used for the task of controlling the machine. I am aware of programs like Octoprint that can do exactly that using a RaspberryPi and I have seen it does a great job. However, unless some more hardware is added to the mix, no display or user input is possible. But a tablet already has the display and touch screen that can be used for that purpose, plus Wifi and Bluetooth for wireless communication. What was needed was a USB connection but for that a cheap OTG USB cable was all that I needed.
Well, once the hardware side is solved, you need some software and after checking and testing different options I ended up with GcodePrintr. A software that is designed for controlling a 3D printer that will do a nice graphical representation of the printing commands too.
The best thing is that though the program is not free, there is a version called GCodeSimulator that allows you to test your setup but will not send a g-code file to the printer (or CNC).
So I bought the program and it all seems to be working as expected even though the size of my "bed" is much larger than the graphical presentation allows, but that is not a big deal for me.
Have a look at some moves streamed from the tablet: