Fighting with computers

Computers are not always friendly.

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 OnShape.com 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 Makercam.com 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 :-)

Tuesday, April 07, 2015

Getting more data from your PID controller

Just knowing the steady-state error of your controller may not be enough for you to figure out how well your manual adjustment for your PID gains is working. In order to get a better picture of it you need to gather information while the loop is reacting to an input change. 

However, just sending back information over the serial port while the loop is working may alter the very timing of things within the loop. So what I have done is to delay the monitoring information transfer till the loop reaches the steady state. That means actual position is recorded every millisecond and stored in an array so it is later transmitted once the motion is performed. Thanks to that I can see the system response quite nicely whether the response does have an overshoot or it is dampened properly enough. It really comes in handy when trying to set the P, I and D gains by hand. 

The problem, however is that for doing this you need to have enough RAM memory and Arduino UNO is a bit short of it. What I did was to use the same Arduino code with a more powerful Maple Mini that comes with 20K of RAM so I could record the system evolution every millisecond to transfer it at a later time.