Kal's panel, switchable to CBPi

[GParkins]

I posted in the Electric brewing forum and on Kal's site a few days ago about a panel I've been working on that is based on Kal's outstanding design, but incorporates a couple of things that I thought would be "nice to haves" for what I'd like to brew with. That design has come along nicely, and the latest iteration is attached. The only update for this round is an improvement in the metering. Now, the meters both read bus voltage, and are split so that one meter reads L1 and the other reads L2. They are also powered before the contactors, so they are on full-time, and I can always see the difference in current between L1 and L2.

Today, I was skipping around between the Electric Brewery forum and the HBT forum, and I fell down a Raspberry Pi rabbit hole. I also read Kal's sticky post about why he opted to not include automation of any kind, and his points are valid, especially regarding long-term support for a specific automation ecosystem.

So what I did was add the capability of switching between manual panel face control of a pair of PIDs and a pair of pumps and automated control via a Raspberry Pi system. I added one 3-position center-off single pole switch, two DPDT relays, one DPST relay, and two SPST relays. I think that as far as power and relay coils are concerned, it is a functional design. That drawing is also attached.

I still have to draw a sensor/signal diagram. I don't know if it will be easier to use a 4PDT relay to switch the output of a 4-wire PT100 sensor or add a second thermowell on each vessel. I still have to think that one through.

I also have to see if I can shoehorn a 7" touchscreen display and another 22mm switch onto the enclosure door.

 

[GParkins]

Here's the panel face:

 

[golfindia]

Using PT100 sensors with the RPi adds a layer of complexity - max31865 rtd-digital converters. That would mean 4 4-pole DT switches. Blech. I'd rather just add 4 sockets to the box, have one bank for PI use one for PID use.

 

[BrunDog]

Per golfindia's comment... do not add switches inline with the RTD probes. They will negatively affect the accuracy and add areas for failure.

I also would suggest you commit to use one system or another. Combining them for a backup adds unnecessary complexity, hardware, and cost, and suggests you don't have faith in the solution.

I also think a 7" screen is a waste of time.

Sorry - these are my opinions.

 

[aeviaanah]

Per golfindia's comment... do not add switches inline with the RTD probes. They will negatively affect the accuracy and add areas for failure.

I also would suggest you commit to use one system or another. Combining them for a backup adds unnecessary complexity, hardware, and cost, and suggests you don't have faith in the solution.

I also think a 7" screen is a waste of time.

Sorry - these are my opinions.

I planned on using switches to have my temp monitor read between various PT100. Are you recommending against this?

 

[GParkins]

I've given this some thought, and while it adds complexity, I don't think accuracy will be affected, because the only functional difference is added sensor wire "length." The added resistance through the 3PDT relay (I decided to go with 3-wire PT-100s) will appear to the PID as just longer sensor wires, which can be corrected during calibration. Once calibrated, the sensors should work just fine. There will be different calibration factors for each system, but both systems need calibration, so BFD, right?

 

[GParkins]

I also would suggest you commit to use one system or another. Combining them for a backup adds unnecessary complexity, hardware, and cost, and suggests you don't have faith in the solution.

It's a way for me to try newer stuff without risking a batch. If I try a new add-on on the bench, or with water, and it seems OK enough to throw into service, my experience is that with live grains in the pot, the condition that causes a crash will invariably manifest.

I also think a 7" screen is a waste of time.

Yeah, but the box is already 24 x 20. I don't want to go any bigger. I'm hoping to be able to do most of the heavy lifting from a browser interface, and just use the 7" as a limited display.

However, with a little rearranging, I can get a 14" W x 12" space available on the door. Have to think on that a bit.

Also, It seems we're in the same area. Sending you a PM.

 

[golfindia]

I second the display comment. Running a display from the Pi also bogs the software down in my experience. And you'll need to either run ethernet to the control box or use an external usb wifi adapter. On board Pi wifi won't work in a metal enclosure. From a reliability standpoint, i think it would just be better to make a separate software control box.

 

[BrunDog]

I planned on using switches to have my temp monitor read between various PT100. Are you recommending against this?

Yes. The amplifiers which read PT100 probes are highly sensitive to resistance differences. The upside to these is they are very accurate, but the downside is the small range of resistance changes which computes the resulting temperatures. Unlike thermistors which are high impedance (say 10,000 ohms), these are low (100 ohms nominal hence the '100' in Pt100... and Pt for platinum). Adding any type of switch or connector WILL change the resistance. It may be minimal, but if you are using these sensors, you are likely shooting for accuracy. It may also change over time with switching etc. I know connectors (like panel mount) are frequently used, but these should not be done without considering the implications, or with cheap connectors if you want to maintain accuracy/repeatability.

 

[BrunDog]

I second the display comment. Running a display from the Pi also bogs the software down in my experience. And you'll need to either run ethernet to the control box or use an external usb wifi adapter. On board Pi wifi won't work in a metal enclosure. From a reliability standpoint, i think it would just be better to make a separate software control box.

Agreed. Or just use a separate display. A BIG one! Cutting holes for proprietary panels may bite you later if the panel cooks (these are typically not industrial duty unless you $$ for it.)

For example, I will be incorporating a 24" 1080P touch monitor into my rig soon, mounted on an arm.

 

[GParkins]

After spending several hours on BrunDog's website, I am thinking of switching over to his system, vice the Rpi.

Reasons:

1) Expandability into fermentation control looks a lot easier.
2) I'm leery of the crashes I keep reading about with the RPi. BruControl looks more stable.
3) It looks like I can offload a lot of the sensor and control wiring into a very small enclosure on the stand, and drag big cables out only when something fails.
4) It doesn't look like I'd have to tear my whole design down and start from scratch. The more I think about a hybrid manual/automated system, the more I like it.

The company I work for builds automated power distribution switchboards. Their philosophy is that the design must start with a manual switchboard. Layers of automation are added, based on the customer's requirements. It's a belt-and-suspenders approach, but we've never had a customer unable to get power onto the distribution bus.

I do like BrunDog's comment about proprietary displays. Cutting a hole in the door is like being the pig in the old saw about the difference between being "involved" and "committed." In a bacon-and-egg breakfast, the chicken is involved, but the pig is committed.

 

[golfindia]

I used Arduino devices for the DROs on my mill. Ultimately I got them to work, but the experience soured me on them. I became an expert at firmware flashing at the end of the ordeal. Maybe arduino devices have improved in the last couple years.

 

[BrunDog]

I agree that writing code, compiling, flashing, then testing is not ideal. That is why using Arduino alone for brewing is not a good solution in my opinion. However, micro-controllers like Arduino are rock-solid in operation as long as their hardware is integrated properly.

This was the goal of BruControl. It requires no code to be written or debugged by the user, and all the configuration, operation, and scripting is handled via the user interface.