As in my previous post, I’ve been modelling parts of my loom. This update covers the two most recent.
Pinch Rollers
At the back of the loom there is the pinch roller mechanism. This is used to control the tension of the warp threads from the back of the loom towards the front. High tension is needed when weaving, but it prevents the lifter bar (referred to later) from lowering properly. Using the pinch rollers, the tension in the loom can be dropped by moving the warp threads forward at the back of the loom. Then when the pattern has been set and the lifter bar raised, the tension can be reintroduced by winding the cloth up at the front.
Pinch Rollers
The bobbin frame support structure, in the previous post, connects to the back of these rollers. The bobbin winder, also in the previous post connects to the lefthand side of the pinch rollers as shown.
Adding the pinch rollers, bobin frame and support, and bobbin winder all together, the over-all model now looks like:
Lifter Bar
Whilst the back of the loom was off – I had to remove the pinch rollers to work out how I’d built them originally – I decided I’d model one of the most important parts of the loom, since it was visible. This is the lifter bar. It is one half of the mechanism that provides the Jacquard ability. It has 32 pins in it, that when one is engaged into the bottom eyelet of a heddle allows that one to be lifted up. There is an equivalent static bar at the front which holds the heddles down if needed.
Lifter Bar
This mechanism slides up and down along some long axles. These pass through the holes in the ends of the bars, and through some of the holes in the frames. There are gear racks at the back and sides which provide the lifting force. The lifting mechanism has to be offset away from the pins as the pin setting mechanism rides along underneath the whole Jacquard structure.
Well, I’m going to put the loom back together, and check that all my new parts actually do what I wanted them to. It’s still loaded with wool from the Mytholmroyd show at the end of January, so I’m going to run that through and then empty the loom.
I’ve then got a little bit of coding to do, to support the bobbin winder – i.e. change the direction of the motor. There’s no need to use the pinch rollers to wind the warp threads on to a drum anymore, so I can repurpose that function to the winder.
I’ve got some other things I need to focus on, and this 3D modelling is quite intensive, so I’m going to take a break from that, and will look to model some more parts in a few weeks time.
Ever since I started to show my LEGO® loom on this blog, Facebook and YouTube, I’ve had people ask me for build instructions. I’ve always said that I’d make them, and I will stick to that … but it’s a BIG task, and will take a long time.
Recently I’ve been making changes to the loom, so have been removing old parts and making new modules to replace them. What I decided to do as I went along was to actually model the parts I was removing, and to model the new parts as I went. This way I have the old parts for reference should I ever want to look back on them in the future, and the new parts have been modelled from the start. As time goes by I intend modelling the separate “modules” of the loom, and then build up a body of work of all the sections. I’ll still need to model the main framework of it, but that will come in time.
So, without further ado, here are the parts I’ve done so far.
Warp Thread Drum
3D render of the old warp drum
This is the original warp thread winding drum. This was used at the back of the loom and stored the warp threads for feeding in to the loom. In my original build I used to have to wind the warp threads on, en masse, by hand. This suffered from a) being tedious, and b) the threads would wind on at different rates. Since the threads didn’t lie completely flat on top of each other, the drum would end up with different “thicknesses” of threads, resulting in some threads winding on faster than others – since C = 2πr. When the loom was running it’d pull all the threads through at the same rate. Due to the different winding thicknesses, this would either result in some threads getting very slack or, more commonly, some threads getting very very tight.
My solution to the differential winding of the warp drum, was to build a set of pinch rollers, that the warp threads went though, and a gearbox that drove the drum.
One of two gearboxes – one either side of the loom to drive the warp thread drum.
The pinch rollers would be in use during weaving, to provide a tension control between the back of the loom and the cloth take-up drum at the front. They would ensure that all the threads passed through the loom at the same speed.
The gearbox would be engaged when loading the warp drum. When engaged, the warp thread drum would rotate at a “surface speed” ever so slightly faster than the feed rate of the pinch rollers – the white clutch gear would deal with any mismatch in speeds. When weaving the gearbox would be flipped over to a gear with a friction pin, just to stop the warp drum free-spinning.
This appeared to work well, until the last time I loaded the loom. I was struggling with the threads getting caught up in the pinch rollers as they wound on. After watching it load, and thinking on it, it was the same differential speed problem as in the original loom, but in reverse. Now, as the threads wound on, they were winding on at different speeds due to not winding on flat. This was exacerbated by the use of the clutch gear. This meant that the warp drum rotated at the slowest speed, i.e. that of the thickest wound thread. The threads winding on to the thinner areas therefore became slacker, and would get caught on the pinch rollers, ultimately winding back inside them.
My answer to the warp threads running at different speeds has been to make a frame that has 32 individual bobbins; one for each thread. I’ve yet to test that it actually works, but will do in the next few days. Now each thread can unwind at its own speed, and not be affected by its neighbour.
I’ve designed a frame that can hold them all, in the manner of a cartridge. This way it can be loaded up away from the loom if desired, and then clipped in to place.
Bobbin frame
Each bobbin has a black and dark grey disc, and a friction pin on one end and an axle on the other. Half of them have the friction pin on the black side, and the other half on the grey side. The friction pin is simply to stop the bobbin from free-spinning. All the bobbins will be wound in the same orientation with respect to the black/grey discs. This means that when they are all installed half will unwind clockwise, and the other half anti-clockwise. This is so that the threads don’t rub against each other (too much). The frame also has a set of long axles to act as thread separators. This is so that the threads don’t get twisted together, thus preventing them unwinding properly.
To support the bobbin frame and to allow it to be easily removed and installed, a simple support structure was needed.
Support frame
The red pin bushes at the top are used to lock the bobbin frame down on to the support. The bobbin frame itself has axle pins underneath that locate into the angled beams on top at the back. The whole thing is supported on the long angled arms, set at a 3:4:5 Pythagorean angle.
Although I expect to wind the bobbins using my main winder, used for the weft threads, I wanted a winder mounted on the loom itself.
Bobbin winder
To achieve this a small winder has been made where there are two devices, dog teeth, that engage with the six holes on “wedge wheel” discs on the bobbins. The bottom one hinges out, and the top one slides up and is driven by the same motor that powers the pinch rollers. A single speed gearbox is used to engage/disengage the motor. This allows for it to be used when the loom is empty, and not powered when the loom is in operation.
The plan is to always wind bobbins with the black disc on the bottom, held by the red dog teeth. This will ensure that all the bobbins are wound in the same orientation.
Whilst I’ve been working on some of the issues, I thought I’d tackle the shuttle.
Weft shuttle
This has generally worked well, but now and again has got caught up on the threads as it’s passed through. This has been down the the “shed” (the hole inside the top and bottom warp threads being a little bit too small, and snagging the horizontal bar at the front. This bar is used to ensure that the weft comes out from the middle of the shuttle.
In my original design this bar sat 6L away from the shuttle. The supports that hold that bar in place, and the long bobbin between them, are now 5L and the bobbin sits at 2½L away. It may not make much difference; I have yet to test. If 5L is too short it is easy to modify it back to 6L.
I build all my models in Bricksmith. I’ve used it for years, and know how to drive it. I’ve had a play with Stud.io recently, and still don’t (yet) get on with it. However, I really like the renderer that comes with it. So, I’ve been building my models in Bricksmith and using Eyesight, from Stud.io, to make the pictures seen in this article.
What’s Next?
Well, I still need to test that this all works. That’s something for this week, but I think Captain Marvel comes first 🙂
I was rather impressed by Baz’s 3D LEGO printer when I got to see it at LW2017. So, I figured that when I had time I’d build it and have a go at coding it myself. I finally got all the parts this month and have built it up – albeit in different colours, and with a few minor structural changes.
Today I got the code working for the first time! It’s not fully fledged, but it’s functional, so I’m going to post a link to what I have so that people can follow my progress. The link below points to this basic code:
It will be expanded to do more things, such as simple geometric shapes/prisms/cones, and reading datafiles to print more complex structures. I doubt I’ll pursue the G-code system as that’s too complex to handle in EV3G.
I managed to focus some more time on tidying up my AI2 app for sending Mailbox messages via Bluetooth from my Android phone to an EV3. The EV3 code is really simple and looks like this:
The AI2 code provides two BT related buttons, Connect & Disconnect, a text box and a Go button to send the text:
When the text is entered and Go pressed it is sent as a Mailbox message with the name “beep” to the EV3, and displayed on its screen. The code to send it has to construct a message in the form:
At the Bricktastic event back in July I showed off my Plott3r as part of the Mindstorms exhibits. It was programmed to do the Hilbert and Dragon curves, several plot “files” and some other bits.
One of the questions that the kids kept asking was something along the lines of “can it write my name?” Unfortunately it wasn’t, and isn’t, capable of writing ad-hoc text. So since then I’ve been pondering ways of supplying user-provided text. I did consider an ultrasonic triangulated “keyboard”, but the US sensors got confused with each other’s signals – so for the moment I’ve put that idea to bed to be revisited in the future. My original thought, however, was “can I do this with a mobile phone?”
Since that original thought I’ve been looking at how to write an Android app that has a simple text box and “send” button. Kids are used to mobiles these days, so it seems to me to be the perfect UI. So far I seem to have settled on using MIT’s App Inventor 2. It does support EV3 to some extent, but I’m going to have to get down and dirty with the EV3 byte code to send mailbox messages via bluetooth 🙂
So, now I need to get learning how this AI2 system works. Thankfully they have tutorials, so I’ll be building the tilt/move tutorial soon to get to grips with communicating with the EV3. Tinkering with bytecode won’t be too daunting as I’m used to getting down to that level of bit twiddling via my current and previous jobs.
