Archive for July, 2015

Pneumatic Controller: Part 5

First some coding, then building with pictures.

As promised, I’ve started on the main part of the code and testing the pistons and sensors. Because I didn’t want to go through the entire setup process each time I checked something, I got rid of all that and just gave some initial values. Then I made a small script to print out all the variables used (such as if a piston was in or out, or how many cycles it has done) so I could keep track easily.

I ran into two problems very quickly. One was that I couldn’t seem to make cycle periods (time in between cycles) that weren’t integers (I could only do 1s, 2s, 3s and not 1.5s, 2.75s, etc). The other was that the entire script was only running about once every two seconds. This second one was particularly frightening because I had expected it to run several hundred times a second and the fact that it was so slow implied that my code was outrageously inefficient. Now as a mechanical engineer, my programming education focused less on efficiency than a computer science major’s would. We learned a bit about it, but for our purposes, the difference between a very efficient code and a kind of efficient code were minor. My worry here is that my code was doing so much (which seemed dubious) that it was crossing that border into CS land, and I would have to learn a lot more about efficiency before continuing, something I was not looking forward to for a section I thought to be pretty simple.

Turns out both problems weren’t too bad. For the first, it was an issue of variable types. Two of the types you can use for numbers are int and float. An int (like integer) is a whole number (1, 2, 300) and a float is a decimal (1.5232., 6.5, 24.23542). There are other difference but this is all we need now. Because I wanted the cycle periods to have the option of times in between whole numbers, I used floats. What I neglected to realize, however, was that if you divide a float by an int (like 3.5/10), you will get an int. This meant that my program was constantly rounding these numbers and ignoring the decimal. The fix was just to change the 1000 I was using to 1000.0.

The next problem was trickier, only because the first problem helped it along. At one point I suspected the printing function was slowing it down, but when I removed it, it was still too slow. Turns out it was still slow because of the first problem. Once that was gone, I got rid of the function and the program ran smoothly and quickly.

Now the picture part. First up was some cleaning. The box had lots of wires and components that I wouldn’t be using, and they took up real estate and made everything more confusing and messy.

So one of the first things I did was to gleefully take out anything I wouldn’t be using in my version. Besides the controller and LCD, this meant about 12 miles of wiring. I left the buttons on the face of the lid in after disconnecting them, though, in case someone wanted to use them later. All I wanted was the transformer, pressure switch, and emergency shutoff button.

Cleaned up lid

Cleaned up lid

Cleaned up inside. You didn't see it before, but it was quite a mess

Cleaned up inside. You didn’t see it before, but it was quite a mess

The other thing I did, although it was after I took the picture, was to move the pressure switch (top left of above picture; black thing on grey thing connected to blue tube) to the bottom, basically flipping along the horizontal. This changed nothing in terms of the workings of the system, but gave me a lot more room on top.

Next, the main program. To test the program, I first wired up some LEDs, since they would be much easier to work with than pistons.

Arduino testing with LEDs

Arduino testing with LEDs

More Arduino testing with LEDs

More Arduino testing with LEDs

This showed me that at least the code worked (eventually). Next was to test it with an actual piston. For this, I used code that just opened and closed the solenoid every one second. All I wanted to know was whether the circuitry worked.

Arduino testing with a single piston (IN)

Arduino testing with a single piston (IN)

Arduino testing with a single piston (OUT)

Arduino testing with a single piston (OUT)

It did.

Next up was to make the permanent circuitry for the solenoids. This would be what went into the actual box when I was done. Luckily, when I cleaned up everything, I was left with these little connector things that had been used a lot. I had planned on ignoring them, or even getting rid of them to save space, but I actually found them incredibly helpful. Besides making connections a lot easier, they hooked onto rails that were installed in the box, making everything neater.

Cool attaching things for solenoids

Cool attaching things for solenoids

I put together the breadboard and wired it all up.

Solenoid circuitry

Solenoid circuitry; wires on left go to Arduino

I do not have pictures but I did test all the solenoids and it worked beautifully. For the Arduino end of this (coming out of the above picture on the left), I used some ribbon cable with one end soldered onto the resistors (above) and the other soldered onto male headers that would plug into the Arduino (below).

Pins for solenoids

Pins for solenoids

I had wanted to plug these wires into male headers directly, but the ones I bought were too short.

Finally, I rewired everything so that the pressure switch and emergency shut off button would still disconnect power to the pistons, and began setting up the rest of the circuitry.

All in all, it was a good week. On Monday, some more transistors and resistors arrived (UL had the oddest and least helpful collection of resistors) and so I can start putting together the sensor breadboard. I’m looking to finish in the next week or so (fingers crossed), depending on my workload.

Until next time!

Ari

Advertisements

Pneumatic Controller: Part 4

This is the post you’ve been waiting for! The one that shifts away from blocks of text and has more pictures. They should be more like this for a while.

Today I finished the debugging of the setup program! It now takes input, stores it correctly, and allows changes to be made in the confirmation section. There were many issues but they’re all gone now. While it’s possible that I’ll run into problems later on, those shouldn’t be too hard to deal with now that the more complicated stuff is done.

The other, more visual/shiny, thing I did today was make a more permanent base for the LCD/keypad. As lovely as electrical tape is, this one is much stronger and more stable, plus it looks a lot nicer.

DSCN2086 (1)

Arduino screwed into the board 

DSCN2085 (1)

LCD on the Arduino

DSCN2083 (1)

Keypad attached to the LCD

DSCN2081

Keypad screwed onto the base (the three nuts in the center are from the Arduino)

DSCN2082

Keypad screwed onto the base (the three nuts in the center are from the Arduino)

DSCN2079

Full assembly

DSCN2080

Full assembly – Side

DSCN2078

Full assembly – Top

Since the final version will have more things stacked on top, the Arduino won’t fit in this base. Plus, the lid to the box (which you will see in a later post) holds the LCD and tends to slam down, so I’d prefer to not have the brain of the operation jostled so much. But some of it should be salvageable and for now it’s perfect for my needs.

Tomorrow I start working on the pistons, sensors, and the main part of the code. Huzzah!

Ari

Pneumatic Controller: Part 3

That’s right, Part 3! Take that, Hand Typing project!

You will not believe how simple the solution to my interrupt woes turned out to be. I tried the code again with the Timer1 Arduino library and was able to use timer interrupts and the LCD, but still couldn’t change the LCD from inside the interrupt. While looking online, I found someone saying how interrupts were disabled inside other interrupts, but you could re-enable them.

Now until this point, I had thought that interrupts were disabled just as a function of how they work, but it seems that they are only disabled with the assumption that if you wanted to stop whatever you’re doing to do the interrupt, you probably don’t want to be interrupted while in it. But in my case, I did so that I could print to the LCD.

interrupts();

That’s it. That is literally all I added to the timer interrupt function to make it work perfectly. It is frustratingly simple. Anyway, it worked.

Luckily (?), it still had some problems. The timer interrupt had some confusion with the scrolling and would sometimes, but somehow not always, print random characters all over and stop the flow of the program. Naturally this was not something I wanted.

I thought of two solutions. The first was to change from an automatic scroll to one that scrolled when a button was pressed, using an external interrupt. This was significantly worse for some reason.

The second way was to get rid of the interrupts entirely.

“But Ari,” you exclaim. “You spent so much time getting them to work. They were so special to you!”

That’s true, imaginary commenter. But an important lesson i learned about writing papers is to kill your darlings. As much as I liked having timer interrupts in the code, ultimately they made it more complicated and worse than it needed to be.

So what would I use instead of interrupts? Well, the normal way would have been to just check for scrolling every loop through this part of the code, but I hadn’t originally because parts of the code stopped and waited for input, which would leave a break with no scrolling. What I realized is that only one function actually used the scroll function anyway so all I needed to do was reorganize it to use a loop instead of waiting (for those who have used the Arduino LCD, it was a switch from waitForKey() to getKey()).

This worked and the program now scrolls lovelily (it’s a word, look it up). It even makes the program a bit faster because there’s no extra memory taken up by interrupts and libraries. Hooray!

Besides a couple of smaller changes, the main thing I did last week was to make a temporary assembly for the keypad/LCD. Until now I had been leaning the keypad as best I could but this got a little annoying. I couldn’t put the full assembly together because I haven’t decided how things will be stacked (probably: Arduino – Generic shield to make disconnecting the Arduino a one step process – All wires besides the LCD – LCD), so I taped them together as best I could.DSCN2071

DSCN2072DSCN2073

The nice thing is that the keypad was built with a window for the LCD, so everything looks all neat and shiny. The text displayed is from the beginning of the setup and is asking how many pistons to use.

Things continue to go well with no obvious problems foreseeable. I hope to finish the debugging of the setup program this week and then start assembling/testing the actual pistons.

Until next time!

Ari

Pneumatic Controller: Part 2

First things first: I added the picture of the sensor setup to the first part post. Done.

Next, solenoids. Monday I was able to start working with the actual transistors and found that, lo and behold, they had the same problem! That was somewhat disconcerting, especially after I tried them with multiple combinations and checked and rechecked all the connections. Finally I tried it with one the lights from the original system (they took the same power as the solenoids) and had no problem.

At this point I began to think that although normal solenoids, which just open or close a single valve, don’t care about the direction of current (I think), maybe these ones did. These solenoids controlled two valves each and would normally have one open and one closed, and when power was applied, would switch them. This is really helpful in terms of programming the controller because it means that each piston only needs one command to change direction (either open or closed, instead of open-closed and closed-open), but I figured it might effect the current. Naturally, the easy, 5 second switch of wires fixed everything and the solenoids worked perfectly and, most importantly, I felt dumb. But I learned.

The diagrams I’ve been working from for the transistors is below.

Briefly leaving the Ari Made Himself Feel Dumb portion of the blog (don’t worry, we’ll be back shortly), I later figured out how to make Arduino functions with a variable number of parameters, not just a set number (it could be f(1) or f(1, 2)…). This was important because Arduino’s printf function did not in fact work like MATLAB’s sprintf function as I had thought, so I had to build my own.

To non-programmers, if I wanted to print a bunch of statements in the form of “It is cycle number X” and replace X with the cycle number, the easiest way is with this type of function. With it, I can put in placeholders and just tell the function what to replace it with each time. However, Arduino’s printf function didn’t work this way.

Naturally, once I was done I discovered that Arduino in fact did have something along those lines, namely the sprintf function. Although it works somewhat differently, it was good enough that I could use it. But since this mishap did lead me to learn something new about making functions, I’m considering it as a win.


Now we have a more interesting problem! The LCD I’m using has 2 lines that each can hold 16 characters. This meant that all the instructions and information I wrote for it had to fit in those spaces or else it would be cut off. However, there were some I couldn’t fit without making them too confusing, so I wrote a scrolling function that would shift them over every second or so (Arduino has such a function but it only works for both lines at once). The problem was with making it scroll even when the program was waiting on a step, such as the user inputting a number.

I had thought I solved this with the use of interrupts. Interrupts are basically magic functions that are separate from the rest of the program. While the rest of the program follows a specific order, whenever an interrupt is activated, it will stop the rest of the program and do its thing, only then going back to the main program. Usually, the program has to be specifically looking for a reason to do something, like checking for timing or an input, but interrupts are always checking (except when in a different interrupt). Most interrupts are external, meaning the Arduino gets a signal from outside itself, but in my case I wanted a timing based one, so it would scroll every half second or so.

However, when I tried it I found that nothing happened. I could make the interrupts work, and I could make the LCD work, but with both running everything would freeze. I had seen others use interrupts with LCDs so I couldn’t find the problem. At first I thought that only the timing based interrupts had this problem, so I considered using a timing based interrupt to turn on a pin that was connected to the input of an external interrupt. That way, a timer would activate an external interrupt which would then print to the LCD. Incidentally, that does work although the LCD still didn’t. Still, neat.

I also tried disabling interrupts while inside the interrupt (which you can do, apparently), then re-enabling them afterwards, but this didn’t work either.

Eventually it became clear that the problem was that the LCD shield I was using, used interrupts itself. This meant that the LCD couldn’t print anything because an interrupt was already running. I haven’t found a solution yet but I’m currently looking at a couple of options:

  • I found other people had this same problem and this person seems to have solved it. By connecting two pins on the shield and adding some code, they were able to use interrupts with the shield. This hasn’t not worked for me, though it’s unclear why.
  • It seems that only the buttons on the shield use interrupts and not the actual LCD. Since I don’t need the buttons anyway, I might be able to disable all the interrupts in the code and use my program normally.
  • Since the shield’s code is checking for interrupts anyway, I might be able to steal that interrupt pin and use it for my own purposes, then change the code to update the LCD instead of doing various button-related things. This might involve connecting a wire to the chip on the shield, but since it will be covered anyway it shouldn’t be an issue of loose wires.

All in all, I’m feeling good about the project and look forward to working on it this week.

Until next time!

Pneumatic Controller: Part 1

I’m back! I’ve actually been working on stuff, I promise. While some progress has been made on the finger typing project, I’m going to save that for another post and do this one about the pneumatic controller.

For those unfamiliar, the pneumatic controller project is something that I’ve been working on for a while. Briefly: I programmed a pneumatic cycle tester while working at UL, but due to the age of the system, decided that redesigning the electronics around a microcontroller would be a good idea. Until recently, I’ve only been able to work on the theoretical: designing the electronic layout, writing the code, making a BOM (bill of materials), and, more recently, making a user interface in Python to make using the system easier.

Well I’m now very happy to say that we are officially moving forward with the project.

This is by far the largest electronic/coding project I’ve worked on by myself. It involves several aspects I’ve never worked with before, such as LCDs, keypads, solenoids, and much longer code. While I think (and hope) that the project will be a success to the extent that I planned, I think that it will at least be better than it is now.

Here’s what’s happened so far:

Day 1 I bought the Arduino so I would be able to start right away and ordered the bulk of the components online. Other than the general program, which would be best to test in sections once the system is built, there were several things I wanted to test individually because they were new for me.

First up was the LCD. Turns out the LCD and keypad from the original Festo system could be detached from the extra electronics and used with the Arduino. This news was somewhat dampened by my breaking the LCD almost immediately. While the LCD was similar to what I would have purchased, the wiring was positioned differently and through an unclear combination of me getting confused by different schematics and the LCD being designed differently than most, it stopped working. It’s possible it never worked. Who knows?

But, up from the ashes grow the roses of success. In this case, success came through me finding out that Adafruit makes a deliciously simple LCD shield for Arduino and the keypad working after a very anticlimactic 10 minutes work. I’ve never used a shield before, but it looked fairly idiot-proof. I put the shield together on Wednesday with only a brief panic at how hot the IC got when I soldered it in, and it worked perfectly. A little more expensive than planned, but about the same as if I had bought both the plain LCD and keypad to begin with. Incidentally, shields fitting perfectly flush to the board and then working correctly is just the best feeling.

So beautiful

So beautiful

Next up were the sensors. I had been hoping I would be able to wire them directly to the Arduino, similar to how you would wire a button, but it turns out the sensors have 3 leads: power, ground, and signal. I tried a couple of methods before speaking to someone at Sparkfun (who have an amazing chat service, by the way) for advice. Eventually, I settled on using a transistor with a separate 24V power source for the sensors, as shown below. This worked great. I had never seen someone use transistors for a high power input before, so it was a neat thing to learn.

Finally, the solenoids. This should have been pretty straightforward (ha!) as it’s just a simple transistor circuit with an added diode, but naturally it was not. After determining that the solenoids needed at least 20V to run (although they could be held with 10V) I tried the circuit and found that while I could activate the solenoid, it would stay put even after the transistor wasn’t powered. I tried various combinations but found that nothing changed and the solenoid would only switch back when the main power was cut. I think this is probably because I was using a different transistor but I won’t know until I can try the real one on Monday. Still, progress.

That’s it for now. I’ve also been making changes and fixes to the code and diagrams. Next time I’ll be able to show you some of the other diagrams and, hopefully, actual pictures! I’m also hoping to update this fairly regularly, since I’ll be working on it at least somewhat every day. Here’s a picture of the new, more exciting, circuit diagram.

So exciting

So exciting

No promises for the finger typing, except that it will one day be done and published.

Goodbye for now!