Supercon 2017 Fun: The Original Luggable PC

I named my Luggable PC project after the original IBM PC clone by Compaq. The Compaq Portable was the computer that started the PC clone market that is still going strong today. It picked up the nickname “luggable PC’ because it was roughly the size and weight of a sewing machine. I’ve seen pictures in books and on web sites, and occasionally I see a unit on display in a museum somewhere. I never expected to see and touch a running unit.

So I was pleasantly surprised (and amazed!) to see one at Hackaday Superconference 2017. It was brought in by Ariane Nazemi, who gave a talk about mechanical keyboards and brought the Compaq as one of his visual aids showing old-school mechanical keyboards. Chatting with Ari I learned one of his hobbies is to restore old computers to running condition. So the original luggable was not just a demonstration piece, it was an actual functional computer.

One of the optional equipment available for the Compaq Portable was a Computer Graphics Adapter. The CGA resolution of 320×200 is has long since been surpassed by modern equipment. But it isn’t very far off from the conference badge camera’s resolution of 128 x 128. And that’s probably why Ari worked to incorporate the Compaq into his badge project. I didn’t want to bother him while he’s focused on getting it to work, but I did ask to take a picture of my Luggable PC sitting next to the original while he worked.

LuggableOldAndNew

I had looked forward to his project presentation at the end of the conference, but I missed it because I had to take care of some administrative tasks. Alas.

It was great to have these two sit side-by-side and see over thirty years of progress in PC hardware evolution.

(Cross-posted to Hackaday.io)

Supercon 2017 Fun: Big Screen + Little Screen

I brought my Luggable PC Mark II (Rev B) to the Hackaday Superconference 2017. Its primary purpose was to be my development workstation as I dug into the source code for camera badge hacking. Its secondary purpose was to serve as conversation ice-breaker since the Supercon crowd includes the kind of people who would appreciate it. It accomplished its mission on both fronts!

One fun experience that came out of the weekend was sitting down in the badge hacking area next to the person behind the PaperBack project. He thought it was hilarious that I had the biggest screen on the table and his was the smallest. One discussion led to another and we decided it would be fun to have my computer simultaneously drive its big 24″ screen and his 6″ PaperBack screen.

We had to borrow a DVI to VGA connection from another helpful person in the badge hacking area, and there were some further fiddling with wiring connectors and display settings. (Including several reboots between Ubuntu and Windows since they each provide different ways to customize display parameters.) But eventually we got my Luggable PC to talk to his PaperBack as an external display.

PaperBack closeup

I put our respective Hackaday.io project pages on each of the displays. His PaperBack showing his project page, and my Luggable PC screen showing its own project page.

PaperBack and LugPCmkII

This was a completely random project done mostly just to see if it could be done. Exactly the kind of curious exploratory spirit that was pervasive throughout the conference.

(Cross-posted to Hackaday.io)

Supercon 2017 Badge Film “In the Back Alley”

My Superconference 2017 camera badge project concludes with the 1-minute short “In the Back Alley of Spercon.” I entered it into the short film festival and was ecstatic to have been selected as the winning film!

I recorded a bunch of footage during the day on Saturday, but once the sun went down the camera could no longer record usable footage. So I switched efforts to putting together a presentation of what I’ve recorded. Since the camera badge has no audio capabilities – no microphone nor speaker – it was going to be a silent film by necessity. I followed precedence for silent films, using the text capabilities of the camera badge app framework to put up static text which give context to the moving pictures.

I started with the ambition of writing a short film editing app on the phone, and quickly decided that would take more time than I had. I switched to hard-coding the sequence of text and videos into a single app that I could run on the camera badge. You can still see my original intent in the filename “avitrim.”

Once running, I had something I could show to other people. Friendly curious people had asked about my project in progress Friday and Saturday, and now I could press “Go” to show them the results. Unfortunately that wouldn’t work for the film festival, where they intend to put it up on the big screen. I talked to Hackaday Mike and he suggested I record the badge app in action and put it up on YouTube.

I tried a few different cameras and they all exhibited problems trying to record the footage playing on the OLED screen. Blooming, flickering, and loss of color saturation to various degrees that I struggle to correct with camera settings. The least-bad version came from my cell phone’s camera so that’s the one I uploaded to YouTube.

Playing the YouTube clip on my TV indicated the video was good enough, but the audio was not. I held my breath during the recording so people wouldn’t have to hear my breathing, but the microphone picked up other background sounds. To cover up this annoyance, I went to the YouTube royalty-free music library and picked out a music clip that’s roughly a minute long. It’s not exactly my favorite song but it’s far better than random background noises.

(The project described in this post is documented on Hackaday.io and the source code is publicly available on Github.)

Supercon 2017 Badge – Now Recording Time Lapse Video

I arrived at the Supercon badge hacking area Saturday morning and immediately got to work. I picked up where I left off – looking for the place in the code where I can change the frame playback rate to be higher than the 1fps capture rate. Once done, a test run confirmed that the automatic power-off will shut down the camera during a time-lapse so I added a line to reset the powerdowntimer counter during a time-lapse capture.

According to the plan, I should now take what I’ve learned and write a dedicated time-lapse capture app. But as I’m successfully recording time-lapse footage, the motivation to do has dropped drastically. I’d rather walk around and try to record fun footage around the conference. So with that, I’ve abandoned the previously planned “phase 2” and “phase 3”. I’m now more interested in utilizing my time-lapse video capability instead of continuing to invest time refining it. Time is an extremely limited resource on this weekend project!

The badge is not taking full advantage of the sensor, so the lack of resolution and crispness is not a surprise. But since we’re getting so little out of the sensor, we can use all the help we can get. This is why I was both excited and felt sheepish when I realized that I had been filming for half the day with the protective plastic still covering the lens. Removing it didn’t make as much of a difference as I had hoped but hey, every bit counts.

Increase Resolution

Once the sun went down, I stopped shooting footage. There is not enough low-light capability to obtain useful video. Returning to the computer, I started brainstorming the best way to present what I’ve captured. I started trying to write a rudimentary video editor (just to trim frames before and after the parts I wanted to keep) but I had no luck navigating the AVI data structure.

With the ever-ticking clock, I changed tactic: instead of an editor, I’m going to write an app that is hard-coded to play specific video files in order, and a few blocks of text in between. Just like silent films of old. I’m confident this less-ambitious application could be finished by Sunday afternoon.

(The software project discussed in this post is publicly available on Github.)

Supercon 2017 Badge – Software Orientation

With the focus on getting the panning base up and running before Supercon weekend, I haven’t spent as much time as I had wanted on software side. The camera badge source code was released a few weeks ago and were constantly getting updated as the weekend got closer. (Differences between the prototype and production boards, plus other fixes.) I had wanted to keep up to date with the software but my project investigation and the pan base took up all the time I had to spend on this project.

As soon as I had two bases up and running, I went to the early check-in and badge hacking session Friday afternoon. It started at noon and I thought showing up at 3pm would still allow some time to work. I did get some time to work, but I also found that plenty of people arrived before I did and there were no table space remaining.

IMG_5340

Oh well. At least I have the badge in hand now. The first thing I did was to perform a quick test. The camera badge came with a video record option, which I intend to dissect for my time-lapse video app. But until then, I could do a real-time video captured while panning on my base to show the basic concept works.

Another bonus of getting the badge in hand is that I was immediately more productive learning the code. The source code was informative, the documentation online was helpful, but my brain needed the anchor of actually seeing the code running. It’s was a great help to play with a menu with my hands, then go back to read the code drawing that menu. The code made a lot more sense after seeing it in action.

I dove into the basic app support framework, and after I understood the basic structure, switched to analyzing the camera app. By the end of the evening I understood enough to know how to modify the camera app to restrict the video recording frame rate to one frame per second. This artificially limited rate much more closely resembles what I would want to do in my time lapse app.

Unfortunately the playback frame rate is “accurate” in the sense it tries to play one frame per second. I have more learning ahead of me before I start writing my own time-lapse app. As a short term workaround, just to see things work with what I have, I copied the file to my computer and used ffmpeg to convert the frame rate of my end-of-evening milestone video.

(The project discussed in this blog post is publicly available on Github)

Supercon 2017 Badge – Pan Base is Turning

After the mechanical bits were assembled yesterday, I worked on the simple PIC program I’d need to drive it. This involved refining the exploratory code into something that resembles an usable device. Things like no longer running on a fixed program but read the potentiometer I wired into the circuit to dictate motor control. Fortunately most of the hard work is done by MPLAB X boilerplate code, I only had to weak a few things here and there to end up with the functionality I want.

(The MPLAB X project file is publicly available on Github.)

I also 3D-printed the remaining layers of the enclosure – the battery tray, a minimalist lid, and the little flexible clips that hold them all together. The layers are an extremely tight fit because the wiring plugs were longer than I expected. Right now they’re pressed against the bottom of the battery tray which is not good for connector health. I’ll increase the height for the next iteration to give everything more headroom.

Pan Base Assembled

The good news is that everything runs. The bad news is that it doesn’t run very well. I dug a digital camera with a built-in time-lapse mode, set it on top of the base, and shot a few clips. The jittery motion of this cheap DIY pan base is very clearly visible in the resulting video. There’s a reason professional photography pan heads cost a lot of money – they have much smoother bearings and better motors for fine control.

Since the conference kicks off tomorrow, I’m going keep forging ahead with what I have. No time to find better motors or bearings. There are a few issues that I might be able to fix in the PIC software, but the sticky jittery motion from the motor and bearing isn’t something I expect to be able to fix in code.

Well, I can hope the jittery motion is not visible in the default 128×96 resolution of the camera!

Supercon 2017 Badge – Pan Base Mechanical Assembly

Hackaday Superconference 2017 kicks off tomorrow! Clock is ticking for me to complete my preparation work. My 3D printer is hard at work churning out iterations of my motorized base for panning photo/video. I had originally intended to drive the whole works with my three-cell lithium lion battery pack built from cells salvaged from a Dell laptop battery pack. The battery power will go straight to the power coils of the stepper motor and a voltage step-down converter will reduce the voltage for the ULN2003 chip driving the steppers and my PIC16F18345 running a program to run the works.

The stepper motor is designed for nominal operating voltage of 5 volts, but the actual limit on stepper motor operation is the amperage running through its coils. I thought I could drive the coils with pulse-width modulation and keep the power under control. The batteries power is about 12 volts, so a 40% duty cycle should be a good approximation.

But real life got in the way of my plan with these unipolar stepper motors. As the coils are energized and de-energized in the PWM cycle, magnetic field and electrical current were getting sent elsewhere in the motor in ways I didn’t understand. Causing the motor to behave erratically instead of just turning at a lower power.

If there wasn’t a looming deadline, I would hit the web searches to learn and understand what’s going on so I could fix the problem correctly. But I do have a deadline and needed a quick fix. “Just” running the motor at full power isn’t a solution. The motor could run at ~12V but it gets very hot. If I was only using the motor to turn infrequently, this might be OK. But a camera pan base is constantly turning slowly.

In order to keep the coils energized with a lower voltage, I changed the power supply to a 4-pack of NiMH AA batteries. Their nominal voltage of 4.8 is close enough for my purposes. It is smaller and lighter than the Li-Ion pack and also eliminates the need for the voltage regulator. The trade-off is a drop in power capacity… which may or may not be important. We don’t know yet. I guess I should pack a NiMH battery charger.

Once the stepper motor power was sorted out, I added a potentiometer to give manual control of rotation direction and speed. Once I finish 3D printing a case around this, I will have a minimal implementation of the mechanical base.

Pan Base Mechanicals

Supercon 2017 Badge – Time Lapse Pan Base

It’s Wednesday and a concrete plan is way overdue if I want to make a project for Supercon 2017 this coming weekend. The badge is a little digital camera so I started thinking about camera accessories that I could build. Since I won’t have the camera itself until Friday, ideally the accessory has some baseline functionality that I can build before I get the badge itself.

There are tons of accessories for photography, but when the goal is to find something both electronic and mechanical, that narrows down the list. Browsing through a photography catalog, I considered a few accessories and settled down on one thing: a pan base. Useful for taking panoramic photos or time-lapse videos, it boils down to a little mechanical platform to turn the camera at a controlled rate as it does its thing.

And most importantly: I can build something basic by this weekend and build upon it through the weekend as time and progress allows. This incremental development means if I don’t get to them all, I’ll still have something neat to show off. This minimizes the risk I’ll get to the end of the weekend and have absolutely nothing to show.

Phase 1: Base Mechnicals

Build the electrical and mechanical parts of the pan base. Digging through the boxes of parts on hand, I think I have everything I need to build the base itself: I have a small slow stepper motor, an associated controller board, a thrust bearing for everything to spin on, and batteries. A PIC with a simple program should be enough to drive the controller board for a slow photography panning motion.

Pan base parts

Hopefully I can get it all put together by Friday, ideally with manual control so it can run by itself.

If this is all I could do, it should be enough to put the camera badge on top and turn on video recording mode for a video that pans across the field of view.

Phase 2: Camera Time-Lapse Mode

If I get the mechanical base working on its own before Friday, it’ll give me time to dive into writing the software for the camera. I’ll need to understand the sample code enough to know what pieces I need to copy/paste to build a time-lapse video app for the camera. Hopefully it’s as simple as taking the video recording application and slowing the frame-rate down.

Once I know the code necessary to gather images and put them in a sequence, I’ll worry about creating the UI to control things like time-lapse speed.

If this is all I could do, it’ll be enough to create cool time-lapse panning video clips to enter into the video contest.

Phase 3: Camera+Base Integration

This is the stretch goal in case everything above was easy and smooth (ha!): Integrate the camera and the base so the time-lapse application controls the panning base. The UI will allow control of not only the frame rate, but also the rotation speed as the time-lapse runs. The camera badge already has a simple API for I2C communication, so I’ll probably have to write code to talk to the PIC controlling the stepper motor via I2C. Either that, or have the PIC32 on board the camera talk to the stepper motor board directly. Whichever is easiest to get running by the end of the weekend.

If I can get this far, I can feel proud at what I have accomplished over Supercon 2017.

Let’s see how far I get. It’s time to get to work!

 

Supercon 2017 Badge – Pivot for Project Risk Reduction

The calendar does not lie – it is now Tuesday and Superconference starts Friday. After a day of playing with mTouch on the Curiosity board, I’m no closer to a project that captures my fancy. Time to take off the curious explorer hat and put on the project manager hat. (Assuming that it’s not already too late to do so…)

The fact is that I won’t have the camera badge hardware in my hands until Friday. Despite all the help Microchip tries to give us with libraries for doing mTouch, capacitive touch is finicky and will require tuning. On top of having to get oriented with the rest of the hardware. On top of the rest of the conference going on over the weekend. I don’t want to be so consumed by the project that I miss out on interesting things happening.

I’m sure there are hardware hacker types who has accumulated enough skills and experience to put together something in a short time. I have ambition to build up to that skill level, but I have to accept the fact that I’m not there today. And I’m probably not going to get there by the end of the week. Time to change the focus to something more predictable and less risky for the sake of getting something up and running this weekend rather than risk having nothing at all by the end of the weekend.

The new ideals:

  • External components interface with the camera badge in some way to add to the camera badge functionality.
  • External components do not require the camera badge itself for its basic functions, so I can start building it and debugging it before I get the badge Friday.
  • Integration with camera badge to be kept as simple as possible.
  • Integration should not be “none” – it’d be pointless to build something that works just as well without the camera badge.
  • Even if all integration efforts fail (at worst, integration is “none”) I want to have enough to demo the idea even if it doesn’t work.

The above ideas led me to think about building an electro-mechanical camera accessory. The gears in the brain continue turning…. but soon physical gears will turn, too.

GearBase1

SevenStock 20

Today was SevenStock 20 and I attended with my RX-8 in her BB-8 Halloween costume. Last year I attended SevenStock with the costume only partially completed. This year it is complete but a little faded from running around over the past year under SoCal sunshine. It was still plenty distinctive in the row of RX-8 lined up in the show & display area. Many people took pictures, some even took me up on my hint and posted on Instagram tagged with #rxbb8.

Out of all the cars on display, the one that stood out to me was ironically not a rotary-powered vehicle at all. It was a Mazda R360, Mazda’s first car built in 1960. By modern standards an adorable tiny little thing. It was on display at the Mazda corporate area along with other Mazda vehicle currently on the market. Which meant the little 1960 Mazda was utterly dwarfed by the modern Mazda SUVs on display.

Mazda R360 Next To Current Mazda SUVs

There were many powerful speed machines on display, but I kept coming back to admire the little R360 that can barely reach highway speed. There are four seats in the car but I don’t see how four adults can fit in this little box. It looked closer in size to a kid’s Power Wheels car!


SevenStock takes place on the infield of the Auto Club Speedway and the track itself was open during the event for people who paid a fee and can pass safety inspection. There was a sizable contingent who love the idea of driving out on the oval but for one reason or another passed on the high-speed track time.

This year the organizers tried an experiment: a “parade lap” to get a taste of driving on a banked oval via a bit of token track time. The thundering herd was led by the trio of historical rotary-power race cars brought by Mazda, and we stopped a few times on track for the scattered pack to organize. Here’s a picture taken during one of the on-track stops.

Rotaries On Track

The price of admission for the “parade lap” was $15, and I thought it was well worth it for the novelty value of taking my car on a real high-speed track. Even if we were only going at city-street speeds.

What Happens When You Don’t Drain Water From Your Compressed Air Tank

Alternate title: I looked inside a corroded air tank and now I kind of wish I hadn’t.

During the disassembly of our thermoforming machine, we noted with worry that the compressor doesn’t have an air dryer between it and the tank, and that the tank is installed in such a way that the water drain valve is basically inaccessible. So any water in the compressed-air system (and due to basic physics, there definitely will be some) would have accumulated in the tank over its years of service.

A short while ago we got far enough in the rebuild to test the compressed air subsystem. Not surprisingly, the compressed air tank leaked and could not hold pressure. Upon closer inspection the leak appears to be rust perforation implying the inside is pretty rusty. So we replaced the tank instead of trying to patch it.

10 - Rusted hole

But I was curious: OK, it’s rusty. But how rusty? During a lull in projects (waiting for some parts to arrive) I pulled out the angle grinder, attached the cutting wheel, and merrily started making sparks.

20 - Grinder

As I made progress cutting, I noticed chunks of degraded metal were falling out of the gap I had cut. Not flakes of rust – chunks of varying color and texture. This is my first hint things are about to get ugly. Once I cut enough to pull away the end of the tank, we can see inside.

30 - Cut open

That’s far more corrosion than I had expected. And while most of the inside surface qualifies as “rusty” the bottom part deserves a stronger word. I can think of a few, but the only one I am willing to put in print is “Yuck”.

40 - Closeup

This sight is something I might expect to see in a home plumbing project fixing the sewer pipe. And this stuff has the soft squishy consistency of… well, the kind buildup you’d find in a sewer drain. This is not something I expected to see inside a piece of industrial equipment.

50 - Full Length

This layer has built up across the entire bottom part of the air tank.

I had originally thought it’d be neat to find the other side of the perforated hole but I was not in the mood to dig through this muck. Even while wearing gloves.

So let this be a lesson to everybody: If you have a compressed air tank, be sure to drain the water out of it regularly, or this might happen to you!

(Cross-posted to Hackaday.io)

Thermoforming Machine Low Amperage Systems Test

We got far enough wiring (and re-wiring) the thermoforming machine to perform an integration test of the low-amperage parts of the machine. This covers almost everything except the heating element.

LowAmpTestSuccess

On the previous test of the compressed air subsystem, we found a leak in the air tank. The leaky tank has since been replaced and this will be a test to see if it works with everything else.

The vacuum subsystem had also been partially tested earlier. For the previous test we only got as far as the vacuum table solenoid. This time we also have the vacuum lines between the solenoid and the vacuum table.

The relay panel had been tested with the following configuration:

  • 24V bench power supply as the input.
  • Manually connecting the control wires in turn like an old style telephone switchboard.
  • Multi-meter reading the output.

This time, the test will put the relay panel in a more realistic configuration:

  • Power will come from the 240V AC to 24V DC power supply on the DIN rail.
  • The control signals will come from the manual operation toggle switch panel.
  • And the most exciting part: the outputs are going to the actual air and vacuum components!

There was much anticipation and trepidation when the power switch was thrown the first time and we see LED indicators on the power supply indicating the system was live. Every switch thrown was a “Will it work?” mystery. The test did its job, exposing a few wiring errors. Fortunately none of them were damaging mistakes and all were trivial to fix.

At the end of the evening, we could control everything except the heating element using the manual operation switch panel: Move all the air cylinders, open and close all the air valves, and activate the electromagnets that hold the frame closed.

We still have lots of things on the to-do list, including some air leaks to track down and fix and plenty of wiring tasks. And there’s still the big intimidating heating element looming in the near future. But all in all, a wonderful morale boosting step on the journey to completion.

(Cross-posted to Hackaday.io)

The Ever-Growing Wiring Job

When we started on this thermoforming machine rebuild project, one of the first things we did was to open the control panel. We looked at the nest of wires back there and tossed the whole tangled mess. Those control wires were a basket case we’re happy to leave behind. But the rest of the machine – the power cables and such – looked OK at first glance.

Unfortunately, they don’t look as good after the second or third glances. Sometimes it’s not a glance at all – it’s seeing (and feeling) them fall apart when we worked in the machine. We expected the wires to be old, and kept our eyes open for signs of aging wires. We just didn’t expect to see them quite so often! This particular example was from the back of the air compressor. When we wanted to clean up the air compressor, we had to disconnect these wires. The act of moving the wires for access and removal broke the age-hardened insulation in many places. So now we have to replace it.

Failing insulation

Every time we get to work on a new area, we find that a new bunch of wires need to be replaced. We’re rapidly approaching the point where it might be easier to rip out every single wire and restart from scratch.

Wiring is tedious work, part of why good electricians make good money. For us, it’s a very real threat against project completion. We’re interested in having our own thermoforming machine, but that interest tends to drop every time we discover 2 new wiring tasks for every one completed. It’s a race to complete before everyone loses interest in the project.

Hopefully the work will be much easier – or at least more rewarding – once the wiring is complete.

Assuming, or course, we get there…

(Cross-posted to Hackaday.io)

Vacuum Table Frame Removal

Around the periphery of the vacuum table on the thermoforming machine, the previous owners built a perimeter using L-brackets. The presence of the frame made sense to help seal in the vacuum. The mystery is the height: The vacuum table and its surrounding frame are the same height as the combined height of the top and bottom parts of the frame holding the workpiece. We had expected the vacuum table to be aligned with the bottom part of the frame, since that’s the height the workpiece will be held at. As this frame is double the height, it would have impacted the workpiece on the way down. We’re left scratching our heads figuring out why this is desirable.

But that mystery isn’t important right now. Since we intend to put this machine to work on low-volume hobbyist projects, we will want to change the size of the workpiece frequently. This would be difficult with the existing system, since changing the size of the workpiece means changing the surrounding frame, greatly increasing the up-front setup work. It might be fine for a commercial production machine but such a barrier on a hobbyist machine would probably mean we’d be too lazy to actually use it.

We’re bouncing around a few ideas that should make it easier to change the size of the work piece in the machine. All of those ideas are incompatible with this existing taller-than-expected frame, so it needs to be removed.

A few jabs with a metal putty knife got things going and the frame popped off shortly afterwards.

Frame Removal

Then the tedious part starts: the putty knives went to work scraping off the sealant that was liberally applied to the bottom of the frame.

Putty Removal

Part of the motivation to invent a new vacuum sealing system is visible here: this surface is quite scratched up and rusty. To make it seal properly with the old system, we need to remove all the paint, sand things flat, and put on a new smooth coat of paint. If we can avoid that work with a clever new sealing system, we’d be happy.

(Cross-posted to Hackaday.io)

Vacuum Subsystem Test

Since we just tested the air subsystem and found problems that will probably require buying parts from McMaster-Carr, we decided to perform a vacuum subsystem test with what we already have on hand to see if we need to add anything else to the shopping list. Only some of the fittings and vacuum lines have been replaced, and the vacuum table itself is in pieces, but we can put together enough to test the vacuum pump, the accumulator tank, the solenoid-actuated vacuum valve, and the fittings and lines connecting them.

We were happy to see the system could generate vacuum beyond an indicated 25 inches of mercury. This measurement is taken with a grain of salt coming from the old vacuum gauge that was on the machine. But while the absolute value (“25 inches”) might be suspect, the relative value is still useful information. We shut off the vacuum pump and went to work on other things. After 15 minutes, the vacuum held steady enough that there was no visible movement of the needle.

Vacuum Holding

The next test is the rate at which vacuum is generated. We don’t need it to be super fast, but we don’t want it to be the limiting factor in cycle time. As soon as the softened workpiece is pulled against the mold, the vacuum should start building back up. It can continue doing so as the completed workpiece is removed and the next workpiece is loaded and heated. By the time the next piece is heated, we want to have sufficient vacuum in the system ready to go instead of having to wait.

Using the solenoid, we opened the valve and admit air into the system, dropping the vacuum down to an indicated 5″ Hg. We closed the valve and started writing down the vacuum reading relative to a stopwatch.

Vacuum Recovery

The recovery rate is acceptable. After one minute it was back up to an indicated 23″ and 90 seconds brings us to 25″. It didn’t have much grunt beyond that – it took double the time (an additional 90 seconds or 3 minutes total) to reach 26.5″, where the needle stopped moving.

We expect a new pump to recover vacuum more quickly, and provide a stronger vacuum, than this tired old thing. But this performance indicates the vacuum pump will not be the limiting factor in our cycle time and that’s good enough.

(Cross-posted to the Hackaday.io project page.)

New Compressed Air Fittings and Lines

We’ve just completed the milestone of replacing the compressed air fittings and lines in the thermoforming machine being rebuilt at Tux-Lab. We replaced the fittings because we expect the old air seals within them to have decayed with age. Since we have everything disassembled, replacing them now is relatively easy and reduces many potential points of failure.

New Air Fitting

The same logic also applied to replacing lines carrying compressed air throughout the machine. For extra bonus, the new air lines are blue and the old ones are green, making it instantly visible which pieces have been replaced.

New Air Line

Once the compressed air subsystem was buttoned up, we wanted to do a subsystem test. Since we have yet to wire up the 220V power distribution, we can’t run the built-in air compressor just yet. So we unplugged the output port of the air compressor and plugged that into the shop air.

Loud hissing announced the presence of a leak in the system. We felt all around the newly installed air lines and fittings, but the source of the leak wasn’t any of the new stuff. We eventually located the source of the leak to the compressed air tank that we had not yet touched. Before this test, the quality of the air tank was a question mark. Now that we have finally pulled it out and gave it a good look, we have answer to that question!

Holey Tank

During disassembly we noted there was no air dryer between the compressor and the tank, so moisture would have collected in this tank. There is a fluid drain port (not visible in this picture) but it doesn’t look like it has ever been used. This hole implies the inside of the tank is a rusty mess and a hole patch repair would only be a futile short-term solution. If we want a self-contained machine not dependent on shop air we will need to replace this tank.

After this discovery, we disconnected the air line from the output port of this tank and hooked that up to shop air. It allowed us to test the rest of the machine.

  • The mechanism to move the heater rearward seems OK.
  • The mechanism to move the heater forward has a leak that needs to be investigated.
  • Trying to move the heater forward/back repeatedly showed no problems (aside from the above leak.)
  • The mechanism to move the frame up/down each seems OK individually.
  • Trying to actuate up/down movement rapidly would cause the two sides of the air cylinder to fight each other. We are missing an air relief mechanism somewhere in the system. Either we forgot we removed something during disassembly, or an existing relief mechanism has plugged up.

(Cross-posted to the Hackaday.io project page.)

Raspberry Pi Pin Initial States are a Consideration For Machine Control

As an intermediate step towards controlling the thermoforming machine with the Raspberry Pi, we populated a breadboard with some components we planned to use. A Raspberry Pi could only source a total of 50mA of power across all the IO pins, so we had it switch circuits on/off via opto-isolators that required far less current to activate. We started by using these opto-isolators to control power to LEDs. Just to see how it works and make sure nothing unexpected occurs before we start hooking up bigger things.

This proved to be wise, as it exposed some Raspberry Pi behavior we did not expect. When the Pi was powered-up, some of the LEDs glowed dimly. They’re not full bright, but they’re definitely not dark, either. Once the control program starts up and all pins are initialized to off, they go dark as expected. But there’s something going on between initial power-on and when the control program starts running.

This was important to chase down because we don’t want the machine relay to close when we’re not expecting them to close. Even worse if it occurs while the system is powering up and components are not yet in known good states. Making this an important consideration in designing our system.

A bit of web searching confirmed this startup behavior was noticed and investigated by a lot of people looking at various parts of the system. The answer was most succinctly answered by a post on the Raspberry Pi subsection of StackExchange: In the peripherals manual for the BCM2835 chip at the core of the Raspberry Pi, the power-on initial states are explicitly stated: All IO pins are configured to be input and not output. Furthermore, pins 0-8 are set with pull-up to 3.3V and pins 9-27 are pulled-down to 0V.

Looking back on the breadboard, we could confirm the explanation matches the observed behavior. The dimly lit LEDs were controlled by opto-isolators that were, in turn, connected to Raspberry Pi pins 5 and 6. None of the other isolators were controlled by pins in the 0-8 range. Since opto-isolators required so little current to operate, the weak pull-up on a pin set to input was sufficient to partially activate the circuit.

Once the cause was determined the solution was simple: move all output control out of the 0-8 range of pins. These pins would be fine for input, so the task of reading the position of a limit switch was moved to pin 5.

The resulting breadboard is visible in the attached image, and the code was changed to match the new pin assignments in this commit. After these changes, we observed no partially lit LEDs which also hopefully means no unexpected relay activity when we hook it up to the machine.

IMG_5266

Setting Up Raspberry Pi GPIO Pins For Device Control

A rough draft of the thermoformer touchscreen control panel application, witting in Python with the Qt UI framework, is now up and running. Now it is time to see how it works controlling some physical hardware. We’re going to build up to this in steps on the way towards actually controlling the thermoform machine. The first step is to have the Pi light up some LEDs as commanded by the control panel application.

I had been playing with a Microchip PIC16F18456 earlier, which can drive LEDs effortlessly. Each pin can handle 50mA which is more than enough to drive LEDs as they typically require no more than 20mA each. I had assumed the Pi would be even more capable with its onboard voltage regulators, but I thought it’d be better to check just to be safe. I’m glad I did! It turns out the pins on the Raspberry Pi has significantly lower power capability than the pins on the PIC16F18345.

The consensus on the Raspberry Pi forums says the limit is 16mA per pin, and 50mA total across all pins. A bunch of LEDs would quickly exceed the 50mA total cap. Given this, we’re going to take two baby steps at once.

We’ve known we couldn’t drive the thermoforming machine directly with Pi. And even if we could, a direct connection is not the best idea. The plan had always called for the use of opto-isolators to keep some separation between the delicate low-power circuitry on the Raspberry Pi chip and the high-power components of the machine. I just didn’t expect that bright LEDs to qualify as “high power” in this context. But since they are, we’re going to use opto-isolators to build the LED proof of concept.

The current design for the control has 9 outputs to relays, and 1 input from a limit switch. For the outputs we’re starting with the Vishay 4N32 chip to see how they work. For input, we wanted a chip that works in the reverse direction, and we’re starting with the Toshiba TLP2200. With the help of a Raspberry Pi I/O breakout board we could hook everything up on a breadboard for the first test.

IMG_5266

Learning Timers: Qt QTimer and Python threading.Timer

QtLogoWhen I interfaced my PyQt application to the Raspberry Pi GPIO pins, I ran into a classic problem: the need to perform input debouncing. The classic solution is to have the software wait a bit before deciding whether the input change is noise to be ignored or not. A simple concept, but “wait a bit” can get complicated in the world of GUI programming. When writing simple programs, we can probably get away with a literal wait by “going to sleep” for a little bit. But we don’t have that luxury in the world of GUI programming – going to sleep would freeze everything in the program. In general, users do not appreciate their UI becoming frozen and unresponsive.

Python LogoThe solution: a timer. In a Windows application, the programmer can use the operating system timer and do their “after waiting a bit” tasks in response to the WM_TIMER message. I went looking for the Qt equivalent and found several timer-related features. QTimer, QBasicTimer, and QObject::startTimer(). Thankfully, the documentation also provided an overview describing how they differ. For debounce purposes, the most fitting mechanism is a single-shot timer.

Unfortunately, when I tried to use it, I received an error message telling me I could only use Qt timer objects from code launched with QThread. Which apparently wasn’t the case with code running under the context of a QWidget within a QApplication.

I had hoped the Qt timers, working off of the QApplication event queue, would stay on the UI thread. But it appears they have to have their own QThread. I could put in more time to figure out how to get Qt timers to work, but I decided to turn to Python library instead. If I have to deal with multi-threading issues anyway, there’s no reason to avoid Python’s Timer object in the threading library.

It does mean I had to review my code to make sure it would be correct even if called from multiple threads. Since the important state are the status of the GPIO pins, they are handled by the pigpio library and the code in my app should be fairly safe. I do set a flag to avoid creating multiple Timer objects in the case of input bounce. If I cared about making sure I only ever create a single Timer, this flag should be protected against cross-thread access. But reviewing the code I decided it was OK if a few Timer ends up being created – the final result of reading the GPIO pin should still be the same even in the case of multiple Timers doing duplicate work.

(The project discussed in this blog post is publicly available on Github.)

Notes on “ZetCode’s PyQt5 Tutorial” From a Windows Developer.

QtLogoOnce I decided to learn how to create a GUI application using the PyQt5 Python binding for the Qt framework, I looked online for some resources to get started. The reference guides for PyQt5 and Qt version 5 itself seems to be fairly robust, but I needed a little push to get over the initial learning curve to understand where to look for what I need.

The Python Foundation’s wiki for PyQt tutorials has a fairly long list. But when I looked, only one explicitly states it is for PyQt5. So off I go to Zetcode’s PyQt5 Tutorial. It was a very bare-bones tutorial that might be a bit too bare for a complete beginner trying to learn GUI programming. But for somebody who already knows the general concepts of a windowing graphics interface system, it is a quick primer to learn the vocabulary.Python Logo

Since I’ve worked with various flavors of Windows frameworks (from raw Win32, to MFC, to WPF) I just needed a tutorial to help me connect concepts in my head to the terminology used in Qt. For example: in Qt, when something happens, a notification called a “signal” occurs. A signal can be connected to a “slot” which can then respond to whatever just happened. Once I learned this, I was able to translate the concepts into my head: a “signal” is an event that could be raised, and a “slot” is an event handler. Once I got this and a few other basic “Rosetta Stone” translations in my head I could switch to the reference documentation to find answers.

One important note: Even though it is labelled as a PyQt5 tutorial, Zetcode’s tutorial is actually pretty much the PyQt4 tutorial updated with the changes to syntax needed for PyQt5. It doesn’t actually cover anything that is new in Qt5. For me this is fine, because the “old way” covered in the tutorial is probably what I’ll end up using when I go even further back in time for the ROS flavor of Qt.

But know there’s no coverage of the Qt5 advancements in declarative interface construction, hardware-accelerated rendering, etc. Anybody who wants to learn the new toys of Qt 5 would have to look elsewhere.