Fighting with computers

Computers are not always friendly.

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.


Sunday, March 15, 2015

One Arduino controlling two brushless DC motors

After some changes I have been able to get it working reliably with two motors. But one of the changes I have made is to use a new type of motors that I reckon are better suited to the task. Instead of using brushed motors that are cheaper, I have found these other brushless motors that have several advantages: 
  1. Being brushless there is no other wear than the bearings
  2. They have built-in driving electronics, so they can be controlled with the Arduino digital outputs, that simplifies things and reduces interface cost. 
  3. Motors have built-in encoder disk too, but the one they carry is just 100 lines per revolution (a bit poor in my opinion) that can turn into 400 "steps" per revolution with the 4x decoding of the program. The lower number of lines per revolution puts less stress on the Arduino interrupt code, which may be one of the reasons it works ok now.
  4. I have moved all the encoder signals to pins that are monitored with the interrupt on pin change and I have reserved the two external interrupts for the STEP input signals for each motor. 
Though I am doing my tests with an Arduino UNO, it has to work the same with the Pro Mini (as far as it uses a '328 chip too). 

The motors I am using seem to be manufactured for Ricoh, but I have failed so far to obtain any decent technical information. But they are sold as 20W brushless motors with built-in driver electronics and quadrature encoder.



While they cost around $15 each, these motors have a brilliant behavior, even when powered at 12V (they are rated 24V).  With power to spare I have to reduce the PID maximum output if I do not want my toothed pulleys to skip in the highest acceleration moves of my tests. The video below shows X and Y axis motion while printing a part controlled with Marlin firmware running on the blue Mega board while the red Arduino UNO board runs this code.

Some other interesting detail is that motor electronics will work at 3.3V too, in case you are driving it from a 3V3 processor. But remember output shaft is 6mm and not 5mm which is a bit of a pain.