Author: Prof. Andresen

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.    

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.

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. 

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.

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.

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.

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. 

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. 

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.

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.