I ( Arthur Wolf, Smoothie project creator guy ), was contacted by Phillipe Cochin ( https://covid3d.org/ ), asking for help with stepper-motor related questions for their syringe pusher project. We talked on the phone and exchanged quite a bit of info, this page is about listing that info for future reference, and to share it with other members of the project.

About

This page is an internal document with some information regarding the syringepump Open-Source project. If you found this at random, this probably doesn't matter to you.

Note: I happen to be myself working on a *separate* Covid-19 project ( along with a grant request to the current call for projects etc ), so I can't be 100% on this to help, but I'll do my best.

Note: Interestingly, the OpenTrons project already uses Smoothieboard to manipulate Syringes ( as well as move them around, which this project doesn't have to do), and we added quite a bit of syringe-handling-related code to Smoothieware for them.

Torque/stall detection

Trinamic drivers stall guard

The plan I was originally approached with, was to use Trinamic driver's “stall detection” feature.

This feature detects current changes in the stepper motor's coils, to check for increases in torque, and actual stalls ( no longer able to move ) of the motor axis.

The Smoothie project is a very large community, we have lots of users, and because the board is very innovation-friendly, a lot of these users are users that try weird and new things. And so, we have quite a few reports of users trying to use Stall detection, either to detect actual stalls or as an alternative to Endstops, to detect when the axis is at it's end and it should stop moving ( “Homing” in CNC/3D printing lingo ).

ALL ( possibly a dozen ) reports on this by community members, are that stall detection is unreliable at best. It has a lot of false triggers.

Some false positives, a lot of false negatives.

This feedback/testing makes it that the Smoothie project does not recommend this method at the moment ( Trinamic might mature it later ) for CNC machines. The corollary is that this very likely shouldn't be used for this syringe project.

There are alternatives, discussed right below:

Encoders

Rotary encoders

A rotary encoder ( tends to be very inexpensive ) on the stepper motor's axis would follow the motor's rotation along with tick by tick. When the motor attempts to turn but is not able to, the control ticks to the stepper drivers, and the encoder reading, would diverge, revealing the stall, and allowing the system to go into Alarm mode.

The issue with this is that there is currently no code within Smoothieware to support rotary encoders. These are typically left for the external servo drive to deal with, but in this case, an external servo drive would be several times more expensive than the Smoothieboard itself, and you'd need one *per* axis. Trinamics has some drivers that have an encoder input but making a board for these, and the code to take advantage of these, would take weeks at the fastest, and so I'm assuming that's not an acceptable path.

Linear encoders

Another type of encoder ( more expensive ), is the linear encoder, which reads the position of something along a line. It'd allow us to read the current position of the syringe along its possible path and detect if we asked it to move somewhere, and it is somewhere else.

The same thing applies as for rotary encoders above though: There is no code to support these, they can't be read and their data can not be taken into account.

There *is* an interesting possibility here, see below:

Digital calipers

Chinese digital calipers are cheap and have a data interface. Implementing support for these into Smoothie would mean you install one along with the syringe, Smoothie reads it's value ( measured distance, matching the syringe travel. See https://sites.google.com/site/marthalprojects/home/arduino/arduino-reads-digital-caliper ) over the wire, and if it detects a large enough difference between expected position and real position, it goes into alarm.

This is a great solution: the parts are cheap, it would be very accurate and reliable, and it requires less coding than “actual” encoders. However, it still requires coding.

If this is the path chosen, I can ask around the Smoothie community, some of the people who usually accept Smoothie-related gigs/jobs, if they have the time to do it, and at what price. Considering the situation, some might even do it for free or at a discount. If money is still needed though, does this project have any funds/cash for this sort of stuff?

Force sensor

This is my recommended solution ( assuming testing shows it does work ) because it's the solution that requires the least work and time to implement. Also, it's cheap, hardware-wise.

Between the screw's nut, and the syringe's butt ( at the exact point where the system is pushing the syringe ), add between them a Force Sensitive Resistor. This kind: https://en.wikipedia.org/wiki/Force-sensing_resistor

They are cheap, reliable, and measure force. We can read their resistance ( and so the force applied on them ) with the Smoothieboard's analog input, and with a minimal amount of code, make it if Smoothie detects an anomalous value on them ( meaning too much torque, or not enough torque ), it goes into Alarm mode.

This would allow detecting over-pression events ( such as syringe being empty ), at a minimal cost and amount of work.

If this is the chosen path, a bunch of different FSRs should be purchased ASAP so several can be tested for this particular use case, as soon as possible.

Endstop

The machine should have this no matter what. If stall/torque detection is implemented, it should be on top of a proper endstop. The Endstop allows detection of when the syringe is empty, but also allows pulling it back as far as can be done ( and detecting when at that end ).

It's possible to use optical or magnetic endstops here, however it should be noted that mechanical endstops have the best reliability track records, and therefore should be used by default unless there is a very good and overwriting reason to use something else.

Smoothieboard

The Smoothieboard seems like a very good fit for this. ( note: other controllers would probably also fit, but I'm a Smoothie specialist, so that's what I'm talking about here. If you want to talk to other project leads, say for Marlin or the Due system, you should know that if you contact them they are very likely to be very attentive, they are great people ).

It has:

  • 5 stepper motor drivers, which can be used to push 5 syringes
  • 5+ endstop inputs to allow homing and “end” detection of the syringes
  • Analog inputs if these are needed for the torque sensor system
  • We can make a special Bill of materials of Smoothieboard ( ID smoothieboard-syringe ) that lacks all the components not needed for this project, and manufacture those, therefore reducing the cost per board.

For the supply of Smoothieboards:

Option 1: Uberclock and Robotseed, the main Smoothieboard manufacturers, have a stock of 250 Smoothieboards 5XC that they can provide.
These boards *currently* are missing their Ethernet component, meaning to be useful for this project, we would need to have the Ethernet parts soldered on, which is a manual operation. The current testing house could do about 30 such boards a day. They could start working, and send 50 every time they have 50 done, so boards are received as soon as possible even if not all are ready yet. This is likely the fastest way to get Smoothieboards for this project.

An alternative would be *not* to use the Ethernet part of the board, in which case these boards are available immediately. However, this would require an alternative host for the interface, such as a Raspberry Pi Zero ( €5 ), and make the project a bit more complex.

Or, another alternative is simply to skip Ethernet altogether, and use a “host” computer to control the Smoothieboards. In this case, it'd require writing a “host” program to run on the computer, which is significantly more work than the above-proposed “web” interface served over Ethernet. But it's a valid option.

What's most important here? Cost? Time-to-working-system? Safety? All of these with varying degrees?

Depending on what's most important, there are different options to consider here.

Option 2: We could use a local ( French ) PCB/board manufacturer, and have them produce the PCBs for Smoothieboards, and assemble them locally ( with the special “smoothieboard-syringe” BOM, which is less expensive ).
This could probably allow the boards to be made in between 1 to 2 weeks. We have a special contact/relationship with a local PCB manufacturer that *might* enable us to skip some steps and get the boards faster than normal.

It's also possible that there is some special Government-licensed PCB manufacturer (for the army? we know of such things from our previous work/customers), that the government/officials could pressure into producing these as a priority. I don't know of anything like this, but I can imagine that somebody with the right contacts might be able to get something like this rolling.

Option 3: There are counterfeit versions of Smoothieboard online for sale in China. These are unsafe ( counterfeit components, bad production quality, no/poor quality checks and functional testing, shady business practices ) and ethically problematic ( http://smoothieware.org/troubleshooting#what-is-wrong-with-mks ), but they are way better than “nothing” if you don't have an alternative.

Option 4: We can get Smoothieboards produced in China in the normal factory, using the normal process. This would be the most economical solution, it would be the safest quality-wise. But it would take 3 to 4 weeks. We can discuss with the factory ways to speed things up, it *might* be possible to bring this down to something around 18 days, but it's not certain. Just putting the option here even though I think I gather from the phone call this would be too long. Maybe if this is something that will be used for longer than 2 weeks ( I don't know how long the crisis is expected to last ), we should use both one of the fast but expensive options above, and this longer but more economical option, that would seem to make sense.

As needed, I can contact the different factories and ask for more precise delays and prices, just tell me: wolf.arthur@gmail.com

Web GUI control

The Smoothieboard has an Ethernet port, and via this port, it can serve a Web interface ( HTTP server ).

This would be the simplest and fastest way to design a control interface for medical personnel to control and set up the automated syringes. They would simply connect to the Smoothieboard's IP on the local network ( using a local computer, or their phone, or an android tablet glued to the syringe system. Then in this ( pretty easy to develop, it's modern HTML/CSS/Javascript, go to Paris and wave your arms around, you're sure to catch at least a dozen web devs ) interface, they have a form/interface that allows them to enter values, start/stop things, monitor, etc.

I can help a lot with the dev of the web interface ( I dev the current “for CNC machining” Smoothieboard web interfaces ), and I can possibly find some people in the Smoothie community who are ready to do this work as a paid project if there is cash available for that ( it's possible if I explain why this is used, some of the devs in the Smoothie community might lower their wage down a lot, or even do it for free ). If you want me to start contacting contributors and ask them if/how they'd like to help, tell me via email and I'll start contacting them.

Liquid pressure sensor

A pressure sensor could be added to the output of the syringe ( along the tube where whatever is injected travels ), to detect the pressure of the liquid that is being injected. Detecting the value of the pressure would allow the system to detect if everything is alright.

I believe/expect that:

  • If the liquid is correctly being injected into the patient, the pressure is going to be at a given and recognizable value, and so we can detect if everything is alright and if not stop everything.
  • If pressure drops too much that might mean something is cut or disconnected
  • If the pressure gets too high it might mean the tube or an artery is plugged/won't let the injected liquid through?

It's possible adding this pressure sensor at that place ( along the tube between the output of the syringe and the needle ) is not sanitary, or that a special version of a pressure sensor designed for this use/hygiene exists or would be necessary, or something else. I'm definitely not an expert on any of this at all, please don't get upset at me for suggesting something stupid :)

Safety

Smoothieboard was *not* created as a safety-critical system.

No work has been put into making sure it's safe enough to put somebody's life in its hands. I believe that's true of other comparable systems too by the way. They just aren't routinely used as medical device brains.

It's a very stable and well-crafted system, it's used by tens of thousands daily and it has been months without an actual bug report, it's very very mature. Users rely on it for their safety in the sense that their CNC mill or laser could hurt them if it malfunctioned, and it reliably doesn't malfunction.

But putting the board in charge of somebody's life is probably going to require testing it much more than it has been so far. Well, that's unless the choice is between somebody dying, or using the untested system, in which case I guess death is worse than any other option, including unsafe ones. You know what I mean.

I just wanted to make it clear what the system's safety is rated at ( that is, nothing ), and make sure nobody comes putting blame on me afterward because something went wrong and I was unclear about safety.

The plan

Here is how I would imagine a plan to make auto-syringes ( how are these things called? nobody told me ) would look like if I had to figure it out ( I'm sure I'm getting things wrong, this is just my first reaction to being asked about all this ):

1. Design a special version of the Smoothieboard with only the parts/components needed strictly for this project is on the BOM, reducing the price of production of future boards made for this purpose.
2. Start producing Smoothieboards en-masse if the 250 boards currently in stock are not enough long term. Start producing them now so that 2 to 3 weeks from now they are available. Otherwise, just rely on that 250 stock.
3. Get the Smoothieboard testing house to take the current stock of 250 boards ( that have Ethernet missing ) to add Ethernet to the boards as fast as possible. Ask them to ship boards to France ( they are in the US ) as soon as they have 50 done ( which should be every two days approx ).
4. Test both the FSR solution and the digital caliper solution. Determine which works best/which is preferable. Start purchasing components and find a contact developer ( along the existing Smoothieboard contributors base ) for the code this solution requires.
4bis. Start work on the web interface with a contract coder we've found in the Smoothie community ( ideally, as they already know the project/code ), or some web dev off the street/job market.
5. Manufacture and test the whole system as a prototype using test Smoothieboards and the various parts needed, gathered from local ( fr ) electronics shops such as Gotronic and similar.
6. Validate this prototype works.
7. When we receive the first batch of 50 ( now Ethernet-enabled ) boards from the US, start mass production of the machines ( I don't know where/how, at this point, this stops being Smoothie-specific and my part of the job is mostly done ).

Comparison of options

Bellow please find pros and cons for the different options presented in this document, to help with choosing which way to move forward with the design.

The comparison can be found at : https://docs.google.com/spreadsheets/d/1UT5zNyo1xt-qPeB4LfyTRXMTwKU8H6BDeTEF9So0A3E/edit?usp=sharing. Note: please follow the link instead of the picture, a section was added to the document since the screenshot was taken.

Forseen issues

  • I2C on the calipers: The calipers communicate via I2C ( or something similar, to check ), but I2C isn't ok for communicating over wires ( it's only ok between components on the same PCB ). So we need to do something about this. The classic solution is a UART-to-I2C circuit board, which will need to be designed, or sourced off the market. All in all not a huge issue, just something to address early on. Can be done using: https://learn.sparkfun.com/tutorials/qwiic-differential-i2c-bus-extender-pca9615-hookup-guide/all

Todo