I’ve agreed to help a couple of my colleagues automate some of their lab equipment using a raspberry pi. This is pretty much the blind leading the blind, as I’ve never used a raspberry pi (or similar) before, but I’m more comfortable coding than they are and it sounded like a fun project. I’m keen to use Julia for the code if possible.
Essentially, they have two pumps. One pump pumps fluid from a large reservoir into 6 smaller tanks and the other pumps it out of the smaller tanks, into a waste tank.
They want to have the the fluid pumped in and at regular intervals about an hour apart, followed by pumping out. If the fluid level in any of the 6 tanks hits a certain max level, then the in pump should stop, but the out pump should keep going. After this, once all tanks are back down to the min level, normal in/out pumping should resume.
The pumps are set up for remote control “Stop/Start Connect remote switch between pins 7 and 15 of the 25D connector. A TTL compatible logic input (Low 0V, High 5V) may be applied to pin 7. Low input stops the pump, high input runs the pump. With no connection, the pump will default to running.”
If anything really unexpected happens (e.g. one tank is at min while another is at max, or one tank remains at max despite hours of only pumping out). The system should stop and we should be sent a text or whatsapp to say what the problem is.
This is just a general call for advice in all areas! Which raspberry pi should I be using, if I want to run Julia? What kit do I need to purchase to get me started (maybe someone has good/bad experience with particular fluid level switches)? Will the GPIO pins that come with the raspberry pi be enough to get the job done, or will I likely need additional adapters? Has anyone found a way they find particularly convenient for sending messages? Maybe someone found a particular resource useful for learning all this stuff?
Maybe you can check BaremetalPi.jl. This package is design to access GPIO, SPI e I2C using pure Julia code (no external libraries).
My ideia is to embed in the future a full satellite attitude control to prove the concept that we can use a high level language like Julia for critical applications.
I’ve been dealing with lab equipment automation for 7ish years, and if this is your first foray, I would strongly recommend following a well-trodden (well-documented, commercial) path rather than forging your own trail, particularly if this isn’t your own equipment. The nature of lab equipment is that it needs to be modified to meet shifting research needs, and if your colleagues aren’t good with code, you’re signing yourself up for a long period of unpaid support work (with panicked calls from your colleagues because a pump isn’t shutting off, etc.). Before going the Julia/RPi route, I would seriously consider one of these:
Well, why not going for Rasperry Pi and Julia? But if you do, choose a pi4 with at least 4GB RAM. And install a 64bit OS, e.g. Raspian headless. I must think a bit about other hardware suggestions…
The application logic consists of simple conditionals that can be implemented in any programming language in an hour, so the choice of hardware & software should prioritize other factors:
Robustness to voltage spikes and adverse environmental conditions
Ease of expansion with off-the-shelf components (temperature measurement? audible alarms? physical override switches?)
Well-documented knowledge base to allow end users to troubleshoot and modify the application
Long-term stability: will the hardware and software be supported for a decade or more? I can open and run a Labview application written by grad students from two decades prior.
Long-term stability: will the hardware and software be supported for a decade or more?
10 years is a long time… Pi 4 will most likely be supported another 5 years, but I would not bet on 10 years.
And while Julia allows to write code that will still work in 10 years, you will not get security updates for older Julia versions any longer in a couple of years which could become an issue if you want to have a device that is connected to the Internet.
So if you need a secure internet connected device you will have to invest some work in software updates no matter what… But that is not a Julia specific problem…
Well-documented knowledge base
Should not be an issue for Julia or the Raspberry Pi…
Robustness to voltage spikes and adverse environmental conditions
Will the GPIO pins that come with the raspberry pi be enough to get the job done, or will I likely need additional adapters?
If you want a solution that is very robust and expandable, you could add tinkerforge industrial I/O modules, see: Shop | Tinkerforge and Shop | Tinkerforge
Very expandable and very robust, but not well supported by Julia yet, this means you would have to invest some time to get it up and running…
A year or two ago, I fully replaced a Labview hardware/software interface for wind tunnel instrumentation that’d been running for 15 years (with user modification along the way) with… another Labview hardware/software interface. I’m a vocal advocate of Julia for modeling and data processing, and Raspberry Pi applications requiring sophisticated data processing might be a good fit for Julia, but if you value your time, there’s no need to reinvent the wheel for automated tank monitoring and relay control.
Well, its a matter of taste and a matter of money available… Julia, Pi and Tinkerforge means open source, open hardware and fun, good learning possibilities for students and no closed-source vendor lock in as you have it with LabView … But you have to be willing to spend a little bit extra time to get started …
And if you want to use Tinkerforge I/O modules, they support C/C++, Python and TCP/IP, but not Julia yet… But calling C/C++ or TCP/IP or Python from Julia should be straight forward. For the api, see for example Doc | Tinkerforge
As ufechner7 recommends, get a Raspberry Pi with more RAM. If you are going to use an older Raspberry Pi, I recently started experimenting with a PI 3+, then you will have to increase the swap file size (maybe you’ll have to anyways). When I was adding a package it started but eventually killed the Julia process with the default swap size. At least for compilation I saw Julia documentation that recommended increasing it from the default 100 to 512. The precompiled ARM version of Julia 1.7.2 with increased swap worked for me though.
LabVIEW and NI hardware are great if you already have them and are familiar with the circuit diagram programming style but there is a high up front cost, financially and in learning LabVIEW. It’s not unheard of for a PI to ask technicians to work magic with little to no budget.
The suggestions here are great. I’m taking notes for my own tinkering.
I really appreciate the advice to go with something tried and trusted like Labview. The Raspberry Pi idea was suggested to my colleagues by the manufacturer of the pump they are using, and they are pretty excited do it. I’m just extra help, but I will pass on your advice.
Even if we end up going a different route I will definitely check out the embedded org and BaremetalPi, as I’m now thinking up other side projects for fun. We would be getting a new Raspberry Pi for the project, so I’d definitely go for the most RAM we can get. Thanks for the tip. As it’s an indoor application which is seemingly pretty straightforward, I don’t think tinkerforge modules will be necessary, but looks really handy for (potential) future projects.
I think that just on/off type of IO is sufficient for your application. If you need some ADC IO you may check out the MCC product line (still NI!). They have a nice C and python library. I have implemented a Julia library for the MCC 172 that you can extend for the other modules. It will be a start at least.
I did some work with the Teensy in the past. If you are going down the path of custom applications then this is worth looking at. It has lots of IO, including analog and a vibrant community willing to answer questions. If low power consumption is really important then the dragonfly is worth considering. The IDE for these are based on the Arduino IDE.
Finally I would definitely bring stillyslalom’s experiences and advice to those making the decision.
Just for your information, I am trying to prove that a Raspberry Pi Zero 2W can run an entire satellite attitude control algorithm inside Julia. The algorithm workload is very low, and I am 100% sure that the Pi Zero 2W can handle it. Now, I am testing if the system can meet the deadlines. The following table is the average latency from an experiment that just acquire the room temperature at every 5s inside Julia using BaremetalPi.jl:
I do not know. I guess not. I think it is related to some cycling between tasks of the Kernel. I am performing a new experiment in which I fixed one core to Julia (I can do this now because the Pi Zero 2 has 4 cores :D). I will post here as soon as I get the results.
Just how DOES Julia handle ‘out of memory’ error? Does it fail gracefully, or puke with a seg fault? I assume Julia uses whatever virtual memory is available first.
So, if you know your file exceeds both real and virtual memory, does Julia automagically create a “sliding window” for loads/stores or is that up to the programmer to manage (like every other language.)
