Here are some photos of my latest screen interface. No where near as nice as Assaf's but that's a function of the screens we each had lying around.

All the photos were taken with the Arduino disconnected from the GS/3, so most of the values displayed are zero.

This is the main screen:


BAR is, of course, pressure. Pmp is the pump speed in percent of max. Fl is the flow rate in ml/min. An asterisk appears in the first column of the second line when the motor is on. The "m" means manual mode (pot-controlled). This can be toggled with the LEFT button to "p" for program controlled. The "^" means pressure limit, which is set to 10.5 BAR but can be toggled with the UP button to 12 BAR.

Here's the main screen in program-controlled mode:


The small "b" means force brew speed. This is toggled with the DOWN button.

When the SELECT button is pressed, the screens rotate from Main to Speed to PID (if the PID conditional compile flag is defined.)

This screen lets the user change speeds on the fly for each of the four running modes: brew, free flow, max and backflush:



The cursor blinks, but the camera caught it between blinks. The LEFT and RIGHT buttons position the cursor on the value to change, while the UP and DOWN buttons increment or decrement the least significant digit.

This screen lets the user change the PID parameters on the fly:



Same edit buttons as the speed screen.

The RIGHT button in the Main screen rotates through two additional debugging screens.

This screen shows the computed voltages for the pressure transducer (Vb), pot (Vp), PWM for motor (Vm) and flow meter frequency in Hz:



This screen shows the raw A/D count for the pressure transducer (Bc) and pot (Pc) and the raw counts for the motor tachometer and flow meter:



Here's the data logger shield I'm using. Very easy to setup and use:



Finally, here's my ribbon cable breakout board for tapping into the front panel buttons (specifically the brew button) and possibly tapping the 12V signal to the button lights:



The ribbon cable from the front panel buttons plugs into the left socket and a short F-F jumper connects the right socket to the logic board (or, if I put the interface near the button box the cables will be reversed.) The signals are broken out on 16 header pins. The pins are covered with jumpers to protect against shorts and to make it safer to test with probes. Four jumpers are removed to show the pins.

Bottom of the board:



Takes a lot of wires to make the connections! These will be covered with liquid electrical tape.

Peppersass wrote:
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?

Readings are not stable; one can use inter-pulse timing to try to better understand the flow through the flowmeter - but I decided what made more sense was to track the number of pulses as they come in. Say by second 30 you'd have - say 150 pulses in the reference stored pull - the PID will work to try to get the current pour to 150 as well (the target keeps changing, as does the limits for the PWM output).

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.

I had electrical noise issues as well... Whenever I try to get fancy with interrupts - you need the Atmel datasheet.... At the end it depends on the flags and settings for the interrupt.

I'd be careful of turning off all interrupts. I try to get away from it and use detachInterrupt... I only used noInterrupts for Sleep and similar tasks.If I needed to do inter pulse timing noInterrupts may also be needed.

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.

That is also what Jacob did. It rubs me wrong as you are not adding more data - you are simply doubling the number of pulses without increasing precision (why not just multiply by 2 - or better: << 1). I'd rather use the extra CPU capacity to do better filtering, etc.

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.

I store to a byte array. Any device activity (e.g. EEPROM) is done in Idle state.

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!

The display and touch screen use SPI. the group solenoid and flow meter use pins 2 & 3 (INT0 and INT1). I have about 5 pins for the motor driver board, 3 more pins for the display and touch screen chip selects, a few LED pins, and that more or less leaves me with 2 free pins...
[/quote]

2. What parts do you need for pressure profiling? I thought you have the pressure transducer and setup the power supply, etc.
[/quote]
The part I found in Israel outputs 100mV FR. so I need to build an instrumentation amp. Easy if one has +-15V supply. I have a 10V single supply. And the input is at 100mV - so I need a ground tracking instrumentation amp. Also awaiting a Bendix connector for said transducer... No military pot - but a Bendix connector!

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?

I only profile a manual shot with the potentiometer. (I currently let it decline - since it is new ).

Automatic modes try to replay the same shot trying to keep the pull parameters as close to the reference shot as possible. Currently the approach tracks flow pulse, and uses the PWM profile to bind the motor speed.

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

Entire shot.

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.

Awesome idea. Have Acaia put the development kit back online?

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.

Make sure you are not losing precision. Also PID uses double precision... but the profile is in bytes.... so lots of casting.

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.

I use both pumps. Gear for brew and rotary vane for steam (even though it may not be necessary - mains here is 3-4 bar...). The two lines are completely separate. I am actually thinking about circumventing the filtering and softening for the brew boiler (as it tends to be less sensitive to deposits than the steam boiler). Water hardness here is not too bad (but bad enough for boiling water and combi steamers...).

Interface is 4 Teflon wires that go to 2 optoisolators that are affixed to the inside bottom chassis of the GS/3. There is (as of yet) no more interfaces.

Funny thing is that since I am replaying a shot - and since both the Gicar 3d5 and the Arduino count the same pulses - the pulls stop at the same place (up until now at least - this is 2 days old...).

I have to think of why and how to connect to the Gicar. Maybe the LED signals are a good way for the Arduino to identify which mode is active?

Outgassing (or stale) coffee and flow:

When doing PP, coffee outgassing and "staleness" is actually pretty measurable on a day-to-day basis.

In the screenshot below, the profile was stored 3 days ago. The flow rate goes up as coffee outgasses and "stales". (The darker green line is the stored flow profile; the brighter green is the current flow).



I find it rather neat that the difference is so profound that the flowmeter can actually measure the difference within a span of a day or two.

PP works very well, as flow changes we obviously compensate with grind. FP also works well - but tends to overshoot if grind is too fine (in trying to "force" a specific flow through the puck).