[harrison]

Hey! You can indeed reduce the voltage which is routed to them in the software. In the PumpModulation function they are generally set completely ON for a short time. For example:
setPWM(M,’Pumps’,sysItems[item][‘In1’],1.0*float(sysData[M][item][‘ON’]),0)
There is a “1.0*” element in there, which is saying to set the PWM voltage to its full value. You could reduce this somewhat to slow them down, though if you make it too low they won’t have sufficient power to overcome inertia and get spinning.

A more reliable/effective method might be to instead change the period of the PumpModulation function. Currently the pumps activate for a short time each minute; if you changed this to 10 minutes you could get lower dilution rates.

[harrison]

To be honest the easiest is probably to either a) connect through a different computer (i.e. a personal laptop) without the restrictions or b) connect through a different internet connection (i.e. phone hotspot, cafe wifi) if the network itself is limiting. You dont need the “network sharing” to be active when you are actually using the device, it is only required for initial setup. I know other people have simply taken the control computer home and done the installation in a different PC when their network in the lab has been troubling…

[harrison]

Interesting question! I am not aware of anyone that has directly measured dissolved oxygen at different ODs, but that would certainly be useful data to have (though highly dependent on strain/media).

The top of the reactor is by default open to the atmosphere, and due to the outflow pump’s regular action, the air in the head-space is replenished very regularly. Therefore, if there will be oxygen limitation it would have to arrive at the point of stirring it in to the media. Generally stirring is (if set to a high rate) about as vigorous as physically possible: With the right stir bar you can get a vortex that runs the length of the media column. If you think that would be fine I expect it would work well for your needs!
From my own experience, I have used fast-growing bacteria (E. coli, V. Natriegens) at continuous ODs of up >0.5 without seeing any significant slowdown…

[harrison]

OK, glad to hear it is resolved!

[harrison]

That works… to some extent. But 33.33% packet loss is pretty terrible, as is that >1s ping…

Perhaps poor connection is where your problem is coming from.

What happens if you ping google.com (just to check you have put the nameservers into the correct file!)?

The problems may then be somehow to do with the USB connection not working, maybe some of the install commands default to looking for that connection.

Could you try connecting it to the internet via another route? Perhaps you can connect your PC to the internet via a phone hotspot, or use a different PC altogether?

• This reply was modified 6 years, 2 months ago by harrison.

[harrison]

Hi Joe!

It looks to me as if the Beaglebone is in the first case not able to connect to the internet, and subsequent errors stem from that initial failure.

Are you sure that the Beaglebone is connected (through your computer) to the internet? What happens if you execute “ping 8.8.8.8” on the beaglebone?
It should start pinging google’s servers and give responses…

More information about sharing a PC’s internet connection with the Beaglebone is available here: http://ofitselfso.com/BeagleNotes/HowToConnectBeagleboneBlackToTheInternetViaUSB.php

[harrison]

As to the skirt; yes this could easily be added. Would just have to think about dimensions etc. However, first it might be good to test if the light getting into the chamber is actually a problem. This could be done by turning the lights on, putting some cells in, and then taking a spectrometer measurement at x512. If the readings are all close to zero (<50 or there abouts), then I'd say it is likely that the light leakage is not too significant.

If you look at the current version of the lid on the hardware page it has arms and an internal barrier to prevent any moisture escaping, this may help with getting it perfectly positioned each time for sampling.

We can easily make the holes in the top bigger (or add more holes) if that is what you need. Do you have any kind of 3D modelling software (there are some free packages!) available? If so I can export the model in any format that works for you so that you can edit it to suit your exact needs.

[harrison]

Hi Zoltan,

I expect the issue is coming from the way threading is implemented in Python. As far as my understanding goes; because we are running a main central loop, if you take “too long” to execute something in a function (within this loop) it can cause a crash.

The way to work around this is to run whatever your function is (which calls this measurement 20 times) in a thread (see the thread starting/executing lines which arise frequently in the code, for example in the PumpModulation function). If you do this then your function will not block the main loop from executing (e.g. the process that is updating data to the HTML UI), and thus it have the timeout problem.

Regarding how the averaging happens; each “MeasureOD” measurement is an average intensity over approx 0.7 seconds of laser. In the automated experimental procedure it measures four such periods and takes the average of these. However, if you just click “Measure” in the UI then only a single (0.7s long) OD measurement is performed.

[harrison]

The Baseband is a normalisation factor for FP measurement, as you said. See Note S15 in the supplementary of our BioRxiv here:
https://www.biorxiv.org/content/10.1101/796516v1.supplementary-material
which discusses why and how it is calculated.

In this “Clear” just refers to the “Clear” filter being used to take the Baseband measurement.

The Raw baseband number should change with time (or rather, with cell density), as more cells leads to more scattered light.

Depending on the biological system you are looking at, you may observe fluorescence go down at the start of an experiment (even at constant OD) if you have inoculated cells from stationary phase, as it will take some time for FPs that were previously expressed to be diluted out as they start growing.

[harrison]

You should be able to retrieve this as it is stored globally. For example, you could put the code that does the fluorescence measurement inside an if statement of the form

if(sysData[M][‘Experiment’][‘cycles’]%5==1):

This would mean that only each 5th cycle would it execute this measurement.

[harrison]

OK, I think that looks OK. It seems the issue may just be in initialisation.

Edit the function TurnEverythingOff:

Try putting the line:
setPWM(M,’Pumps’,sysItems[‘All’],0,0)

Inside an if statement like:
if int(M[1]) in [0, 1, 2 , 3]:

[harrison]

OK, maybe post your PumpModulation function (if that is the only thing you edited) and I will see

[harrison]

Interesting!

As a first measure I would recommend just reducing the intensity of whatever LEDs you are using to excite the fluorescent proteins. This will directly reduce the light dosage, and depending on your culture density potentially not make too much difference to the signal-to-noise of measurements.

If that is not enough, I would update the MeasureFP function such that each 10 cycles it takes a measurement, and the other 9/10 cycles it just just does nothing. That will allow the pump/OD control algorithms to keep running on a 1 minute cycle, whilst fluorescence excitation is less frequently. I think it is a good idea to keep the OD regulation on a 1 minute cycle because if you make the time between measurement/actuation changes much 10x longer it would be much less accurate…

[harrison]

Interesting. That error means those Reactors are still trying to send digital signals to their pump boards, despite the fact that the above code changes should (if they work perfectly) prevent that from ever happening. The error you are describing is therefore symptomatic of the changes I outlined not working as intended, and so I would recommend debugging that rather than disabling the connection check functionality. Disabling the connection check functionality might make it work to begin with, but may lead to problems down the line if signals arent actually going where they are meant to.

Does this error happen when you click on the pump controls in the software, or also when you start up the software and it goes through initialisation? Have you tried adding some print statements to “PumpModulation” to see when and where it is going wrong (i.e. when it is trying to control pumps on pump boards that aren’t connected).

[harrison]

Yes, to do this what I would do is write a “Custom Program”, for which there are templates already in the code. Make some counter that increments by 1 each experiment loop, and when it gets to 180 (60*3) change the OD set-point to 0.01. Then, have it stay in that state until the desired OD is reached (e.g. do a check that OD<0.01). Once this is achieved then put the OD setpoint to something large (e.g. 10) and re-start your 3 hour timer.

[Author]

Posts