Fighting with computers

Computers are not always friendly.

Tuesday, September 15, 2015

How to do a CNC milling farm.

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.

Happy g-code streaming!

Monday, September 07, 2015

Basic 2D CNC milling workflow

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 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 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.

Monday, August 31, 2015

Using a tablet to control a CNC machine

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:

Tuesday, August 18, 2015

Closed-loop motor control for 3D printers

It is been a while since I brought this topic in my blog. I recently bumped into this thread on element14 about the same topic too.

I was naive enough to assume that what shows up on eBay or Aliexpress can be available for quite a long time. It appears that some the units just pop up for a while to never be seen again. That has been the case with some of the motors I have been doing tests with.

Since I realized that steppers could in fact be replaced in our 3D printers by a closed-loop DC motor I have been tinkering. One of the key ideas was to find a steady supply of motors that would enable anyone interested into building the same contraption. And while the brushed motors I used worked as expected and were cheap enough, they seemed a bit too weak (not enough torque for higher accelerations) and I was quite worried about how long they will last.

On one hand there is the argument that if inket printers replaced steppers by closed-loop brushed DC motors, we could do the same and get away with it. After all, how many of you have needed to replaced a DC motor on any of your inkjet printers because their brushes were wear out? However, if you have a look at how inkjet printers work you will notice not much in common to how 3D printers (I mean FDM ones) work.

An inkjet carriage moves from side to side of the paper at a [constant] speed while the readings of the optical stripe help the processor to trigger the inkjets to spite ink at the right spots.  Each movement comprises the whole paper width and takes a few hundred milliseconds. Therefore there is one or two full cycles (start-coast-stop) per second while the printer is active. Each start/stop operation will require the motor to receive/deliver a significant amount of current for a few instants while motor is accelerated (or decelerated). It is these high-current operations what will put more stress on motor brushes.

On the other hand, a 3D printer moves each axis by tiny bits whenever a part is being printed. Each movement will required the motor to accelerate and decelerate (sometimes till reaching a full stop) before the next movement takes place. Each one of this little movements can take as tens of milliseconds or more and usually they are fused in such a way that carriages do not need to fully stop between them. But that means the closed-loop position control is putting several tens of start/stop operations per second on the motors. If we use similar brushed motors as the ones present in inkjet printers, it is expected to see their lifetime to be definitely much shorter in this new role.

Therefore, I decided that most RepRappers will be disappointed with a "new" closed-loop DC motor if it only lasts for a few months before motors had to be replaced. Specially when stepper motors usually last forever (or almost, in most systems). Steppers do not have brushes, so unless severely overheated it is the lifetime of the bearings what limits its service life.  If we use brushless DC motors instead of brushed ones, we can get a similar lifetime as stepper motors.  However, brushless motors are usually more expensive and they need more complex electronic drives.

I found several models that could work and while not ideal, they were more than powerful enough. Unfortunately, just a few weeks after I bought some samples they became unavailable. Still I was kind o happy with the results but realized no other people could use the same solution as the model could not be obtained anymore.

I contacted some manufacturers, most notably Nidec, which has some very interesting units, but the company seemed not to have any interested on talking to me (I guess their business is good enough to turn down sales of tens of units per month, as that was the projected sales figure in my request).  Other manufacturer had very nice motor prices but above $60 which looked to me a difficult pill to swallow.  Maxxon can create custom motors to fit all you needs but you may be willing to pay their price.

I had more luck talking to smaller companies so I settled with a Taiwanese motor manufacturer that was brave enough to explore this application space with me. So as you read this a sample brushless motor is being develop and the goal is for it to be able to replace at least X and Y axis in RepRap 3D printers while it can be directly plugged in to regular electronics (you remove the Pololu and plug the motor cables in).  A setup process will be needed before we can obtain the most of the new motor, though we will try to have an initial configuration that may allow most people to skip setup process.

Working together with a manufacturer, cost has been all the time a priority, as I want this to be available at an affordable price. After all, you can do this right now if you buy a brushless motor and a driver electronics that could accept step and direction inputs.  The problem is these available solutions will easily cost $150 per axis or more. You can buy ten steppers and their driver electronics for that price, so to me that is not a choice and I do not see any conversion to happen at that price range.

I have moved away from optical encoders and I am currently testing magnetic encoders that hopefully will give us a higher angular resolution (12 bits) at a lower cost. More on this once we have a working unit.

Tuesday, July 28, 2015

Minimizing tool air-time

For a CAM software I wrote, intended for milling foam sheets, I needed a way to improve machining time, so once the feed rates are raised to the limit, the next step is to reduce any wasted time.

On an initial approach, our tool was finishing parts one after the other, so there was a bit of the tool going back and forth within the same part. While it may seem the whole problem is like a big TSP (travelling salesman problem) and the way to optimize the used time is to connect all the dots with the shortest possible path, it is not exactly so.

On a milling operation, the tool path has been carefully calculated so it will remove the proper amount of material by following a certain path. Changing such a path will alter the finish of the part and we do not want to go there.

So what we really have is something like two different sets of movements, one that corresponds to the actual cutting operations and a second one that moves the tool over the air to start a new cutting operation. It is that latter set of movements that can be approached as a TSP without affecting the quality of the CAM output.

Many CAM operations require removing material as a sequence of steps or layers, the order of each layer needs to be preserved as explained here.

But I am lucky our process just go straight to the finishing pass as the tool can machine the whole stock depth in just a single pass (don't try this at home).

So what I have done is to rearrange the different movements between each milling pass so the total distance is minimized (though I am just using the simple 2-opt heuristic that most likely won't lead to the best solution but to an acceptable one).

I have got the idea from the StippleGen2 software I downloaded from Evil Mad Scientist Laboratories blog.

The lines in red correspond to the actual milling operations and are not changed and the grey lines represent the ones that we are trying to minimize but carefully rearranging them.

Saturday, June 20, 2015

Importing OpenSCAD designs into Onshape

After using Onshape CAD software for a while I am really fond of it. So one natural thing to do, specially once they have released the Instructor's kit is to start using it in the classroom too. But one thing I was not so sure how to do was to use old designs I made using OpenSCAD.

It does not mean I am completely quitting using OpenSCAD but suddenly I can see I can do assemblies in Onshape that will look quite nice for showing and documentation purposes if only I could easily import from OpenSCAD.

I am glad to report that the route OpenSCAD --> FreeCAD --> Onshape worked brilliantly. Even more when a few tricks were applied. While some people suggest to import CSG files from OpenSCAD to FreeCAD, I have had more success by directly importing SCAD files into FreeCAD. One trick that worked well for me was to get rid of $fn references, so now circles become real circles (or cylinders) in FreeCAD.

If a part keeps some $fn references then your cylinders or circles will keep the desired number of facets, which may be the desired intent in some cases.

This workflow: import .scad file in FreeCAD and export it from there as .step file will create a STEP file that Onshape will happily import into a part studio with no further intervention on your side. 

Once this process is done with all your parts you can easily create an assembly of your machine in Onshape, including rotating and sliding mates that will allow you see your mechanism in motion.

Saturday, June 13, 2015

Decoding barcodes from scanned pages

A while ago I created a tool that would send the marked exams to my students by email. I used adhesive stickers with a QR barcode they put in the first exam page once they are done. The system kind of works and even some colleagues have started using it too. The problem is that once we have the pile of marked exams scanned as a single PDF file, barcodes need to be read reliably.

It is not that the scanned images are bad. I usually scanned it at 200dpi grayscale. The problem is that even if I set the black to the strongest setting is not good enough for ZXing library to decode it properly. And of course if the code is not decoded properly all the system goes under.

For a while I have been cranking up the black color using Imagemagick command line tool and when that was not good enough I realized that blurring the document would also helped. While I get that working, the exam itself became not so nice to read after that.

Anyway, after a bit more of testing I realized that the slight imperfections on the dark areas of the barcode seemed to be the cause of not being recognized properly, so I did a quick test with The GIMP to see if Erode operator would help here.

Erode will use a mask around pixels that will keep the blackest neighboring pixel, effectively eroding white pixels, mostly those surrounded by darker pixels. A blur operation later would make the result even better for much more reliable recognition.
So the question was now to just do this in an automated way. As I was already using ImageMagick I googled to see if that feature was available in it. But several posts on different forums suggested it was not possible.

So the next few hours I fought with The GIMP command line mode. It is there, it can be used, but I am embarrassed to say I kind of gave up as I failed to see how I could do that quickly and easily; after all I just wanted to use a couple of options of the filter options (erode and later blur using default parameters). Some examples I found online did not work at all with 2.8 version, maybe something has changed since they were written. Finally I decided that it might just be easier to code that in Java.

But just by chance, I discovered that what new versions of ImageMagick call Morphology Methods do, in fact, include an erode operation. So finally it is all good and I get a, hopefully, reliable barcode decoding.