[harrison]

Hi Frederic,

That is a little worrying.
The temperature sensor shouldn’t perturbed by this.
What CAN cause this is if you run the reactor without the glass test tube (with liquid in it) fully touching the heat plate at the bottom. In that case there are few ways for the heat to be conducted out and the heat plate gets very hot -> Can melt the fan.
I would therefore be cautious to ensure you ALWAYS ensure you push it righ to the bottom (should be able to hear a little clink when glass touches metal).
Note some poeple have made custom lids in the past which broke this feature – i.e. the “arms” on the lid pushed up against the screws on the top side of the reactor before the glass reached the bottom. Consequently there was always an air gap there and these heating problems happened. So, make sure your lid isn’t causing it (e.g. by pushing it all the way down with the lid arms not aligned/on the screws and see that it goes down the same distance as when they are on the screws.
Hope this makes sense
Harrison

[harrison]

Hello,
Yes you can change the password to anything you want. It is just a basic debian linux OS so you can use standard commands to change password as you see fit.

Harrison

[harrison]

The naming is indeed a bit confusing now that I look at it.
sysData[M][‘OD0’][‘raw’] – raw data that comes from the sensor.
sysData[M][‘OD0’][‘target’] – the OD blank value
sysData[M][‘OD’][‘current’] – the calibrated value of OD

The confusing is the OD0 entry in the dict holds all the “raw” values e.g. the blank value and also the measurement in raw form. The ‘OD’ entry in the dict then has values for the OD in OD units (i.e. no raw values).

Best method to understand might be to put a bunch of print() statements in the code at the things you want to look at and see how the values change, this should make it easier to work backward.
Currently the system doesn’t record the RAW OD values (sysData[M][‘OD0’][‘raw’] ) in the database over time so you need to back-calculate these from your readings, and then shift the sysData[M][‘OD0’][‘target’] value, then calculate your new adjusted OD values.

[harrison]

Hello Kate,
It shoudl be OD0. You can look inside the code and see how this is done, what you need is lines 1572 to 1576: https://github.com/HarrisonSteel/ChiBio/blob/master/app.py
And yes I think it would be fine to just re-scale the final reading (i.e. as if there was a different OD set point) to join up the growth curves. Ultimately it has done the same raw measurement, just scaled it in a different way.

[harrison]

I think it SHOULDN’T make a difference in general since we schedule in the software for liquid removal to happen when the reactor is not stirring. But if you have made some edits to software or custom programmes maybe this is no longer the case so it would make a difference.

I don’t know what else in specific might help your application. I suppose if I were doing that I might try adding a fluorescent dye with whatever you are adding, so you can see the fluorescence spike when you add the chemical and then watch it go down as it is diluted out during growth. THis would give you a very precise measurement – much more so than trying to rely on the pump data to confirm growth rate.
If you ARE trying to get the growth rate estimated accurately (to back-calculate to dilution rate) I suggest using the Zigzag mode on the UI (Dither OD button) which lets the OD go in a “z” shape trace so you can more accuarely fit a growth rate model to it. It is discussed in the PLOS Biology paper about Chi.BIo if you wish to learn more.

[harrison]

Hello Kate,
The system solely regulates volume based on the length of that tube. It will pump out more than it needs to (i.e. above the inflow rate) such that most of the time it is pumping air. Thus in practice it should pump down to the level of the tail and then stop (as then it is pulling air). If you extend the tail it should go and regulate to a lower volume. I am not sure how it could end up with volume less than the bottom of the tail (extension) in general. One special case this could happen is if yuou are pumping out when the liquid is being stirred in which case the vortex means it has a non-flat surface so you might be able to pull it lower (i.e. the liquid rises up the sides so if your tail is there it could reduce it to below the liquid level with no stirring).

I think we designed them to be approximately 20ml volume with that tail, but I think we also adjusted it slightly over time so it is likely far from exact. In practice I think they do a pretty good job of keeping volume fixed (or close to it); if you need to change the fixed volume you change the tail.
Hope this answers your question?

[harrison]

Hello,

If the heating is working then there LEDs/stirring should also work since they are controlled by the same PWM chip – that is, if the reason was to do with the digital communications.
So, if you see that some of those parts are working but not others it seems to point to some deeper hardware issue / fault in the device. Perhaps the 6V power regulator on the board is broken. I am afraid it is a challenge that you would need to get from Labmaker. Try emailing their support@labmaker address.

[harrison]

Hello,

It is most likely one of the capacitors on the 6V power regulator oscillating at high frequency since there is a switching power regulator in there that runs at high frequency. It SHOULD be OK, we have had some that have done this for years without issue, though if it annoys you you could it by adding more solder to the capacitor to provide more of a mechanical fixing so it can’t vibrate at all.

[harrison]

Likely that liquid is the issue. There is also a moisture sensor track half way down into the device (you can see if it you look into the top). Try a cotton bud with alcohol to wipe that. It has a lower surface too, so if that doesn’t work you would have to take two sides off to get at the underside. We strongly recommend using rubber O-rings in the lids to prevent any possible overflow so this doesn’t happen, since it is super annyoing!

[harrison]

That is a strange one. Not sure how it could have been changed. Might it be possible to just re-flash the OS using a micro-SD card? That would work and not take very long – and re-set everything back to correct password. Alternatively perhaps email Labmaker, they may have been testing on on the control computer and forgot to re-set the password.

[harrison]

Hi Kate,

1) We can’t do this since the Beaglebone is actively sending digital commands via I2C to the reactors, hence there needs to be that intermediary there to format and control each reactor. This being said, people have worked on means to make the web interface more robust, in fact someone put an update on this on Github last week that might be worth checking out: https://github.com/HarrisonSteel/ChiBio/pull/12

2) We haven’t integrated this yet but it should be fairly straightforward. You could just put a hard-coded stop at a certain cycle count into the code. For example write a custom programme which takes as input a number of cycles (corresponding to number of minutes) you want the experiment to run for, then it does a logic check with each cycle of the main software loop and when it reaches the set number of measurement cycles it turns off experiment.

3) We have not tried adding this error logging, in practice it would be quite straightforward to just write to an external file; you could just re-define the print statements throughout to print_custom which writes into a file.

[harrison]

Hello,

You could try and fix it by adjusting the I2CCom function. Instead of it deliberately crashing things you could get it to set the offending reactor to not “present” (see how the reactors are scanned in scanDevices).

The reason they are currently deliberately crashing together is that there is a hardware safety system that is able to hard-disable all of the electronics/pumps in the whole system. This system is run from the main control computer (so it can’t easily be broken by moisture overflow etc), and sends out a signal to all reactors shutting them off when needed. The idea is that if one of the pumps was left on or something by the user this would then be a physical shut-off to prevent such issues. By doing what you suggest (preventing them from crashing together) you will open the possibility that if (for example) one of the pumps gets turned on and left on and overflows, it will now STAY ON (even if overflowing) because you would have disabled the hardware shutdown function.

So, proceed at your own peril 🙂

[harrison]

That is very strange. Looksl ike it is the white LED – I hope you weren’t using this one for fluorescence protein measurement?
The flashing behaviour seems very strange. I would have to say it may be a hardware defect if indeed it is not been re-coded in some way. It seems as if it may be stuck on and then the flashing arises from the power supply resetting to try to manage it. If you unplug it, leave it for some days to cool/dry in case there is some issue with moisture, and plug it in and try again that would be wise. Otherwise, may be best to contact Labmaker.

[harrison]

By light do you mean the main LED? I assume you have tried plugging that reactor into other ports, and re-started the computer? I assume you have not re-written the code in any way?
It is an unusual problem. I do not see how it would have broken if you are ONLY using it for fluorescent measurement.
If after resetting and updating software etc, it still flashes, it may be a manufacturing defect for which you would need to get in touch with Labmaker

[harrison]

Hello
Do you know if the liquid in the reactor overflowed at any time? This is the most likely reason. If I were you I would go through the troubleshooting guide in the manual, particularly w.r.t cleaning the top of the reactor moisture sensing tracks.

[Author]

Posts