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!