Knitout and Kniterate 3

kniterate notes 4

This is the fourth in a series of blog posts about the Material Programming Project. We are developing malleable knitting software for the Kniterate, a semi-industrial knitting machine. The first post, on the Knitout project, is available here, a longer post about the Kniterate machine is here, and a guide to the different file formats is here.

This week I learned 2-bed knitting on the domestic machine, and made some progress on the Knitout-> Kniterate code visualiser. We also managed to get a bunch of tests to run on the Kniterate, most of which worked fairly well. We also visited an exhibition of some work by visiting students from NAFA (Nanyang Academy of Fine Art Singapore), which featured a really great and inspiring bit of Kniterate work.

making friends with the ribber

This past weekend, Rosie and I went to Knitworks to do a workshop on the Brother ribber. Neither of us had worked with one before, and it was really useful for getting a material understanding of what’s happening on a 2-bed machine.

Setting the ribber up in my studio

We practiced a cast-on, different ribs, and experimented with plating and racking on the front bed (which might be a nice thing to re-create on the Kniterate). After the session, I went to my studio to set up the ribber that had come with my Brother machine, but that I’d not used before! It was pretty straightforward to set up: the hardest part was figuring out how to attach the brackets to the ribber as they’d been taken off. These are sprung, to allow the bed to latch up and down.

kniterate testing

testing the waste section

The first thing we did at Chelsea was to test the waste section sample we’d generated last week. All I needed to do was add a set of rows of front bed knitting. I decided to do this by using the waste generation file as intended – I made a rectangle on the front bed, and then appended the waste section using a script.

This turned out to be easier said than done: the lines I’d added to the cast-on section messed up the carrier directions because I was bringing them in twice: once in the tucked section and once again in the kniterate-style introduction that I’d added. This meant that the carriers ended up on the ‘wrong’ side of the bed for the original code. In the end I ended up adding a few extra rows to hack this together so we had something to test with, but I’ll need to sort this out properly later on.

The tests went well: B was quite pleased with the double introduction as it means the yarns are brought in early on, getting around an issue with yarn height on their kniterate, and saves her from manually bringing the carriers in. It was really cool seeing our code turn from code into actual, knitted material – and in seeing the correspondences between the knitout and kniterate-editor based cast-on.

We encountered another issue, which is that bringing carriers ‘out’ from the right hand side means that they trail over the whole knit to move to the Home position. For now we just move the ‘out’ statement to the end (as they’re not as important in kniterate anyway),B said that bringing carriers ‘in’ and ‘out’ was more of a Shima thing – when they’re not being knit they just sit there, they don’t do that much. but the other way around this would be to always ensure the drawthread ends up on the RHS (thinking about it, this is non-ideal as it fixes the cast-on direction of the input file… so we won’t do that).

Once we’d got this working, we made a couple of test samples – one with a 1x1 rib, one with a fisherman’s rib (same as the waste section). Both of these knitted well, though they could have been a little tighter.

casting off

The next thing to test was casting off (after B spent about 20 minutes manually casting off the first sample). Initially, I used the rectangle-bindoff code from (in the US, ‘casting off’ = ‘binding off’) from the knitout examples repo, adapting it to the more recent version of the knitout-frontend javascript code as follows:

what the first bindoff section looks like in the knitout visualiser. Note the ‘held’ stitches every other stitch on the back bed!

k.xfer("f" + n, "b" + n);
k.rack(1.0);
k.xfer("b" + n, "f" + (n+1));
k.rack(0.25);
if ((n-min) % 2 === 1) {
k.tuck("+", "b" + n, Carrier);
}
k.knit("+", "f" + (n+1), Carrier);
if (n+2 <= max) {
k.miss("+", "f" + (n+2), Carrier);
}
k.rack(0.0);

Translating to words, the order of operations here is:

• transfer a stitch from the front bed to the back bed
• rack 1 needle position over, bringing the stitch that was transferred to face the next needle along
• transfer that first stitch from the back bed to the front bed
• every odd-numbered stitch, perform a tuck stitch on the back bed
• knit the stitch that’s held on the front bed
• for all except the last 3 stitches, drop the knitted stitch off the front bed
• rack back to 0, and continue

This does something a bit different to the typical knitout bindoff, which doesn’t do this step of holding every other stitch on the back bed. B remarked that this method was ‘very shima-y’, and the end result was somewhat distorted.

The next step was to update the code to match kniterate editor, removing the every-other-needle transfers to the back bed. We ran out of time to test this, but the hope is this should work similarly to the version in the kniterate editor:

k.xfer("f" + n, "b" + n);
k.rack(1.0);
k.xfer("b" + n, "f" + (n+1));
k.rack(0.25);
k.knit("+", "f" + (n+1), Carrier);
k.rack(0.0);

This does a simpler operation than the first one described above, missing the tuck steps, but also leaving the ‘miss’ steps till the very end, holding the knit stitches in place on the needles.

• transfer a stitch from the front bed to the back bed
• rack 1 needle position over
• transfer that first stitch from the back bed to the front bed
• knit the stitch that’s held on the front bed
• rack back to 0, and continue

kniterate issues

We encountered a recurrent issue where the Kniterate moves the yarn carrier before the carriage starts to move, resulting on stitches being dropped on the right hand side of the bed. B mentioned that this was also an issue that also occurred in kniterate-editor generated files, but was seeming to occur more often in ours.