[harrison]

Hah! You raise a good point. This is on my to-do list but evidently not high enough to get seen-to in a reasonable amount of time. Some things to get you started:

If you look at the SI for the PLoS Biology paper there is a superior modelling SI section which includes some additional diagramatic description of the software:
https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000794

After reading that I would look at how the “customprogram” sections are structured in the python code, as these are easily adaptable for many experimental protocols one might want to implement.

If you want more customisation (i.e. new features in the GUI) it is also not too difficult, there are essentially four primary things you need to add, and each of these can be copied from any of the features already in there. They are:

1. You need to add new buttons/fields to the html file with new “id” attributes related to what you want them to do.
2. You need to add new scripts at the bottom of the html file which define how the data from the above buttons/fields is sent to the python back-end.
3. You need to add new lines to the .js file that update any labels/fields in the html that need to dynamically respond to changes in the python back-end.
4. Finally, you need to adjust the python back-end to do the hardware implementation of whatever function you are trying to do.

I realise just looking at those instructions is a bit confusing – to figure it out in practice just pick one of the features (say, the stirring interface) and trace through its corresponding html / javascript / python code.

[harrison]

Sure, I have emailed you the draft schematics and PCB files, let me know how you get on.

[harrison]

Sure – What file format can you use? Do you have access to any PCB software? If you do not have editing software I can send you Gerbers that you can use to get it fabricated and a BOM.

[harrison]

Hi Filippo,
Yes, this is no problem to implement. There are 4 pumps, so assuming 2 are used to implement a turbidostat-like mode, the other two are free to program as you please. Adding a custom program which switches which pump (or a combination of the two) depending on OD is quite straightforward.

[harrison]

I have designed the PCBs and have some (unassembled) sitting on my desk, but have not had time to assemble them. If you fancy doing some soldering I can send you schematics so you can do it right away.

[harrison]

Hi Nishant,
Do you not have any reactor at all?
You should be able to load the software without having a reactor involved if you disable all the “Initialise” functions in the software – these are responsible for checking reactors are there and setting default values for all the hardware.
If you do have a reactor, but it isn’t connecting properly and blaming the Multiplexer, there may be a fault with the PCB attached to the Beaglebone Black. This is a hardware issue with some boards – Labmaker should be able to fix it for you.

[harrison]

Yes, send them an email. Mention I sent you and it seems you have a faulty pump board. Attach the logs above so they can see it is causing continual errors.

[harrison]

From the look of the above it seems that there must be a faulty pump board. There should be very few such errors (maybe once every few thousand times you send the command, not EVERY time). It seems that in MOST of the logs you attached the system is able to correct the error (as it is designed to), but infrequently it fails to do this, which is why it then stays on for longer than expected. I expect the issue is a poor connection on the USB connector or circuitry on the Pump PCB, which Labmaker should be able to sort for you.

[harrison]

Very good – I have just designed a custom PCB to fit this to Chi.Bio, will have them manufactured and keep you posted!

[harrison]

Both of those look promising, we could fairly easily integrate either into the Chi.Bio. Was your plan to have this combine with the Atlas sensor PCB?

[harrison]

Hi Gian – I assume you got this sorted (sorry, I didn’t see your topic previously). But yes, it seems multiplexer is the issue, a faulty PCB I expect.

[harrison]

Hi John, it looks like a faulty Multiplexer PCB. Has Labmaker gotten back to you on this front?

[harrison]

Let me know when you get a chance to test that, in the meantime I will try to figure out what else could be done to fix it in software (though I think working hardware would be a better first step!).

I can now see your other replies to this thread with logs for when the system worked. In these cases you can see the connection to the pumps is still causing issues, but nevertheless it is able to recover. So, it seems sometimes the recovery fails – perhaps this could be fixed by adding additional checks to the recovery procedure, but this will then slow down the entire system in general.

• This reply was modified 5 years, 11 months ago by harrison.

[harrison]

Hi Pablo,
Looking at your log it says at the top:
| BeagleBoard.org Debian Buster LXQt Image 2020-05-18

So it seems you are using the LXQt Snapshot, rather than the “Debian Buster IOT Snapshot” which is linked just below it on that page (and is I believe what is specified in the Chi.Bio software manual). I think if you install the IOT snapshot there should be plenty of room on the device.

[harrison]

I will have a look at well – currently we are investigating implementing the Atlas PCB you linked previously.

[Author]

Posts