[harrison]

When you have been doing these past checks – I assume you have got the pump board connected to the reactor too, right?

Beyond that, I am not sure at this point – it seems as if there may be a more serious fault in the hardware somewhere. It could be in either the control board or the reactor – with only one of each it is difficult to diagnose which is not working. Most likely there may just be a poorly soldered connection that is corrupting the electrical signals. The best approach would probably be to contact Labmaker and ask if they can replace it, they are usually very good at this.
Sorry to not be of more help!

[harrison]

Hi John,

A few points/questions
– How “fluorescent” are the “appropriately fluorescent” cells? Do you mean they are at some level that (for example) is visible to the eye? How much expression did you measure from them as a fraction of e.g. “the brightest GFP E.Coli you have ever seen”
– You shouldn’t need to manually switching on the excitation LEDs first. When you click “Measure FPs” it will turn them on itself (and then off again ater the measurement).
– For the GFP have you tried exciting with the lower (395nm) LED?

Generally the system works best when you are not taking tubes in and out of the reactors. There is some wiggle room around the tube and this can impact absolute values of readings. Furthermore, when you start/stop stirring and heat/cool the reactor these will all make some (small) impact on the measurement. Instead, what the system is really designed to do is to track a single test tube (and its contained culture) over time. This is what is done in Figure 5 of the PLoS Biology Paper! So, to best assess your setup I would either a) Test with an inducible construct, which you can maintain at a set OD and then induce and observe fluorescence production or b) Grow your GFP cells to a fixed OD and maintain them there for some time, then pipette into the reactor concentrated RFP cells (say, with the goal of the resultant culture being 50% GFP and 50% RFP) and see how this changes the GFP/RFP balance measured over time.

[harrison]

OK. I must say I still think that liquid problem is the most likely. When you look at the top of the reactor you can see there are two sets of silver tracks closely spaced. Some around the middle hole where the test tube goes, and others around the outside. Did you very vigorously wipe with alcohol both those tracks?
One alternative would be to take two of the sides (i.e. the left/right, not the sides that the cables connect to) and then unplug the top sensor track internally (it should be obvious how to do this given the cabling) and see if that fixes it.

[harrison]

Hi Tatsuya,
You said it worked well, but then at some point it started showing this error – is that correct?
Does this error come if one specific reactor is connected, or is it happening when any of your reactors are connected?

If it is only happening with one specific reactor I think the most likely cause could be that there is some liquid that has dried on the top part of the reactor, where there is a circuit that is used to sense moisture overflow. If you have any liquid on this (or if it spilled and dried partially) it can trigger the circuit. To fix this I would suggest using a cloth with some alcohol and carefully wiping down the silver tracks on the top of the devices to make sure nothing is there that could be triggering it.

[harrison]

I think whatever works, works! If you want to have a long cable in there and it seems happy with it then go with that.

[harrison]

Hi Avik,
I am not too surprised by this. The problem is that the digital communications (which use I2C protocol) are sensitive to the capacitance of the connection (i.e. wires) between the differnt components. The longer cable has more capacitance (there is more copper there – so it takes longer for the system to drive the digital signal high/low) and hence the digital signal has slower rise/fall time when the longer cable is used. When the cable is TOO long this rise time becomes too slow, meaning the chip on the pump is unable to “see” the digital signal properly – it gets corrupted.

I think in later versions of the device we will work out additional mechanisms for buffering this connection so that it is possible to reliably use longer cables on the pump side. But for now it seems sensitive to very long connections (though the software does make it a bit more robust in some cases).

[harrison]

It should really only be the PCB.
You say you don’t see ANY putty window. That is very strange – if the device crashes it should not be possible for it to close the putty window. The window should stay open at all times, even if you unplugged the control computer from your PC (Though it would throw up an error message in Putty).

If Putty is literally gone, are you sure your PC isn’t restarting or crashing somehow? For example, is it a Windows computer restarting itself to install updates (which happens painfully often if you leave them running overnight!)

If the device itself is crashign then the putty window should remain open and give error messages.

[harrison]

Potentialy yes. Though I am a little confused – if the control computer doesn’t work beyond one reactor at a time, how is it that you have multiple reactorS running such that they can stop working?

What does the PuTTY window say the next day when they stop working?

As to the cause: If the control computer is faulty then that is the most likely. Beyond that, the next most probable reason could be that you are getting liquid on the moisture sensing track at the top, which crashes the software. Are you running it in Turbidostat mode, or something else?

As an aside, if you are having any issues like this I would recommend updating to the V2.0 Software (see the Software page on this site) which makes it much more robust.

[harrison]

Thanks Shilan,
So based on what you said it seems that the reactors are fine – since all of them work if plugged into M0. However, you are saying that all of the other ports (i.e. M1-M7) are not working for unclear reasons. Is my understanding correct?

If that is the case I would say the most likely cause is a problem with the soldering of the Multiplexer chip, which is one of the circuits on the Control PCB (i.e. the PCB that has the M0-M7 ports on it).

Labmaker should be able to replace it for you if that is the case. Send them an email describing the problem and link them to this thread. They should be able to fix a replacement, they have been very good at this in the past!

[harrison]

Hi Avik,
Have you got the most recent software installed?
In particular, on this page: https://chi.bio/software/ there is a new Software V2.0 setup guide which should fix this.
The issue is probably that with your current software version it can take a while to recover from some communication issues. The updated software fixes this by updating the Linux Kernel to change how it handles communications errors.
Let me know how it goes!

[harrison]

OK, I assume these devices are all individually powered on with the wall plug?

Can you try and see what happens if you connect one reactor to M0 and then a second to M2? Or M0 and M3? etc.

What if you connect different reactors to M0? Do only some of the reactors work (while others don’t)?

I want to diagnose whether there is a problem with the control computer (i.e. one of the plugs is broken on it), or if there is a problem with one of the individual reactors.

[harrison]

Hi Shilan,
Can you explain what error you get? Perhaps share the log in PuTTy?
It should be that if you connect all the reactors up to the control computer via USB, and power all the reactors on, then you can access them all in the UI.

Harrison

[harrison]

Have emailed you 🙂

[harrison]

Yeah, i agree cabling isa pain and something I have thought about changing. At present there isn’t too much to be done since (even if data was wireless) we still need power transmitted between them.
One option I thought of was to have a “base” to which reactors/pumps attached. Thus, all power/communication would be routed through some table top-size structure and you just plug in the pumps/reactors to the top of this. But, would take a lot of design/manufacturing and potentially could create new failure modes (e.g. liquid spills could become more damaging…)

[harrison]

Hi Melo,

That error message would occur if you try to turn anything on when you have the GUI set to a device that is not at present plugged in and powered on.

Are you able to turn on/off LEDs and stirring for the reactor, but NOT pumps when they are plugged in to that reactor?

Which port in the control computer is your reactor connected to? Is this the same port you have selected in the M0-M7 buttons in the GUI? If the answer is not M0 for both try setting both to M0.

Do all your reactors have pumps plugged in to them?

[Author]

Posts