[harrison]

Hi Katja
This error is consistent with either a hardware fault, OR there getting liquid on the moiusture sensor. In fact the later is much more likely since as you said it ran for 3 days first before failing randomly.

Did you see any liquid on it? Did you see even any dried liquid/residue around the top of the device? What kind of lid are you using? (is it 3D printed, or a rubber washer one?)

I would have to say this is by far the most likely issue if it is randomly crashing with that error during an experiment.

As to the OD jump -can you send me the data file (csv) so I can look at this? If it is just for ONE time point in the experiment it may be just an error in digital transmission of data somewhere.

[harrison]

Yeah, good idea! I would appreciate if you can send me a picture of your setup with the peristaltic pumps once it arrives. Then yes, we could make a smaller footprint pump board that then anyone can use as you suggest.

Harrison

[harrison]

Dear Avik,

Thanks for reaching out. That sounds very interesting – so you directly connected it to the power output of the comms board and all seems fine?
If that is the case I see no reason why you cannot continue doing so. Technically that pump seems to say the minimum voltage is ~11 whereas the pump board only supplies six – however – generally if it is working with a lower voltage it will just move more slowly.

Ordering the PCB boards from PCBway would be fine. Some of the chips are a bit fiddly to solder but I have actually put a guide for this in the hardware self-setup document.

So, I’d say if it works go for it!

[harrison]

Hello,

The voltage reg on the pump board is only outputing 3.3V for the digital components. It is NOT regulating a 6V input for the pumps. That 6V comes in raw from the cable.

That said, making a 6V supply is not outrageously difficult so I imagine what you propose can work! Maybe it would get by with 5V input – the limiting factor is whether that is enough to get the pumps spinning (IMO it should be).

[harrison]

Hi Eric,
Interesting idea! In principle it could work, but I must say, I am not sure this approach will be easier than messing with app.py. Probably you WOULD have an easier time sitting down and understanding what app.py is up to with the pump control, then building upon that.
Nevertheless, the inputs to the pump board are:
-6V
-unused
-GND
-SCL
-SDA

So the main difference with what you wrote is the 6V input. This is the power used to actually run the pumps, and needs to be able to supply ~0.5A minimum since they generally draw quite a large current when they start turning. Thus, you would need to make whatever hardware system you propose to develop supply this current or it would not be able to run them at all. Currently there is a regulator inside the Chi.Bio reactor doing this…

I hope this helps – as I said IMO you would be better doing it using the existing hardware infrastructure and making your changes in code. Once you do understand how it works, it is not so difficult to make changes!

Best
Harrison

[harrison]

Hi Lachlan,

1. The issue is likely that the pump is making a very poor seal on the tube. To fix this there are instructions in the manual for how to put some extra tape inside the pump head to make it “tighter”. Have you done this? Basically the issue arises from poor manufacturing tolerances on the pump head, so we have been using this to improve them where needed.

2. I am surprised the silver tracks did not turn it off. Generally people find these are TOO sensitive to moisture, rather than missing it entirely. Was the liquid leaking directly onto them, or somehow avoiding it? One possibility is there might be a wiring fault on that reactor. To test such a thing I would recommend starting a blank experiment (e.g. just put a test tube with some water in), press “Start” on the interface, then DELIBERATELY short the tracks with a piece of metal or other conductive item to check that indeed it crashes the software (can take up to 30 seconds or something for it to trigger).

[harrison]

Hi Katja,

No, there is no reason it should stop in particular. The software is designed to run indefinitely and we have done experiments of a month or more.
Do you know what error was shown in the PuTTY window when you saw it had stopped? In order to diagnose what went wrong we would need to know what message it displayed.
If I were to guess, the most common failure mode is some liquid (or condensation) reaching the moisture sensing tracks on the top of the device and causing it to cut out (since it would then think the liquid might have overflowed).

Best
Harrison

[harrison]

Hello,
Potentially you could, but it would require you to create a new Cape PCB (i.e. to fit the Raspberry Pi rather than Beaglebone Black) and also adjust software to fit the new operating system.

It is unclear to me why you wish to do this as it would not save any space – just replace one microcontroller with another.

If you want to run the existing Beaglebone Black _without_ connecting it directly to a PC then this is possible – you just have to set your network up to connected to it via ethernet. I believe others have done this in the past but I have not as we just connect a bunch of them to PC via long USB cables 🙂

[harrison]

Great, let me know.
Also, by OS I mean the underlying Beaglebone operating system (i.e. Debian Linux), not just the Chi.Bio software on Github. The underlying OS is the one causing these faults, we have been trying to patch it…

[harrison]

Hello, what operating system version are you using? Has it been updated to the latest variant from the Chi.Bio website?
I have observed an error somewhat similar to this in the past but updated the OS in order to try to cover it off. If you are still seeing it that is worrying as it means something might still be amiss…

Harrison

[harrison]

I see what you mean, the last line was meant to say “Then, OUTSIDE that If statement, have another check which does something like (if ODNow is less than target ODTarget then turn off RegulateOD).”

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

[harrison]

OK – but I think the two goals (volume change vs OD change) can be made to go hand in hand.
That is, if you have a calibrated OD then in theory OD is linearly proportional to cells per unit volume.
Thus if I halve my OD (from 1.0 to 0.5 say) then that is the same as taking 20ml of cells, reducing volume to 10ml, then adding in fresh media back to 20ml – right?

I think confusion might have come from the use of the sysData[M][‘Volume’][‘target’] in the system. This parameter does not “control” anything. The volume in the software is only there to help the OD regulation algorithm’s accuracy. So setting a Goal Volume there would not solve it.
What I think you need to do is as in my above post with the steps laid out. You have the right time check in there (i.e. the timept % timelength==2) to start the process, but what you should instead do is inside that if statement set OD target = 0.5*ODNow (for example), then turn on Regulate OD.
Then, OUTSIDE that If statement, have another check which does something like (if ODNow

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

[harrison]

The difference between that proposal and what I am suggesting is that my suggestion is pumping out/in at the same time, while keeping the volume constant.

In practice what you are suggesting (reduce volume then pump back in fresh media) will yield the same result as setting a specific OD reduction target (i.e. reduce OD by half) – is this not correct?

[harrison]

Hi Sina,
I must say the description confused me; would it be possible for you to write down precise steps you want to achieve point-by-point?

There is some ambiguity in what is meant by “volume reduction” in my mind. In particular, as the Chi.Bio is set up by default the “outlet” tube is only some way down into the reactor. It is set at a fixed height so that you can never reduce the volume in the reactor below the normal amount (20ml or so). That said, you can dilute it by adding fresh media and taking out a mixture of media + cells, but during that process the total volume remains (approximately) constant.

If you really want to reduce the volume this is possible (but would require changing the height of the tube and would not be very effective), but it is somewhat unclear to me what you would gain based on your description.

In my subsequent messages you referenced I suggested another approach which is to use the OD Regulation function already in the system. You could on a X hour loop do something like:
1. Measure current OD (say, it is equal to 1.0)
2. Turn on OD regulation with a target of 0.5 (i.e. half the measured value).
3. Wait until OD has reached 0.5 (probably will take 5 minutes, though pumps are only on a fraction of the time). At this point half the cells + media have been removed (and replaced with fresh media).
4. Turn off OD regulation and wait 12 hours before beginning step 1 again.

Does that make sense?

I am afraid I may have misinterpreted your specific goal, if so please do let me know what was meant 🙂

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

[harrison]

That is correct!
The software setup instructions in fact assume that you are starting with a completely stock-standard Beaglebone, so you should be able to follow them as written.

[Author]

Posts