Week Six: Lunes

I continued researching articles about the various parts of my experiment from ion competition to the different techniques used to investigate DNA compaction and aggregation including the ICP, tweezers, AFM, SAXS and different types of crystallography. This afternoon, the argon gas was replaced and the ICP began to warm up for the numerous runs that will hopefully take place the rest of the week. The first run will be with the 10 buffer solutions I just made at 20x dilution to decrease error bars. In the previous four runs at 20x, the concentration of sodium in the buffer solutions steadily decreased each run. Hopefully running ten more samples will even out the averaged concentration.

Week Five: Friday

Today we had our first journal club meeting of the lab. Abby and I had read the paper Stretching DNA by Marko and Siggia. The paper introduces the theory behind the worm like chain model of polymers and applies it to DNA, which happens to be a semi-flexible polymer. The main importance of the paper is a useful formula which gives an approximate interpolation for the WLC force versus extension. This is a go to formula for most force extension work when it comes to force spectroscopy experiments with DNA. The main importance of this article however, is the fact that this interpolation formula is only useful for low and high end force ranges. At ranges in the middle, this formula is no longer accurate.

In addition to reading, I looked at more of the code today, trying to get the images displayed from the camera to the screen saved to file. What I found is that there exists a fatal error in the existing version of the code due to an inappropriate file call. What will happen if the user attempts to save the images to file is that the application will crash, and the user will be forced to stop the program through the task manager. This is of course not very useful.

Finally, Professor Andresen continued to teach me the basics of machining, introducing me to the procedures in operating the mill. We used the mill to machine a piece that attaches our XY table to the posts we machined earlier. This is what the lab looks like as of now:

TGIF

Today I read and talked about reading, that is all.

Week Five: Thursday

Today I started by playing with the rotary motor. While it worked as expected following my port of the motor code to existing code that works for the other stepper motors, I had some difficulty figuring out what the exact unit was to make the motor do one full rotation. This actually took some time to calibrate. In the end, I had to find both how many steps the stepper motor took, and how many substeps the motor controller takes, multiply the two, and then for some reason multiply this number by three. This gives me how many sub steps are in one revolution for the motor. I then made this number be defaulted to 1, so that if the user entered in 1 for the unit the motor should turn, the motor will turn just 1 time. In order to ensure that the error in turning was minimized, I blew up the amount of turns the motor should take to 100. Thankfully, the motor stopped at the same spot it started at after 100 turns, indicating that the error is minimal.

By the afternoon, I had played with the code and camera interactions a little bit more. I noticed that there was a significant lag between what is displayed on the screen of the computer and movements that the camera actually sees. I believe, although I can't test this yet since I don't have the objective lens, that the portion of the code that generates the lookup table works as well.

The next steps will be to finish focusing the lens for the camera and to clean it. I also need to figure out how to attach the rotary motor, and the stepper motors to the XY table. There will probably be a significant amount of machining to do in the near future, which isn't ideal, but necessary.

Week Five: Thursday

Today, I fixed the error bars on my graphs because I forgot to add my standard errors in quadrature. I also talked to Prof. Andresen to decide what to run next week to shrink the error bars. This afternoon I have been reading about optical emission spectrometers and I read the information for our round table tonight about research ethics. 

Week Five: All the Graphs, all the Time

Today, I finished my PowerPoint and fixed all of the first run data of the cobalt- varied samples. I also read several journal articles including one about the Wormlike Chain Model that was very confusing. This afternoon, I showed my PowerPoint to Prof. Andresen and he noticed that the amount of sodium in the samples was significantly different between the 20x and 100x dilution. To try and correct this, I redid my analysis using all three wavelengths the ICP measured, averaged them all for each sample and added this to the figure to result in the figure below.

As you can see, the addition of the other wavelengths just shifted the data down but did not bring them closer to each other.

Week Five: Mike Mike Mike Mike Mike! Guess what day it is!

Today I read up more on the worm like chain (WLC) model and its applications to a semi-flexible polymer, which DNA is. The posts that I spray painted yesterday have fully dried and are ready to use. The power supply for the camera arrived, and we managed to get the camera safely working with it. By the afternoon, we placed the focusing lens in place, and although it isn't focused at the right distance, we managed to get a pretty nice picture.

In the process however, we dirtied the focusing lens a good bit, and it will have to be cleaned. The next step after cleaning will be to get it focused at just the right distance.

Week Five: Tuesday

Today, I finished (relatively, I still need the motors to test it for sure) porting the code for the remaining motors to work off of the code for our motor control board. This is pretty good, because it means that the code is almost, if not entirely, full operational.

Also, I spray painted some posts.

Week Five: Tuesday

Today, all day, I worked on completing the analysis of the varied sodium DNA samples and create a PowerPoint and I am almost finished!!!

Week Five: Monday

Today:

All four posts have been machined and are ready to be mounted. Also, the framegrabber for the camera arrived today. We placed this in the computer, installed the software, and set about trying to get the camera to work. Unfortunately, we do not yet have a power supply for the camera, so we rigged one up momentarily.

Attached camera with rigged power supply.

After a little hassle, we managed to get the camera working to show changes in light. Nothing was in focus of course because the focusing lens is not yet set in the lens tube. As of today, all of the files needed for the code to work are present, so all of the code is technically working, just not for us. My next step is to update the code for the remaining motors to be run off of our motor control board. After this is finished, all of the code should be working for us.

Week Five: Monday

Today, I recreated the sodium-varied samples at 20x dilution and ran them through the ICP twice. Mistake time: I tried to open up chrome once I began the second run to send myself the first set of data and apparently that is a horrible idea because the computer freaked out and shut down :( 
Once I got the computer to be alive again, I ran the data for the second time. This afternoon, I started work on the data from the four runs of the samples. Tomorrow I will fix the graphs, clean up the excel file and create a PowerPoint to share with our collaborators including full explanations of the method, error propagation and detailed explanation of each graph.

Week Four: Wednesday

Today with the help of Dr. Good we managed to get the LED collimated. Although the setup is slightly different now in its attachment to the kinematic mount, it still functions the same.

The setup with the mounted LED in place. 

The Beam of Reasonable Collimation

I continued my work with porting the code for all of the stepper motors. I also added a table which can save values to screen of the stepper motor coordinates.

Lastly, Professor Andresen managed to machine one more post bringing our total to two.

Week Four: Tuesday

I began my day by trying to figure out why the .flx files generate errors, even when they are being used for the same motor control board as in the code. What I found was that a separate motor control board was being used for the other stepper motors. So, my next task which I already started today successfully is to port the code for these stepper motors for use with our motor control board. To do this, I took the code that already works for our stepper motors that will move the xy table, and began to allow it to move the other stepper motors. I managed to successfully do this with the stepper motor for the objective. 

The current driver and power supply for the LED arrived today, allowing us to play with the LED for a little bit of fun. Here's the mess it's in now:

The LED with the attached current driver. Trust me, it works.

Towards the end of the day Professor Andresen began to show me how to use the different machines in the workshop. We managed to machine one of the four posts that will hold up the rest of the tweezers set up. So now, the lab looks like this:

The post that Professor Andresen machined. 1/4" 20 tapped holes on both ends.

How the floating table looks now. It's all coming together. 

 

Week Four: Tuesday

I ran the six calibration solutions on the ICP and got reasonable results so I continued to run the calibrations with the first sample set I made yesterday. This data should follow a similar trend-line to the first sample run because the only difference was the concentration of the samples. However, the buffer solution had a much higher sodium concentration, by a factor of ten, causing the relative sodium in each sample to be much lower as seen in the graph below. Tomorrow, I hope to find the cause of this inconsistency and possibly make new samples at the same dilution. 

Figure shows the difference in the sodium concentration for each of the samples and the common buffer used for all samples. Because the measured level of sodium in the buffer was so high, the first few samples to show a concentration less than zero.

Week Four: Monday

The rails came in yesterday, allowing us to finalize our positioning of objects on the bread board to estimate the size of items that we will machine. For the LED, we will be placing an order for a current driver and power supply.

In terms of the code, I found that the cursor keys work for controlling the stepper motor. The up/down keys correspond to the x stepper motor, while the y corresponds to the left/right keys. These work through relative moves, but can be switched to absolute moves. All of this was done in the top level of the program. 

At the top level of the code, I added a little bit of code to show the users what coordinates they were at as they moved the stepper motors. We can add on to this code at any time in order to display more useful motor coordinates to the user. 

Week Four: Monday

Today, after discussing the goals of the week as a group, I began figuring out how to structure the next part of the experiment. I decided, with much help from Prof. Andresen, to run the first set of samples that has varying sodium concentrations at a 20x dilution. I created six new calibration solutions with different levels of sodium, cobalt and phosphorus than the last calibration set. I plan on running the new calibration set this afternoon and I will begin running the DNA samples tomorrow.

Week 3: THURSDAY

Today, we figured out how to connect the kinematic mount to the posts. Turns out, those posts have quite an ingenious design. 

More importantly, however, we managed to get the .flx files somewhat working. They exist now, although they run with errors. It doesn't seem to affect the final read out of the code however. This is an important development, as it opens up more of the code to work on. 

The most important thing that was accomplished today was the figuring out the units of one rotation of the motor in SimpleMove.vi. This is good, because just a little later I figured out how to modify the number of units in one rotation. This is exciting because it means we can modify these units to whatever we want.

Week 3: WEDNESDAY; the build begins...

Today I began setting up the different optical components that just recently arrived for a mock up as to how we might want to build things. As of right now, I have the lens tube holder and mirror kinematic holder set up in a decent fashion. 

Side view of the lens tube setup with the kinematic mount
for the mirror. The whole setup can be raised or lowered as
needed.

 One of the first problems that I ran into with the optomechanical components was with our larger kinematic mount. This larger mount will be used to hold the LED with the collimator attached to it.

The problem that I found was with the screws provided for the kinematic mount. The problem is that the screw size is too small for our optical posts; the stainless steel rods you see in the pictures to the left. To complicate things, it turns out that the large kinematic mount is not threaded, so the optical posts can't be screwed into the kinematic mounts either.

Ideally, this should be enough space for the rest of the
tweezers setup to go above the 45 degree mirror.

Ideally, you could just drill a hole into the kinematic mount to run a screw through it and into the stainless steel post. The thread count for the stainless steel post is unknown however, which will make it difficult to find something to attach it with. I believe that Thorlabs does this with their threading in order to make it so that you have to purchase their products.

View of the kinematic mount. You can see inside the mounting holes that the hole size changes.

Alternative view of the kinematic mount. There is no threading inside of the holes.

Another issue that I ran into today was with the CCD camera. Unfortunately, we didn't order a cable for the camera yet. This needs to be done. The problem is, we might end up needing a CameraLink cable, and a frame grabber control board in order to capture images from the camera. This could be costly.

Finally, I began to look at the high-powered LED that we received from Thorlabs. According to the included specs sheet, we'll need a power supply that can deliver current at a Forward Voltage of 2.2 V. This is quite strange. We also probably don't have anything that can provide that. 

Closeup of the LED

The nifty case that the LED came in with the specs sheet. High-tier.

Thankfully, the strangeness of these problems that I'm dealing with was mitigated by some quality Lab Swag.

Ithaca Waterfalls!

After four days of running samples for 16 hours each day, we finished our BioSAXS experiments. But before we left, we went to see several of the amazing waterfalls in Ithaca. 

Path leading up to the largest falls. Unfortunately the path was closed further up because of construction, so we had to circle back and follow another path to the waterfalls. 

WATERFALL!!

Prof. Andresen attempting to take a panoramic view of the falls. 

Week Three: TUESDAY

I started the day off by figuring out once again what the initial motor position would be if I connected everything up to the computer and ran the motor control code. Once again, I found that it was initialized to -16,777,216. This number must have some meaning, but I am not sure what.

Following this, I attempted to figure out how to do a little programming challenge to see if we could make the motors do what we want them to in the long run, or figure out if the existing code we have can accomplish this. The task is as follows:
1) Tell the motor to rotate 3.5 turns and stop.
2) Move back 1.2 turns and stop.
3) Report the position as 2.3
4) Save this position so that when the program is closed and reopened it still recognizes that the motor is at 2.3, ceteris paribus.

As it turns out, this is a bit more difficult than it would seem. The reason for new positions in the motor becoming zero each time the control board is unplugged as opposed to the program being closed and reopened is because the motor position is stored in the control board's memory, not the program's.

So how difficult is it to create a vi to do what was described above? Not very, but you need to have the right tools. Tasks 1) through 3) can easily be accomplished with the base code that I've been working with, but the unit "turns" would have to be figured out empirically. This is not optimal, so I set out to figure out what the units were, and more importantly, how this motor code works in the scheme of the whole program.

It turns out that the units, speed, and voltage of the motors can all be calibrated in a nice little calib.ini file. This file is then called by a CalibConstants.vi which appears everywhere in the overall tweezers.vi code structure. This CalibConstants.vi should be able to figure out the units and normalize instructions from turns to what the base code I was using earlier uses for units.

CalibConstants.vi is unfortunately not run-able because there are two important files missing: Reset Position.flx and Read Position.flx. The observant reader would note that these file endings are different for every other LabVIEW file that I've discussed so far. That's because, (after doing a little bit of research) these files are related to the NI-Motion set of *stuff*. .flx are Flex Motion files, used by the NI-Motion driver. These .flx files appear several times throughout the tweezers.vi and are most of the missing files in all of the code.

With the inclusion of these two .flx files, CalibConstants.vi should be run-able, and by extension, simplemove.vi, which is the overhead code for the base motor code I've been using, which should mean that the programming task I outlined above is entirely executable by the existing code we have. Also, since much of the tweezers.vi code has CalibConstants.vi throughout it, more of that code will be run-able too. This is exciting since our camera and other optics equipment just arrived today.

So what's the bottom line? Either we rewrite the code or get this NI-Motion driver which should contain the .flx libraries. I did manage to comment out sections of the CalibConstants.vi and SimpleMove.vi that referred to the .flx files we don't have. I managed to get both running, but since I commented critical sections out, the code was stuck in an infinite while loop and I was unable to proceed further.

CHESS: Second half of BioSAXS

Yesterday, after looking over the data from overnight, Prof. Andresen and I began running more samples. Instead of varying the salt concentration (the amount of K in each sample for dilutions of 1x, 2x, and 4x) we began changing the contents of each sample and diluting that. The samples were separated into the categories of blue and red and each had 6 types of samples. The first three were tetramers and the last three were dodecamers. The first in each series was simply the nucleosomes in solution of TEK10, the second included globular H1 protein, and the last included globular H5 protein. For these samples, we did not use any TEK but instead had a buffer of 1mM Mg. This could change much about how the nucleosomes interact because of the change from a +1 ion to a +2 ion in the solution. Because tetramers and dodecamers are more prone to aggregation, we began cleaning the sample cell after each sample much more thoroughly. We washed the buffer solution through the cell twice after running the sample and then washed the water and alcohol through twice as much than on Saturday. On Sunday, we were able to run all of the Red series, a trimer and a large portion of the Blue series. Our other group finished that series and began to run their own samples of proteins. 
Today, we ran the gold samples that were given to us by Prof. Thompson for his experiments. Because the composition of the gold samples was so different than the nucleosome arrays, our sample cell was wrecked and Prof. Andresen had to insert a new cell and reconfigure the alignment. While he was doing this, I attended a thesis defense on the ion interactions with single and double stranded DNA measured using solution x-ray scattering.  This talk included several biophysical techniques that we discussed in physics 246 this past spring such as SAXS (obviously), spFRET and molecular dynamics. The presenter also used data obtained from Gettysburg's ICP-AES that Prof. Andresen ran. To finish off the day, we are going to run the R series with a 2x dilution for the different levels of TEK (50, 100 and 200) including double the buffer between samples (the TEK of the previous and the TEK of the next). Hopefully we will get through most of the series before we switch off at midnight.

Week Three: MONDAY

Today I accomplished a couple of things; reading and code-documenting, not necessarily in that order. I generally like to break up the day as a mix between reading and viewing code, so that neither become to monotonous.

I finished reading Kruithof's thesis, Magnetic Tweezers Based Force Spectroscopy Studies of the Structure and Dynamics of Nucleosomes and Chromatin (2009), which was quite a read; 9 out of 10, would recommend. I also began reading a thesis by Fan-Tso Chien, Chromatin Dynamics Resolved with Force Spectroscopy (2011), which I plan to finish tomorrow. In general these readings have strengthened my understanding of force spectroscopy. More so, it highlighted more things that I should learn about. I've slowly been creating a list of things to delve more deeply into, in no particular order. Since this project is on magnetic tweezers, it would be helpful to further my knowledge on microbiology, so I've included topics such as DNA, chromatin, and the worm-like-chain model, mostly with respect to their use in force spectroscopy experiments, and what questions we can resolve about chromatin through force spectroscopy. I've also included more technical things, some which I know a little about already, and others which I feel I should know but unfortunately don't since I've never had a class in Bayesian statistics. These are, Brownian motion, Monte-Carlo experiments, and Markov analysis w/ respect to a Hidden Markov model.

Back to the mechanical side of things, I made a couple of important breakthroughs, but I'm not entirely sure of their implications. I analyzed how the motor control board and our code for the control board works more thoroughly. When I initially ran the code, I found that the setup thought it was at initial coordinate setting of -16,777,216 (units, still need to figure out what the units are). Not remembering what I had left the motor at yesterday, I assumed this might have been just where I left off, although it was highly unlikely. I told the code to move the motor to a position of 0. After this, I proceeded to unplug the motor control board from power and the computer. I closed out all of the code as well. Reconnecting everything, the position remains at 0. I then told the code to move to 100,000 and verify it was at 100,000. Closing and unplugging everything only to reconnect later, I found the position was now 0. I noticed that after a move to 100,000, the motor was at roughly the same position as 0. To verify that 100,000 wasn't simply a "rotational multiple of 0" (like on the unit circle, 0, 2pi, so forth), I made a move to 50,000, believing that this should be somewhere in half, and give an initialized number. This is not the case however. This will also read 0 on startup, as well as any non-multiple of these. What this means is, the control board does not hold memory after power down. I also noticed that the absolute moves as used in the code, 25,000, 50,000, 100,000, and 700,000 are not multiples of one another, as they do not remain at the same position. What this also means is that there will be a problem with initialization for absolute moves. Any position the motor is in at shutoff will become the new 0 at startup, so absolute moves no longer are absolute. I also have no idea why the code believed the motor was at -16,777,216 at startup.

I found what I thought could be possible Piezo-related subvi's. All of them are contained within the SimpleMove vi, or within the Piezo-related subvi's as additional Piezo sub vi's. This is good, as it means it should be relatively easy to remove the part of the case structure in SimpleMove that contains the code for the Piezo with little repercussions.

Finally, I began exploring the code above SimpleMove. I found that SimpleMove has instances in InitializeLUT, InitTweezers, MoveTrajectory, the main instance of the code, and UseParFile. I began my documentation of MoveTrajectory, although it is quite a complicated bit of code. For tomorrow, I plan to continue to document these vi's. Also, out of curiosity, I will find what the code believes to be the initial position of the motor.    

BioSAXS Controls Video

Video of System Running: The first computer screen shows a spreadsheet of all the runs with information about each run; what it is, how many seconds its exposed for each image, how many images, and the time that the run began. The second computer screen controls the spec to make each run start and to vary the time of the run. This screen also controls the sample cell to tell it to move the sample left or right, to oscillate and at what step size it should take. The TV screen above both shows what the camera sees so that the oscillations can be regulated and we can be sure that no aggregates or bubbles are in the cell. Above all of this is the sensors for I2, I3, GDoor and the diode. The diode does not give us much information. When I2 and I3 are large, that signifies the strength of the X-rays in the beam.

Week Two: BioSAXS

I accompanied Professor Andresen to the Cornell High Energy Synchrotron Source (CHESS) to run SAXS experiments on various nucleosome arrays. Friday and a large part of Saturday, we modified the experimental setup. We elongated the tubing in the hutch, inserted a beam stop, switched the detector from a 100K pixel to a 200K and began with an X-ray of 200 by 200 micrometers. 

Inside the hutch, overall view of the setup. The long tube farthest to the left was exchanged with the tube on the wall behind to lower the q value. The X-ray beam enters at the far right.

Further to the right the 200K detector can be seen which is the box on the end of the tubing. Right before the detector is a glass plate that the beam stop is placed on. **Fun Fact: Professor Andresen, as a graduate student, painted the maroon square behind the detector.

Then a camera was set up to look at the sample inside the beam mostly to ensure that the sample was centered at the beam and to look for possible air bubbles or aggregates in the sample. At this point the guards and elements of the tube were varied to get the best beam signal throughout the tube with minimal scattering due to the sides of the tubes. Silver behenate was used as a calibration of the beam to find rough values for q to see what range we were working with. All of this was changed in the hopes of lowing the q value, which is the momentum transfer or scattering vector, to a low of 0.004. After the physical setup was chosen and implemented, all the different elements had to be synced with the computer outside the hutch (the hutch is the room where the X-rays are present during experiments).This was what took the most time because so many variables were changed since the last time the G1 hutch was operating. 

Operating system outside of hutch including the real time values of I3 and I2 which give an idea of the strength of the X-rays inside the hutch, the camera monitor that is looking at the sample, and all of the programs that control the beam, guards, sample etc. 

In the image above, Professor Andresen was closing the hutch door and turning the key. This is where the key is placed and the X-rays are turned on. After searching the hutch (pressing two buttons on either side of the hutch and ensuring no one is inside) the door is shut, key is taken and placed in the Station G1 control and the black buttons are pressed on the top right corner of the control box. 

 The element that gave the most trouble was the beam stop which was not in the correct place for running initally and also had different components that continually got in the way of the X-ray beam. This caused the I3 signal to be very low (~16) until it was fixed and showed a signal of ~200. After many hours of centering the beam and correcting the scattering from the sides, we began taking data from our samples. 
We began with the Trimer A which is three nucleosomes together because it is the smallest set of nucleosomes we will look at this weekend. First, distilled water is sent through the sample cell (about 3 times), then ethanol is sent through (about 2 times). At this point the sample cell is mostly clean so we turned on the air to dry the area for about 30 seconds minimum. After all that, we inserted a buffer, closed the hutch, and ran the buffer. This gives us a base line to subtract out any systematic problems against the actual samples. 

View of where the sample is inserted. Between the two plates, a small clear sample cell can be seen. This is where the samples, buffers, water and alcohol is placed and also where the air comes out. The camera is on the opposite side of the beam.  

We ran everything for 5 seconds with 20 images with a ten second break and then once more. After the buffer, we cleaned the sample cell with water, alcohol, and air once more and put the sample inside. We repeated the set up of 5 seconds, 20 images twice for the sample. This procedure was followed for all of Trimer A which included three dilutions (1x, 2x, 4x) for buffers of 10, 50, 100 and 200. 
Today, we are running samples of higher nucleosome arrays. Tetramers and dodecamers (4 and 12 nucleosome arrays respectfully) are much larger structures so the set up had to be modified so that the scattering angles could be measured. This is because larger objects give smaller scattering angles and smaller objects give larger scattering angles. We had some issues with a peak coming off in the z direction from the beam but by changing the guards and the beam stop, this was corrected. Because we are working with the other samples, we lower the beam size to 100 micrometers in the z direction which also lower our intensity so we will be taking longer time intervals when we run. 

Week 2: Friday

Today I worked primarily on experimenting with the motor control VI and documenting the SimpleMove vi and its sub vi's. I also did a little bit of reading on magnetic tweezers. But first, I'd like to share with you the current setup we have for the lab.

We took the floater table from the nuclear lab and moved it into the middle of the room. Also featured is the new computer.

I started the day by messing around with the motor control board, the motor, and the VI that's supposed to run it. I improved over my messing with it from the other day by managing to successfully make it rotate in the opposite direction today. Although I initially thought that the code written for the control board would be bug free, I discovered later in the day that there would be certain cases in which the code would break. For example, starting from point zero, it is possible to move the motor in the wrong direction into negative absolute points. This could be bad for the MT setup, as it could result in the motor moving when it cannot physically move due to a barrier. I also found that when just launching the VI, the code does not always recognize what is zero for the motor.

The motor setup: A control board straight out of the box (or in it), a motor, and a breadboard. A USB cable leads to the computer. A power supply runs off of the table to the control board.

A picture of the control board that we are using. It is a Trinamic TMCM 6110 motion control board.

I also ran into issues today with the code that calls the move controls for the motor. Yesterday I attempted to see if deleting parts of that code that don't pertain to the motor control would allow for it to run even though we don't have the other parts that the parts of the code that I deleted refer to. Unfortunately, today I found that it still will not be able to run, as the unit calibration and timing sub vi's will not run due to missing files. It's possible that if this overhead code that calls the motor control code fixes the problems with zeroing I mentioned earlier, but I'm not 100% sure.

Week 2: Thursday

Today I reviewed the new LabVIEW code sent to us. We finally have our new computer up and running in the lab installed with LabVIEW. I managed to make the motor control board operate the motors through the supplier's LabVIEW code just as Dr. Andresen had. However, I found that the existing MT LabVIEW code could also run the motors. While I was quite pleased with this, I found it to be somewhat buggy, and had no way to make the motor move in the opposite direction, which is disappointing. I believe it to be a problem with some uninitialized values, which might be initialized or transformed in some other VI in the codeset.

For the rest of the day, I began looking at the SimpleMove.vi, the part of the code that basically tells the motor control to move. It also does several other things, however, it's not functional right now, since there are several pieces of the code missing. With our optics in order and just waiting to be ordered, it is now my job to figure out how to get this section of the code running again, which should take a couple of days.

Week 2 Wednesday

For the most part this week, I've been figuring out the optical system and components that we are going to include in the magnetic tweezers setup. It's been problematic so far, because we're having difficulty with the parts list from one of Professor Andresen's friends. Complicating the situation is the fact that they're in Singapore, so any communication is delayed significantly.

One of the first problems we have is determining how to focus the collimated light coming out of the objective. This light has to be focused in order to be stored on our CCD. We have a choice of either a f=100 or f=180mm lens. However, we're unsure if (and what would happen) if we include both lenses in the setup at the same time. Secondly, we need to figure out what type of LED we want as our light source. We're leaning to using Thorlabs as our main supplier for all of our opto-mechanical and optics equipment for ease. So, for the most part of this afternoon, I've been chatting with a tech-adviser from Thorlabs for help with selecting the LED and the appropriate opto-mechanical components. Right now we're leaning towards a red (625nm) LED w/ an output power of 1000mA. To collimate the LED, we'll be constructing our own collimator out of different Thorlab stuff. We'll be using an aspherical lens with AR coating in some appropriate housing to collimate the light from the LED. This housing will attach to the LED itself. Of course, the main problem now is making sure that the whole list of everything we need is complete, and get everything ordered.

Week Two: Mike Mike Mike Mike! Guess what day it is!?!

This morning, I reanalyzed the cobalt- only samples on the ICP, exported the raw data, and added the information to the graphs I made yesterday. The fraction of charge neutralized by cobalt was within the standard deviation from the first run but the individual concentrations of cobalt and phosphorus were significantly lower than yesterday. Although the second run had much lower concentrations, the trendline for both ions traced the same as the first run. This afternoon, I have been catching up on my reading about DNA, nucleosomes, SAXS and studies related to my experiment. 

Week Two: Tuesday

I recreated the graphs from yesterday of the fraction of charge neutralized by Cobalt and Sodium among others using data from both of the runs. Below are the separate graphs of the charge neutralized by the ions. 

I also began to run the other samples given to us with no sodium present in large or varying quantities and only cobalt was varied. Tomorrow I will run the samples again to verify the initial results. 

Week Two: Monday

I analyzed the data collected from my final run last week to determine the quality of the run based on the knowledge I have about how the concentrations of cobalt, sodium and phosphorus change with increasing sodium levels. Using the fact that each of the samples increased in sodium from 0 mM to 80 mM, I created Excel graphs to show the relationships between each of the ions and also how the system competitively behaves. I also determined the relative proportions of cobalt and sodium in solution and created a graph to show their congruence relative to the amount of phosphorus detected. This is shown in the graph below. 

The error bars are rather large so I will be adding a second run of the same samples to clean the graphs up. Today, Steve and I also had a group meeting with Prof. Andresen to discuss the current state of our experiments, mostly so each of us understand what the other is doing, and also discussed what we will be doing for the next two weeks. 

Settimana Due Giorno Uno

Oggi io ho letto molti documenti per il mio lavoro. In the morning I read up on optics, particularly relating to ccd cameras and camera focusing in general. A problem that we've encountered is that, while the focus from the back end of the objective in the setup may be infinity, we still need a way to resolve the picture so that it is in focus for the ccd camera. We need a lens, and a couple of other optics to get the setup to work properly.
I also began to document and review parts lists for other magnetic tweezers setups. I will begin comparing these groups' parts lists to our own, and figure out which are necessary.
Around 3.30, the motor control board and the motor itself arrived. I began to play with the motor control board by connecting it to my laptop via usb. A green light came on flashing on the board, which is a good sign. After a little hassle, I believe that I have my laptop using the right driver for the control board. Hopefully my pc will now recognize the device.