Fighting with computers

Computers are not always friendly.

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.

Sunday, May 31, 2015

Making sense of toolpaths

On my CAM project I am using the intersection of a part with a given plane to determine later the proper tool-path for three-axis machining. But sometimes, parts are such that the intersection line contains some concavity.

So I detect whenever the tool cannot reach that line and create a suitable solution. In the picture the red line in the top removes any concavity as seen from Z-axis top, converting that polyline into another that might be machined from the top.

It is interesting to note that one extra point needed to be created and appears marked with a dashed circle, though strictly speaking both bottom corners of the red line are new points too, but they are not over any of the original polyline space.

A second problem appeared once I obtained not one polyline but several of them as a result of objects that contain holes or several domains with respect to the cutting plane as it is shown in the image below.

In this other case, the different polylines need to be consolidated into a single one, that will ignore the holes (as the gray one) contained within another area and that will join the polylines that can be joined (which may or may not be possible depending on whether or not they overlap in the sweep direction). Again the red line will be the result of combining the three different polylines above.

Friday, May 01, 2015

Getting the hang of it

I have been using for a couple of weeks the web-based CAD system OnShape. I did this robot just as test to see how to use the different tools.

I have been using OpenSCAD for quite some time and I was not very keen on using some fancy CAD systems like Inventor or Solid Works because I could not afford them but also because they would force me to use Windows, which I prefer not to. But even if AutoCAD can do OSX besides Windows, I do use Linux most of the time.

So when I learned that there was a new game in town that was based I was first skeptical that a browser could to the job, but after some testing I am now a believer. And I love to be able to jump from a Linux workstation to a Mac to continue editing my designs.

The free version of the service has certain limitations in the number of private projects you can have, storage and something else, but given the fact that can not only import but it exports to popular CAD formats like STEP or IGES it means your work is not locked in. And the easy export to STL makes it perfect for 3D printing (it can also export 2D sketches to DXF equally easily for laser cutting parts too).

I am by no means a CAD expert so maybe some important features are missing but it seems these guys really are experts in the field. If you liked Gmail, I would say this tool is to CAD what Gmail is to email.

Friday, April 17, 2015

Rookie mistake with Makercam

This morning I was in the lab of a digital manufacturing subject and I showed my students how they could do simple designs and turn them into a 2D manufacturing g-code without installing any software in their computers or tablets.

I did show them the terrific online service that I have found very easy to learn and yet very powerful 3D design package. I performed a simple design.

And later I showed how that could be exported as a DXF file and with the help of Inkscape it was written into a SVG file that online CAM software can handle.

I selected metric units (though I would expected MM instead of CM but I guess it is ok for grid size purposes) and I proceeded to show the different machining operations available and how we will be cutting the thing.

So minutes later we have g-code file ready to be loaded into our CNC router equipped with LinuxCNC software. After setting the whole thing up the process started and seemed to be working ok, though I had the impression it was larger than expected. But I let the machine to work till the cut was done (I missed to have had some tabs for the outer profile operation as the parted was freed and got a scar in the process).

But when I did performed a measurement of the part it was clear something went wrong as it was just too large in both X and Y axis. But I remember I had been careful with Inkscape to avoid any problem with the part's scale.

Little by little I walk back and forth all the steps to find where the error was introduced and it was soon clear makercam was to blame. I just imported the file into makercam and it was the wrong size, just large. But then I said to myself, how come this program is so wrong and yet many people seem to use it happily.

So after some googling I realized where the culprit was: Though makercam use SVG file format for importing designs, it seems it needs some additional guidance to set the right scale, in the dpi box of the preferences. Those like me using Inkscape have to set that to 90 dpi. It was set to 72 and that was the reason the part scale was off. Now I have the right part but at the wrong scale :-)