6 posts tagged python

For the past couple weeks I’ve been working on automating and hacking the Passap E6000 knitting machine with Ivan.

I have previously posted about hacking on .cut files, but it turns out that the machine doesn’t even use .cut files. While Ivan & I were learning to knit we heavily used a piece of software called WinCrea and it lead us down the path of .cut files as that it is what WinCrea reads and writes by default. It turns out that it uses something even simpler, much simpler.

The E6000 uses a straight forward protocol that is represented by a specifically formatted ASCII string. The string describes the number of colours, columns & rows in the pattern and then just sends “0”, “1”, “2” or “3” to represent which colour should be used for that stitch. (For more details see the code, link to the GitHub repo is at the end of the post).

With the task of being able to directly send patterns to the E6000 over the serial interface behind us I needed to design and attach the arduino circuit that would allow us to interface with it.

The E6000’s main control panel is exposed and easily hackable inside the plastic housing. Minimal dis-assembly was required to get into it and the electronics for the buttons have through-holes (via’s) for each button that made attaching our own leads to them a breeze. (Ok, maybe “breeze” was the wrong word. I forgot how out of practice I was at soldering so the first 20 - 25 solders were a total PITA until I found my rhythm again)

The main component used in our circuit is an Opto-isolator/Opto-coupler, which is essentially a digital switch that the arduino can control and allows us to trigger the buttons for any arbitrary period of time. Pins 5 & 6 of the opto-isolator attach to the leads to the button, pin 2 goes to ground and pin 1 goes to the arduino, via a 1K resistor to ensure that we don’t arbitrarily trigger the button press. (This thread on the arduino forums was most helpful in coming up with a design).

The final piece to the hardware hack was a simple arduino program that reads single bytes over the serial interface and translates them into button presses on our console, thus allowing us to trigger the buttons from our control machine. The code is small and straight forward, and can be found in the GitHub repository.

We’re ready to rock. Who’s ready to knit?

KnitterStream code on GitHub

I’ve recently gotten involved in a project that involves building some custom software to do some image manipulation and some hardware to control an amazingly cool machine; The Passap E6000. Watching this thing in action is awesome to say the least. I’ll be posting more about it as we progress on the build, but for know I’m just going to talk about the first real aspect of the software development part.

A .cut file is a simple image file format that can be used store very basic image data plotted in pixels and using a limited 256 colour palette. These files can be loaded onto the E6000 via a serial cable and there’s a couple different pieces of software out there that can both create .cut files and download them to the E6000 but we’ve been using Win_Crea for our testing.

The first step in our experimentation was to learn to decode the .CUT files. The files use a run length encoding scheme built upon single bytes in a file. You can find the full details here: .cut file details

And after a day of tinkering around with it… Success!

The window on the left is Win Crea showing a simple pattern I designed in the grid editor and the window on the right is Preview on OSX showing the PNG I generated using some python code & PIL.

The goal is to build a nice interface to reading and writing .cut files called pycutter, but for now it’s just a straight forward python script. You can find it in my github account: https://github.com/fatbox/pycutter

More to come as we continue to put this project together.

It’s true. It’s weird. I love a programming language, and every day I use it I love it more and more.

As a sys-admin & developer I regularly find myself needing to parse data supplied by clients that’s, uhm how to put it nicely, formatted like it’s supposed to be an email rather than structured data. This means I often find myself munging data; you know, read from STDIN or sometimes open a file, read it line by line, do something with the data. That kind of thing.

Today I was confronted with a rather unruly set of data and went looking for a better way to handle input in Python, and happened upon the fileinput library.

import fileinput
for line in fileinput.input():
    process(line)

Wow. Process STDIN OR a list of files line by line and only needing a single line of code!?

Python, you’re amazing.

I found myself refactoring a large amount of code recently, and during the course ended up reading PEP-20 - The Zen of Python again. It’s been awhile since I last read it and it reminded me so much of why I love python and actually motivated me to refactor more than what I was working on at the current time!

While these are easily applied to writing code, I feel like with the right point of view they are generalized enough to apply to all facets of life.

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren’t special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one— and preferably only one —obvious way to do it.
• Although that way may not be obvious at first unless you’re DutchCanadian/Swedish.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea — let’s do more of those!

Python 2.5 is REALLY starting to show it’s age now. Python 2.6 is in testing, but anyone who’s tried to mix and match Python packages from stable & testing already knows that it never really seems to work out…

I’m working on a project that includes a piece of software that requires Python >=2.6, and since I have no intentions of moving to Debian Squeeze on my production machines it has to be compiled by hand.

I’ve seen lots of posts online trying to integrate Python 2.6 into the core system (binaries in /usr/bin, libraries in /usr/lib, etc) by compiling Python with a --prefix=/usr, but that’s another sure fire way to cause issues down the road IMHO.

So, we’re going to compile Python 2.6.5 into /usr/local and then use virtualenv for all of our project dependancies thus keeping everything neatly away from the core system.

Read More