Fighting with computers

Computers are not always friendly.

Wednesday, April 12, 2017

More on STM32

After testing different choices, I have come to test a package called Platformio that runs over Atom editor. Atom is a multiplatform code editor that looks a bit like Sublime but it is open source and they claim highly hackable.

The nice thing about PlatformIO is that it looks like a nice IDE that can handle a good portion of embedded processors from Arduino variants, to ESP8266 and ESP-32 to many ARM variants from NXP, ST, Atmel, etc.

For the f103c8t6 board I am using I can use the config details above in platformio.ini file in the project folder and it all works nicely on one of my Macs, the one using El Capitan. Unfortunately, my laptop is still running Mavericks and for that it seems there is not a libusb available that plays nicely with ST-Link programmer/debugger dongle.

Now I am going to target my dcservo code for this Cortex M3 processor.

Wednesday, April 05, 2017

STM32 or the pain I have been avoiding for quite a while

If you follow the blog you know I use Arduino IDE for quite a while and I am quite fond of the eco-
system as it usually makes things simple. With some effort, same environment works for other beefier processors like ESP8266 or even STM32.

But what usually kept me away from the various ARM offerings, with the exception of mbed on-line compiler for Nucleo boards has been the commitment level manufacturers seem to ask from engineers before they can start to think using their wonderful hardware. So far my point has been that life is to short to go through so many manuals and datasheets.

Recently, an American maker told me he was about to build a piece of hardware using a STM23F103C8T6 core to mimic my dcservo project I built around Arduino and other processors (even around a Maple Mini with a similar STM32 processor in fact). He would welcome any help on the software side of things so I had to have a look at how I could help and ventured into the wild west of development tools for these parts.

So far I have had only moderate success of loading some sample code onto a $3 board using an ST-Link USB dongle with ChibiOS's ChibiStudio IDE, but unfortunately the OpenOCD binary bundled did not work with my Windows7-32bit OS.

Yes, one of the reasons I was not keen of venturing into this world was because many of the tools are Windows-only, though many IDEs are Eclipse-based and therefore multiplatform by nature. Not so much the different debugging tools. But again, I have just stated to scratch the surface and I am trying, so far, to test only freely available tools, even if they are for Windows.

While I could compile code with ChibiStudio, I learned that CooCox IDE use a code-upload tool called CoFlash that worked for my setup and allowed me to upload code that actually worked. It was refreshing to the the USB_CDC demo working finally.

While I thought CooCox IDE was complete development solution I soon found out it was missing the compiler. I later downloaded GNU ARM compiler and I was able to build and upload (all from the IDE) a version of GRBL for STM32.  It still feels a bit of black magic and it is quite clear how many of these annoyances can prevent many users into this families of processors. Apparently you have to go the Teensy way if you are looking for a user-friendly way into the ARM world or just stay into the Arduino territory but in both cases you are a bit more limitted to the choices (and prices) of the processors available.

Now that I have a couple of IDEs working in Windows I will try to move my way to Linux to see if the same work can be done in a plaftorm of my choice. I am sure there are plenty of choices but I do not know how long it would take to test them all so any recommendation for STM32 development away from Windows is more than welcome.

Saturday, February 25, 2017

Make a heated bed with 9 calibration points.

Most likely you have learned that the new Prusa i3 from Prusa Research is including a nice self-calibration feature based on the special heated bed they use.

That bed features a grid of nine disks that can be detected by an inductive sensor that moves with the hotend carriage. These spots double as bed leveling and XY geometry calibration.

While the bed is flat an covered by a special (PEI) film to improve adhesion, the spots can be easily replicated if using an aluminium bed as my video below shows. Nine inserts of 8mm steel rod can be used by doing nine holes of the same diameter on the aluminium bed.

The interesting feature is that steel is detected further away than the surrounding aluminium so the same algorithm should work if you build your bed like this. In fact you can just place the aluminium sheet on top of your existing heated bed (though doing so may increase bed weight needlessly).


According to the calibration source code these are the locations of each point:

Click on the image to get a larger version of it (unless you have "retina" sight).


Sunday, January 15, 2017

Installing PIL on OSX

I have got some messages about installing PIL library on a Mac assuming it is a Windows-only

library. It is not.

I have never used Python Image Library before, but when I designed 4xiDraw drawing machine I used one Inkscape plug-in that was intended for laser engraving. I hacked it just a bit to make it work with my machine. The plug-in itself is a simple two-file thing you need to copy to your ~/.config/Inkscape/extensions/ but the PIL library may be a bit of a challenge on some systems.

It is important to use 0.91 version of Inkscape as the plugin will not work with an older version. Other than that it should work in Windows, OSX and Linux.

What worked for me are the following commands on an opened terminal session:

sudo easy_install pip
sudo pip install pillow


Saturday, November 19, 2016

Reaching your Pi over your network

There are multiple ways of learning what is the IP address your Raspberry Pi is obtaining from a
router. The most obvious one is to use the router's DHCP client list. Another one is to use a HDMI display as your RPi will report its IP address while booting.

The former requires administrative access to the router, which may not be possible on certain networks and the latter is only possible if you can connect the display to the RPi and you have a display available. What I am going to propose requires no special rights over the network gear not any additional hardware.

One of the things you can do over a network is to broadcast a message (in fact this is the foundation of the DHCP protocol for a computer to find a suitable DHCP sever over the network without previous knowledge of it). Sending a UDP broadcast message allows any other system on the network to hear it. And if that message is received each receiver knows immediately the sender's IP address.

So here is what I do to perform this periodic broadcast from the RPi


from socket import * 
from time import sleep

s=socket(AF_INET, SOCK_DGRAM)
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
while (1) :
    s.sendto("Hello\n", ("255.255.255.255",25555))
    sleep(2)
Any computer on the network can tell the IP address of the sender of this special message so it will effectively learn about it. I tried to use the netcat command but while it works it fails to shown the sender's address so I used tcpdump instead.

sudo tcpdump -i en0 port 25555
That did it for me. Once I learn my RPi address on a network I can go ahead and ssh to it for any maintenance task I want. My main interest here is for nodes that are installed on networks different than my home network.

Tuesday, November 01, 2016

First experience with RPi3

I am working on a project that required some computing power and commanding an Arduino UNO running GRBL. Things have changed quite a bit from
original plan, so because radio reception was awful, the original plan of using dump1090 with a USB dongle had to be ditched. Of course I only learned that once I have it working nicely on the Raspberry Pi 3.

Plan B would be to use the Ethernet network interface. Once that was working we realized it was not possible on our target installation.

Plan C was to use wifi. And while it is really simple to get it working with stock Jesse, I found a way to waste my time when I added spaces in between variables and equal signs in /etc/wpa_supplicant/wpa_supplicant.conf. So now you have been warned.

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp 
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
#------------ wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
 ssid="mynet"
 psk="mypass"
}


Once wifi connection was working and the rest of the project code was up and running I wanted to have it all to autostart. However, I always like to be able to peek into each program to see how that is going on.

If I had chosen to start each program off /etc/rc.local I had the problem that I won't be able to see what is going on with the terminal output of each program unless I redirect its output to a file, but that usually uses up disk space and eventually needs to be deleted and wears the flash memory.

Instead, I decided to use screen command to launch each program. And, as usual, it did not work at first try. Several things are slightly different there than from bash command line:

  • root user in the one running the show there, if you launch something it will be under that user (unless you do something about it)
  • commands and files locations need to be specified carefully, as there is no $PATH value to rely on.
  • you can always use su - username -c "command" to launch a program under other user credentials
  • any program you launch here needs to end quickly as you are delaying the boot process, if you need to launch a long program it has to be on the background (use &)
Once I understood all these points I was able to launch my commands using lines like this:
  • su - pi -c "/usr/bin/screen -d -m /home/pi/mycommand" 
And while you do not see the & at the end of the line, it is the -d parameter of screen what takes care of running it as a daemon process and not blocking the script flow. 

The good thing is that later, I can log into the RPi3 and use screen -r to connect to the virtual terminal each program is running on, to see if the output is right and everything is working as expected or not. It really works well for me.

Wednesday, October 19, 2016

My Printrbot experience

While some friends were waiting for their first Printrbot off Kickstarter I had already built one with the parts Brook Drumm posted on Thingiverse. That was quite a while ago. It was a cute little machine that I sold to a fellow reprapper.

Last year, while I was working on a closed-loop DC motor controller for replacing the steppers of our 3D printers, Brook Drumm offered to help and sent me a free Printrbot Simple Metal, fully assembled to be used as a testbed printer for such type of motion control. I had a difficult time trying to convince the taxman that the printer was really a gift and eventually I had to gave in and pay some custom taxes although that was not really a product I was buying and the sender was charging me no money for that.

I was surprised of how compact the thing appeared and how smooth and solid all the axis moved. However, the 3d printer was not intended to be used as a 3d printer and the first thing I had to do was to partially disassemble a brand new unit and to start to adapt the other type of motor.

Adapting another motor while keeping the functionality of the printer was a dead end given my limited mechanical skills and how tight fit all the parts on this model of printer. I managed to get a motor working on Y axis but then I would lose Z-axis functionality as it was not possible to get both axis working with the type of motor I was using.

At then end, the mechanical limitations made the task to lay in my project's table for a long time without any new development. I want to stress that when I mentioned the problem I was having to Brook and the inability to get the test of operation he offered to send another model but I already felt embarrassed enough for not achieving the original goal to go on that path.

So one day I decided it was about time that I reassemble the Simple with its original motor and get it work as a regular 3d printer. Once it was up and running I did a sample printing while the printer sat on a stool in my office and I left the printer unattended for a coffee break with some colleagues. When I returned I discovered to my horror that the printer had fallen on the floor due to the carriages acceleration (metal feet of the frame on a hard plastic lab-type stool was a deadly combination). To make things worse the USB cable had almost ripped apart the micro-USB socket. My attempts to fix it did not succeed, so I ended up cutting the micro USB connector off and soldering the four wires directly (incidentally I discovered the schematic had the wiring to D+ and D- reversed on the Reprap site).

Luckily the torn USB connector was the only damage occurred to the printer after the fall. Once fixed it is working I hope as new and giving very good prints using PLA. While very good output quality, I have to admit it is not as good as the i3 MK2, but one of the reasons maybe that the Simple feels faster (in fact it uses default higher accelerations on XY axis than the Prusa i3) which can account for both the faster printing and the small difference in output quality.

All in all, I am impressed at how well this little printer handles. One minor detail is that while the printer profile is small, you need to have good clearance on the sides and on the back so X and Y carriages can move freely.

I can understand why this model has so many good reviews, it is just not intended for tinkering much as all the parts are held in a really compact space.