Fighting with computers

Computers are not always friendly.

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.