Any particular reason for choosing the Dynisco pressure transducer?

Mine is an Auber oil/fuel pressure transducer. I've been wondering if a better transducer would give me more stable readings.

Not any specific reason. Found it on eBay and was able to talk the price down. Range is swell at 250 PSI and 100mV output - so easy to amplify. Also, it is intended for high temp high pressure injection molding machines so it should be pretty robust.

So the preliminary version of the Arduino controller is ready. It is simple to control, a potentiometer and a 2 color LED. The LED switches color when the group solenoid is activated.

Red in standby:


Green when a shot is pulled:


The inside:


The 24VDC motor is controlled using a VNH5019 motor driver breakout board. The power supply board next to it drops the 24VDC to 10V for the Arduino and the pressure sensor:


The control is still manual using a potentiometer:


The group solenoid is detected using a TLP2630 opto-coupler - a rather rare dual coupler device of which I have a rail of (got it for free). The two channels are wired in parallel (open collector) and the LED's in opposite polarity, with a 220nF and 6.8K 2W resistor in series to the LED. This connects to the 220v solenoid.

The pins for the LowFlowBypass solenoid control and the pressure sensor have been allocated, but need a few more components to proceed. Also, am awaiting an EEPROM breakout so that profiles can be stored. As per an earlier post, the bypass is enabled when the Pot setting is at 10% or so of the range.

Nice work! Have you written the code for pressure transducer readings? if so, are you getting stable readings?

Still having issues with pressure and flow reading stability. Have done some testing that pretty much rules out hardware as the cause -- other instruments like a DMM and a scope show stable readings when connected to the Arduino inputs.

When the pump is active, pressure flickers 0.1-0.5 BAR, which makes it hard for the software to detect thresholds and directions. My DMM doesn't show enough fluctuation in voltage to affect the tenths place, so something is going on in the software. Adding caps to filter the signal didn't help.

The flow meter shows a stable reading for a few seconds, then it suddenly flashes about 90 ml/min lower, then it returns to the stable reading. It's almost like interrupts are being masked for a time, but every now and then it'll show higher than the stable reading, which sort of rules out that theory. The flow meter signal isn't a clean square wave -- the top of the square tilts down to the right a few tenths of a volt. But the rise side of the pulse, which the Arduino is set to detect, is clean and I don't see how the tilted top could produce the strange readings I'm getting. Also, the frequency counters in the DMM and scope show solid reading and no sudden fluctuations. They're connected to the Arduino input and the scope isn't showing any noise. I could clean up the wave with a Schmitt trigger, but I don't think that's necessary, seeing as how the DMM and scope can handle it.

I'm pretty sure these are software issues. A while back I played around with commenting out some calls in the main loop and that seemed to help, but didn't fully correct the problems. I took the LCD update out of the 2 ms sensor reading loop and put it on a 200 ms timer, but that didn't correct the problem, either. I might need to lengthen the sensor read delay. That might help the pressure sensor reading, but not the flow meter, which is interrupt-driven. Now that I've ruled out the hardware, I'm diving into the software. Also adding parameter editing and a couple of debug screens.

How much time are you spending in the interrupt handler? Remember in AVR architecture handling an interrupt masks other interrupts so keep it short.

Have yet to get to the pressure. Need an instrumentation amplifier to get it to 0-5v levels.

The motor and flow meter interrupt handlers have just one instruction ++<count variable>. The main loop has adjustable timers (200 ms at the moment) that translate the counters to RPM and flow rate. Another adjustable timer updates the display on a similar schedule. I'm not using timer interrupts. The main loop keeps track of the elapsed time for each timer.

Did some research on the web and I'm pretty sure I know what's causing the problem: my LCD shield uses the I2C interface, which is interrupt-driven. I read some posts that confirm I2C can cause interrupts from other sources to be be missed.

Assuming the LCD interrupts occur only when I'm writing to it or reading the buttons, I think I can fix this by using just one timer that will compute the RPM and flow rate, then update the entire display, check the buttons on the LCD display (also I2C), then reset the counters to zero. That way, the display won't update while the counters are counting.

Edit: This following is relevant to the LCD Adapter for the TC4C roaster Arduino. It isn't the case for the standard LCD shields that do not have a mux.

The mux that is usually used by the LCD adapters actually has an interrupt output that is usually not wired. I wired it on my roaster controller which allowed me to not poll the buttons.

The main problem with modding (e.g. converting a GS/3 to an EP) is to know when to stop. I don't have that gene...

So I had one of those TFT touch screens I could never find a use for. So pressure profiling turned out to be the goat that could rationalize a display.

1st iteration:


Once a profile is created (in manual mode), it can be replayed in auto mode (useful for making milk drinks...):

for the time being, the only intervention needed is ending the shot (as there is no feedback to the GS/3).

Still need to add pulses from the flow meter, pressure sensor input and low flow bypass...

(Note - I am not sure this is not hijacking the discussion (since the OP was about conversion to an MP, not to a Strada EP like version) - but since the EP conversion is easier and massively cheaper - I think this thread is sort of OT. Furthermore, as I am discovering - Jacob was right all along - flow profiling works - and works great.)

A short update:
Conversion to EP is progressing. Arduino is proving capable (albeit would have been much more comfortable in an Atmega rather than an Uno).

Software now does:
- Manual (potentiometer) profiling
- Session store of manual profile (for playback using Flow or PWM profiling)
- Storage and recall of 1 profile to on-chip 1024 byte EEPROM
- Automated operation of Low Flow Bypass solenoid (preset level adjustable & shown on graph)

Automatic profile replay:
- PWM profile replay
- Flow Profiling replay (using PID)
- Fully automatic profile replay operation (triggered by 3-way turning on)
* Still awaiting parts for Pressure Profiling

Display (Adafruit 2.8" display w/resistive touchscreen):
- Dashboard
- Graphing of manual profiling
- Overlay graphing doing profile replays
- PID operation overlay
- Touchscreen operation mode selection soft keys


Interim observations:
Flow profiling (meaning getting as an identical flow to the reference pull - as possible) - works really well. It is able to recreate pull after pull with little variability in flavor (have yet to test extraction).

I even tried upsetting the system by uneven puck distribution, bad grooming, etc - and what usually would have been a drain pull was actually good (good but not AS good .... Albeit it can ameliorate some sloppiness - it can't fully compensate for bad technique).

Implementing flow profiling in the GS/3 AV: Replaying the pulse count as sent by the Gicar flowmeter. The accumulated pulse counts are used by the PID algorithm to calculate the PWM sent to the gear pump. The profile (stored) count is used as the changing setpoint and compared to the current pull's count (used as the PID input). To prevent runaways, the PWM correction signal is bound to an error band around the PWM profile.

Choice of Arduino: Uno (R3 - but that makes no difference) is borderline sufficient for this project. It has ample computational ability - but I used all but 1 of the inputs/outputs, and at 90% flash capacity and 71% of SRAM capacity, and can only fit 1 profile on the EEPROM. Also, since the profile consists of an array of 200 values of PWM, flow and pressure - to fit the 600 value array on the 1024 byte EEPROM meant having to store everything as bytes. That meant an awful lot of casting to ensure one can keep precision. Sufficient - but hardly ample.

Fantastic work, Assaf!

Some questions:

1. Interesting that the PID works so well with the flow meter. How stable is the flow rate reading? Are you using a running average?

I've gotten my flow rate to settle down for the most part, but the pulse counts still vary a little and I haven't been able to figure out why. My oscilloscope shows a rock steady frequency reading, but the Arduino ml/min display will sometimes jump 15 ml/min, sometimes as much as 75 ml/min. Seems like the Arduino is missing an interrupt here and there, but I can't figure out why. It shouldn't be caused by interrupts from the motor or LCD I2C because the Arduino is supposed to queue interrupts.

All I'm doing in the ISR is incrementing a counter (a volatile int.) When the timer goes off, I turn off interrupts, grab the count, reset the counter to zero and turn on interrupts. I realized that a missed interrupt with such a low frequency (15 Hz) can have a large impact on the reading, so I changed the interrupt from RISING (or FALLING) to CHANGE. That doubled the number of pulses, which helped stabilize the reading. I'm checking the counter every 200 ms and using a running average of the last 10 counts. I've tried playing around with those numbers but there's a trade-off between stability and response time.

Still think it could be related to the LCD I2C I/O, though those interrupts shouldn't be causing issues. I've got a data logger shield and have set that up to store the various parameters to an SD card, but the display jumps even more when I use the data logger, so it seems like that might also be disrupting the count.

In the end, I may have to go with a regular display that just uses I/O pins instead of the I2C interface. That's probably what has cost you so many pins!

2. What parts do you need for pressure profiling? I thought you have the pressure transducer and setup the power supply, etc.

3. When profiling are you attempting to keep the flow rate constant throughout the shot, or are you letting it decline as the puck becomes more permeable?

4. Is the water debit for the total shot or just the pre-infusion?

5. Agree on the Mega being a better choice than the UNO. So far I'm only using about 45% of my UNO's memory space, though I've been using conditional compile flags for logging, Serial I/O, debugging, etc. to save space. For example, if I turn on the logging flag it jumps to 74% used. Haven't gotten around to saving anything in EEPROM yet. I'm planning on adding BT to query the Acaia scale and have concerns about how much memory that will chew up.

6. To save space and computation time I got rid of all the floats -- just doing integer arithmetic and formatting output with sprintf. Makes the code a little harder to follow. Didn't save any significant space, though.

7. Have spent most of my time on stabilizing the readings, sprucing up the interface, adding logging and coming up with algorithms to cap the pump speed. On the latter, I'm using timers to check the pressure and flow rate. For example, at low pressure and low/zero flow rate, the machine is either running tea water or autofilling, so I can jack up the motor speed to max. This is quite reliable and it only has to wait 500 ms to figure it out. It can tell the difference between brew and free flow, but it takes more delay time and isn't completely reliable. I've also got a trigger to detect backflush that looks for pressure exceeding a certain value with low flow rate. That works fairly well, too. All this would probably work better if I compute the direction and rate of change, but without stable flow meter readings I'm reluctant to spend time on it.

At any rate, I've been considering abandoning most of that approach and just using buttons on the controller: brew, brew with pre-brew, free flow and backflush. It'll be able to detect autofill and tea with signals from the interface board. That way, the code can regulate speed based on what the user told it to do or the detected state of the machine. Easier and more reliable than deducing it from pressure and flow rate.

Currently I'm working on breaking out the signal lines from the front panel buttons and adding relays and more optoisilators to my interface board. I've been seriously considering moving the interface board out of the brain box and into the machine behind the front panel under the LCD/buttons. That location is close to the autofill, tea, brew and (future) bypass solenoids) and It's a lot easier to make changes if I don't have to get into the brain box. It probably involves cutting the existing motor leads, but I can live with that. Can always restore them with barrel crimp connectors. Still need to tap the AC supply for my electronic steam solenoid, but lately I've been thinking about replacing that with a rotary knob so I can fine tune the steam power.

Where is your interface?

In a bit I'll post some photos of my current user interface and ribbon cable breakout board.