Spot welder

Over the years I have seen a few ways of doing spot welder for battery packs:

A bank of electrolytic capacitorsOne or more super-capacitorsA modified microwave oven transformerA car or motorbike or LiPo battery But besides the power source, some sort of control is needed, as you are basically shorting the output of your power source and you do not want that to last long. The simplest thing to do is to use a pushbutton, but that is not very precise nor repeatable, so something like an electronic timer can work best. But if you want to provide more than a single pulse a microcontroller can be the best choice for a precise and repeatable switching of the power.
And switching the power can be another source of trouble, especially if the switch is the high-current side. A spot welder can rush hundreds of Amperes and you need something more than a pushbutton to handle that. Some designs use a bank of MOSFET transistors to do the job (power dissipation is not huge due to their low ON resistan…

Just add a shutdown button, it will be easy, they said ...

Finally, one of our Art projects is selling. My partner asked me to add a power-down button so the
museum personnel has an easy way to power off the installation. Adding that to a Raspberry Pi cannot be very difficult using one of the GPIO pins or so I thought.

So the first iteration was something like this: a small Python program that will detect a falling edge on an input GPIO input. Tests worked ok, I was using the internal pull-up resistor and a normally-open switch would connect the input to ground. Once the falling edge was detected a detailed shutdown sequence would be initiated (to avoid any damage a heated element would need to be retracted by a servo).

As usual, things worked well in theory and in the lab, but failed miserably in the real test. So I thought that, perhaps, the wiring was too long and close to a power line and that might be picking up some noise, that eventually triggered an unwanted shutdown (sometimes even before the system started working ;-)

So the second…

Testing SKR 1.3 board with Marlin 2.0.x

Not that I really need it but given the price I had to buy one of these units just to get a feel of it. At less than $20 it was a steal. And most of what I have seen from the board is to be liked. But, as usual, it took me a large amount of time to get everything working, as a few hurdles prevented me to succeed on the first try.

Luckily, there is a huge Marlin community and getting the software up and running was easy-peasy, once you have Atom/PlaftormIO installed (which I did). So the basic configuration is well covered on the net. The board can be powered either from the DC input (12/24V) or from the USB (jumper-selectable). 
But ... expect trouble if you are powering it from USB and attempt to configure TMC2208 UART mode. It will not work until you power the board with DC too. And it will only work if you have properly configured your firmware and set the right driver solder blob so UART is connected to pin number 4 of the driver carrier board and you have set the proper solder bl…

The art of compiling Meshlab and getting it running

I have been using Meshlab for quite a while as a powerful tool for automating 3D mesh calculations. Newer versions were not always more reliable than older ones, but mine was mostly a command-line usage more than interactive sessions so I got by.

The latest stable release is still 2016.12 and it gets my work done (though some changes were made to the command-line switches that broke some of my scripts). I have been using it on 14.04, 16.04 Ubuntu systems and lately, I wanted to use it on the 18.04 Ubuntu. But for that version, I could not find a pre-compiled binary and the versiĆ³n included with the distribution was Meshlab 1.3.3 that, you guessed it, uses a different set of command-line switches so it was not an option.

Still, there was the choice to install a binary using the snap package system, which comes included in Ubuntu 18.04 and got me a working interactive Meshlab. But the meshlabserver command was nowhere to be found. It seems someone thought it best to rename it to meshlab…

More on wireless uploading

As usual, even best-laid plans face hardship, so now I can wireless upload g-code files to the USB memory connected to a DDCSV1.1 CNC controller. But, once I factor in not to upload a code line before I have got the remote echo of it, things get really slow. Like ten minutes per megabyte.

Yes, I wanted it to be wireless. I could accept a not so fast upload speed, but 13 Kbps is not ok as we handle files in the 1-10 MByte range usually. A few seconds is ok, but half an hour or more is not.

So I came up with yet another approach that would recycle some old-tech that I discarded years ago: There was a USB dongle that would accept an SD card and it would work as a USB pen driver but with a twist: the unit did also have wifi connectivity. So the users could access the content of the SD card wirelessly as a network disk. That was cool and made totally unnecessary (apparently) my previous work but, there was a catch: The device would work either as a pen drive (as soon as you connect it to a …

Enabling wireless uploading of jobs to a stand-alone CNC controller

I explained a while ago how I set up a farm of CNC routers. At that time a combination of an Android tablet and an Arduino running Marlin was a good compromise for a DIY system.

Over the years, one thing that was demanded was to have controllers that are a single machine (as the USB cable from the tablet to the Arduino creates problems at times due to machine's vibration).

Several options are available in the marketplace of small and affordable CNC controllers that require no computer and can run jobs off a USB pen drive. No computer or tablet required. One of such a system, running Linux, with a nice display and keyboard, is the Digital Dreams units DDCSV1.1 and above.

I bought one unit a couple of years ago but it was never used, but now I am giving it a try on a test machine, where we want to reach 5000 mm/s^2 accelerations and speeds above 30 meters per minute and the fact that unit could create step pulses at a 500kHz rate really caught my attention. It can do that not becaus…

A simple plan

One of the things I did not like about a new printer was that the belt that moved the carriage was not laying parallel to the axis of motion (left) but at an angle, as shown in the picture below (right):

Such a belt path is not right as for each inch of motion in the axis a slightly different amount of belt is moved (the hypotenuse of a triangle instead of its long side). Most of the time, the angle is so small the difference is tiny. That is why the arrangement works and printers are printing even though they have this ugly hack.

The problem is worse when the carriage is close to any of the two ends, as then one of the angles is not so small and that creates a bigger error. But the question is: how big the error can be?

Well, it took me a good part of a weekend to figure that out, among other things because wxMaxima does not like to calculate the intersection of two circles easily.

So the first thing I needed was to model the anomalous belt path in a geometric model I could calculate…