Fighting with computers

Computers are not always friendly.

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 :-)

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.

Saturday, March 07, 2015

Moshidraw: pain on every laser cut

I have been using a [cheap] laser cutter machine. You can see which one on the following video.


Till now it kind of works but what is really annoying is the software you have to use to be able to cut and engrave. It is called Moshidraw and for reasons I cannot really understand it comes with a USB dongle for protection (it will not run without it).  Not in a million years I would like to copy such a program.

This is what I have learned so far that causes trouble:

  • If you DXF file contains curves, the operation will fail randomly (suddenly the cut will take an unexpected route and it will ruin your stock material).
  • If you import a DXF and fail to select the part, the cut will did not work properly.
  • If you have several parts in DXF, it may fail at any point (mostly when it is almost finished and all your stock material will be ruined). Best results and lower risk if you do multiple parts one at a time.
  • There not seem to be a way to force inside cuts first, so some operations will fail as the outside is cut before the inside so the part will fall and inside cut did not happen (only solution I have found is to reduce the power, doing multiple passes and keeping some of the contour to be cut till.
  • Sometimes it will cut a line in the middle of the design for no reason. If you are lucky the Optimize Route option will avoid that to happen but that is not a sure bet.
  • It will never remember you want to do a outline cut or that you do not want a mirror image of the cut.  At least it will remember the offset you fixed.
  • Do not attempt to repeat a cut without closing and opening again the cut dialog or the second one could fail. (Don't you love it?).
Other than that and the ridiculously small area of the stock material holder it is a fine machine if you have the patient not to destroy it every time you found out one of the many evil sides of the software/firmware that controls it.

It is easy to see why many people will completely replace the controller board right away.

Sunday, February 22, 2015

3D Tool path generation

I needed for a project to create a parallel finishing tool path similar what many CAM software does. There is nothing wrong with existing CAM software but what fun would be to just buy and use the software.

The basic idea is that you can use a swipe plane across the mesh representing your volume and get the top part of each slice to be the tool path. A similar idea is used for 3D printing, but there the swipe plane is an horizontal one and object is built from the bottom up.

The problem is that you cannot use the slice you just obtain from the mesh as milling bit (or extruded filament if 3D printing) has a non-null dimension. Because of that, just following the contour of the object will create a smaller result than the model.

For 2.5D milling you can do a waterline finishing, doing flat passes on XY-plane. Thus a simple polygon offsetting operation can help you get the part dimensions right. But for 3D milling, the tool compensation becomes more difficult.

The solution I opted for was to perform a mesh offsetting. Three different ideas can be used for the operation:

  1. Facets can be offset following the normal direction.  Mesh becomes full of gaps
  2. Edges can be offset following the a combination of the two normals of the two triangles sharing that edge.
  3. Vertices can be offset too. The question is that what is the better way of combining the normals of the three triangles each vertex shares. 
A quick look at the vertex normals calculation available in Meshlab gives four different methods. Before committing to code anything, a quick test would be welcome. 

I have done a simple test, that proved useful: after calculating vertex normals, I can export the file from Meshlab. Using PLY format instead of STL allows me to output each vertex's normal. If now I do some math with a script I can do the offset and test the result. 

Most time was lost due to a particular "feature" of awk in OSX. Once this was fixed I was able to offset the vertices of the mesh and prepare the correct tool path.

Friday, February 13, 2015

Barcode listings with data

A few weeks ago I mentioned a new tool I created for (allegedly) making my life easier when delivering marked exams to my students. Then I covered the process that happens after the exam. But one key element it was not mentioned is what it needs to do in advance.

For my system I needed a set of labels. My prototype used Code-128 barcode that can handle ASCII code to encode each student email using barcode command-line program for Linux. The only problem with that was the lack of additional information being added to the label, such as the student name.

Looking around I found a very handy tool by AVERY company, that helps you creating labels on-line for all their range of labels. What is even better is the tool will allow you to upload an excel file with data columns, like names and addresses to create a custom listing you designed and export it as PDF (they offer to print it for you to and deliver the labels to your office too).

After some tweaks and, the most difficult part, discovering the reference of my European A4 labels on their site, I get a set of working labels but this time using 2D QR codes that are a bit more reliable than 1D barcodes.

But I was left with a bit of an itch that I should be looking for a way of solving the problem entirely with my own software instead of using an online application, as importing a new list of students required a bit of touching here and there.

Not knowing what could do the job more easily, I turned to the ZXing library I am already using for decoding and I saw there is an encoder too. And given that creating a PDF output seemed to work well for AVERY I decided to do the same, this time using Processing, as it tends to make my life easier than when using Java.

The function above will create a QR code as an image you can later place inside a PDF page following the pattern you want. Going from BufferedImage to PImage took me like one hour to get right, as it seems Processing has been going through different solutions to that in the past, most of them no longer working.

So now I do have a tool that creates the labels from a CSV files with students name and addresses. I am looking forward to use these tools in the coming months.