Prime Lines with Mike and Dave

This week, Mike and I discussed the implementation of the Prime Lines function. We came up with a strong design for how it will work. It will basically consist of a few lines of php that will call the serial driver using different argument strings. The Prime Lines screen will have two separate areas, one for priming the entire system, and one for priming a single line. Each will call the serial driver using a string of arguments similar to the Pour Drink function. Using this, the system will open the valves for the lines to be primed just long enough to bring the liquid to the very end of the line. This function has been proven in concept, but cannot be fully coded until the length of the lines has been determined. This will be completed when we have cut the lengths of tubing for the system.

We also spent time working with a bug from a previous implementation that surfaced recently. This bug was in the Add Drink subsystem. It was allowing drinks to be added with incorrect liquids (or no liquids at all). We changed it so that it will work with all of the liquids.

Most of the primary functions are coming together. For the rest of the system, we need to have the parts arrive before we can really develop the software. A lot of the configuration can only occur after we have constructed the system.

~ Written by Dave Freitag and Mike McLain

A new prototype is “born”

This week I took two tasks upon myself… first being to use PHP to pass arguments to the C code developed by Dave and second to mockup a prototype using a two valve configuration.

PHP Passing

On passing values and arguments to the C code: This task was relatively straight forward, as I thought it would be. I simply build a string within the PHP script that contains the correct arguments and values to control the valves. This looks something like:

$runString = "serialDriver " . $glassSize . " " . $liquid1Port . " " . $liquid1Amount . " " . $liquid2Port . " " . $liquid2Amount . " " . $liquid3Port . " " . $liquid3Amount

Above:

  • runString is the variable name for the string I am building
  • glassSize is set with a call to the database class to get the either chosen glass size or default
  • liquid”n”Port is set by a call to the database class to get the array of liquid ID’s and their corresponding port number
  • liquid”n”Amount is set by a call to the database class to get the amount of each liquid in a drink by drink ID and store it relative to the liquid ID

Next I’ll use the execute command (exec is a built in PHP function) to run the compiled C code and pass the variables to it.
exec($runstring);

As you can see, the string I just made is then simply passed, via the exec command, as a system command and executes the serialDriver.

Two Valve Prototype

The building and configuring of the two valve prototype was not a hard task, it just took a little bit of actual construction. We first had to split the CO2 line so that we had two separate lines for powering the flow of the system. Next we wired up the harness to accommodate two of our 12VDC valves and created a system of “daisy-chaining” the ground line through the Relays (as to minimize the amount of wire clutter). Then we hooked up all the air and liquid lines and tested with system calls to pump from the two different bottles and finally we used the C driver to control the whole thing!

All in all it was a successful and productive week with a lot of progress made!

Note: I also helped Mike with the interstitial page and passing of the information from page to page. And last but not least, I ordered the rest of the hardware, which includes but is not limited to:

  • 14 more valves
  • CO2 manifold
  • Connectors and Quick disconnects for the manifold
  • Various tube fittings
  • 1-way flow valves
  • Rubber Stoppers (for bottle assemblies)
  • Tube clamps

Next up is making a 4 valved prototype and starting construction on the actual housing of this “beast”.

Serial Driver

The driver is, for the most part, finished.  It can now take the glass size and a set of port numbers and amounts, and convert them into system calls.  It also calls the appropriate delay between  each call.  The order of calls is as follows:  driver.exe   -glass size-  -first port #-  -first amount-  -second port #- …..etc.  The most difficult part about this was figuring out how to handle strings in the C language.  Currently, it outputs the calls to the screen using a Linux machine.  It will be tested tomorrow (or sometime soon) on the actual machine, and the calls will be sent to the command line rather than simply being output.  Then, we just need to have the php code call it when a drink needs to be made.

More Interstitials

The interstitial page is almost completed. We got the Add Drink page to concatenate the drink name and liquids into separate arrays in the $GET array. Now we are trying to get the glass sizes (default and overall possible glasses) to become concatenated into the array from the interstitial pages. We have one interstitial that works and adds the default glass to the URL for GET method, but we need a second interstitial to pop up immediately afterwards so that the user can select which glasses can be used to make the drink in. This second page is what we are stuck on right now. It won’t concatenate and continue onto the configuration page.

We’re going to get the database query formed up as soon as the interstitial passes to the configuration page. We’re all thinking it should take very little time to get the data passed into the database once we get the $GET array completely formed. The array accessing will look something like this:


//$_POST['drinkName']
$name = $_POST['drinkName'];


//$_POST['liquid']
$liquidArray = $_POST['liquid'];

//$size = sizeof($liquidArray);
for($i=0; $i<16; $i++)
{
if(isset($liquidArray[$i]))
{
//amount stored in this index is the amount for the index $i
//echo "Liquid ID " . $i . " is " . $liquidArray[$i] . " percent of the drink";
}
}

Serial Driver for PHP to Port Interface

This week we worked on testing the pumps for the liquids. I also began work on a new driver program that will serve as an interface between the PHP code and the hardware. The program will be called with a string of arguments. These will include the glass size, the port numbers that the liquids are connected to, and the percentage of each liquid in the drink. It then takes those values and computes the number of ounces per liquid based on the percentages and the glass size. From there, it will convert the ounces for each drink into lengths of time. We will use these times as delays between turning the ports on and off. Last night, we determined that it takes just over 2 seconds for the system to pour one ounce. This number will need to be recalculated once we have a permanent solution for the bottle caps. The next step will be creating the system calls from the current data that is passed to the program. The pumps work well, and as soon as we can get the second pump connected, we can begin testing actual mixes.

Interstitials? Yes, please.

With the cooperation of Derek, we managed to find an interstitial code segment from Dynamic Drive (www.dynamicdrive.com). We had some issues getting it implemented (mostly due to my stupidity with a spelling error in the location of the referrer…)

The interstitial runs from a fairly complex Javascript file that we’re including based on a document referrer that checks whether the previous page is the ‘addDrink.php’ page. We did this using the following PHP script segment:


<?php
if($_SERVER["HTTP_REFERER"]== "http://lab.derekfernholz.com/SCABMS/test/addDrink.php"){
echo '<script type="text/javascript" src="interstitialOn.js" charset="UTF-8"></script>';
}
?>

The Javascript file uses an array of statements to control what pages are displayed, the frequency of the display, the formatting of the header on the interstitial, cookie settings, bust caching pages fetched by Ajax, whether the scrollbars are disabled or not, and a timer for an auto hide on the interstitial. The code in the JS file looks like:


var interstitialBox={
//1) list of files on server to randomly pick from and display
displayfiles: ['samplecontent.htm', 'samplecontent2.htm'],


//2) display freqency: ["frequency_type", "frequency_value"]
displayfrequency: ["chance", "1"],


//3) HTML for the header bar portion of the interstitial box
defineheader: '<div class="headerbar"><a href="#" onClick="javascript:interstitialBox.closeit(); return false"><img src="closeit.gif" style="border: 0" title="Close Box"/></a></div>',


//4) cookie setting: ["cookie_name", "cookie_path"]
cookiesetting: ["stitialcookie", "path=/"],

//5) bust caching of pages fetched via Ajax?
ajaxbustcache: true,

//6) Disable browser scrollbars while interstitial is shown (Only applicable in IE7/Firefox/Opera8+. IE6 will just auto scroll page to top)?
disablescrollbars: true,

//7) Auto hide Interstitial Box after x seconds (0 for no)?
autohidetimer: 0,

Now, we just need to get a page made up for displayfiles[] that is going to show the different glasses that are selectable for the drink. It will also allow the user to input a default glass along with the other available sizes. The difficulty is going to be getting the items (the selected glass sizes) from the interstitial to the configuration page so that they can be sent to the database along with the rest of the drink information.

As for the SQL query to get the drinks added into the database…that’s yet to come.

Prototyping: A functional exploration

The mission that was set before Dave and myself this week was to create a functional prototype of our system interfacing with the valves through the relay and to actually control the flow of liquid using our CO2 powered system.

Tube Coupling, the finer points

The first task was to find fittings and or couplings to attach a length of 3/16″ inner diameter tubing to our 5/16″ inner diameter regulator output on our CO2 tank. This was finally accomplished after a few trips to the local Lowe’s and acquiring a few pipe threaded barb fittings and a length of 5/16″ inner diameter tubing. What this allowed me to do was connect that piece of tubing to the regulator and then connect the other end of that tubing to a 5/16″ ID barbed fitting that had a 1/4″ threaded pipe fitting on it. Next I connected a similar piece of hardware to the length of 1/8″ ID and using a 1/4″ Female to Female pipe coupler was able to have a successful “down-scaling” of tube sizes.

Pumping, the cap saga

The biggest issue yet to resolve is to find a solution for connecting this tubing to a bottle cap or stopper assembly. For this prototype I simply drilled to 1/4″ holes in a bottle cap and hot glued two lengths of 1/8″ ID tubing into place. Then I connected this assembly to the CO2 lines and also to a 12VDC valve. Next I connected the power to the valve and ran the ground wires through the relay terminals, this way when the relay is turned on (or the “switch” is closed) a connection is actually made and current is allowed to flow and to open this normally closed valve.

PHP, a useful timer

As of last week we had a working proof of concept that we could run C code through PHP and manipulate the ports on the relay. This week I took it a step forward and using PHP’s built in date function wrote a small script that checks the start time and then keeps checking back for a predetermined length of time to elapse. This method can be accurate down to the millisecond and we are currently experimenting as to whether this is the best method to use. I made my script run for 10 seconds, ran the script and collected the pumped liquid in an empty container. I found that this method, in conjunction with a controlled 5 p.s.i. pressurized system made for very consistent pours. The amount of variance was practically undetectable to the naked eye and that result made me quite pleased with our progress.

Onward and Upward

Next I plan to further investigate timing and calibration methods as well as further research on a permanent cap assembly. One other thing that I will be attempting is pumping 2 different liquids to make a test “mixture”.

Note: as soon as I find my camera charger I will be uploading a video of the prototype working! :)

Adding Drinks, Part Deux

Nothing to add this week.  Been pretty busy trying to get programming languages churned out.  I did talk with Derek about this earlier in the week.  Pretty much, there are a lot of inter-table checks that are going to need to be done when creating the SQL script.  There are going to need to be checks against the liquid IDs to make sure that the liquids needed in the drink are actually IN the system.  Also, there is a need to check, logically, if the drink is already in the database.  One thing I want to talk to Derek about is the possibility of having multiple of the same drink names with different ingredients (i.e. Liquid Cocaine is a shot and a drink, with completely different ingredients.)

I’m going to get together with both Dave and Derek sometime early in the week, hopefully before the meeting if possible.  Derek, to talk about how to create the interstitial pop-up page for adding the drink (i.e. showing a page between the final product and the last configuration page to confirm the settings for the drink) and Dave to figure out exactly which database tables I need to interact with (he is the database man, after all.)

Adding Drinks

While most of the code has already been written for the Add Drink interface, the database handler which will send the information from the completed configuration form to the corresponding database tables. It will require interaction with more than one table since the liquid IDs and the drinks are stored separately, which means there will be some fun cross-checking to make sure the right liquid IDs are being stored for the drink when it is inserted.

I spent the last week reteaching myself PHP/MySQL, since I haven’t used PHP for a few years now. I did a lot of SQL at work over the summer, but it was just direct queries from C# programs. I’m going to be spending some time over the next week going through Derek’s code that he already has written and seeing if I can whip up a test page and get the database handler working.

Serial Communication in C

Direct Serial Communication

My primary task for this assignment was to research methods of communication with devices connected to the serial port using the language of C. The first method that I came across was a very direct method. It was coupled with a discussion of serial modems as well.

First, we would need to open a connection to the serial port, which was accomplished by using the following C code:

int port;
port = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY);

Then, there were various configurations that needed to be made. These included setting the baud rate to 9600, setting the character length to 8 characters, setting the stop bit length to 1, and disabling the parity bit. These were all contained in the “termios” structure in the C header “termios.h”.

//Pointer to the termios structure in termios.h
struct termios config;

//Gets the current configuration for the port
tcgetattr(port, &config);

//Set the baud rate to 9600
cfsetispeed(&config, B9600);
cfsetospeed(&config, B9600);

//Enable the receiver, set local mode
config.c_cflag |= (CLOCAL | CREAD);

//Only one stop bit
config.c_cflag &= ~CSTOP;

//No Parity
config.c_cflag &= ~PARENB;

//Setting the Character size to 8
config.c_cflag &= ~CSIZE;
config.c_cflag |= CS8;

//Set the new options for the port
tcsetattr(port, TCSANOW, &config);

Although this method seemed to make sense, we were unable to open the correct port. For some reason, the Linux machine would only open port 3, which is incorrect. We solved this using a much simpler method of communication.

System Calls in C

Using Linux, we were able to directly communicate with the serial port without using an interface program. We had a simple command that could be called from the command line. In the file “unistd.h”, there is a system() function that takes a string and runs it as a command on the Linux terminal. Using this method, we were able to bypass opening and configuring the port and simply make the system calls automatically. The C code is as follows:

system( "N02 > /dev/ttyS0") ;

This accomplishes our goal of communicating with the serial port using C. Using a simple loop, we tested this on the Linux box with a LED and two fans. I am a bit concerned about the timing of the calls and intend to research further the issues with the initial code we found. The system calls seem to slow down as execution time increases, and timing will be critical when we are measuring the liquids.