Shop OBEX P1 Docs P2 Docs Learn Events
Propeller Brewing System — Parallax Forums

Propeller Brewing System

wickedbeernutwickedbeernut Posts: 6
edited 2012-12-07 09:34 in Propeller 1
I'm in need of some free advice. I'm about to revamp my computer-controlled brewing system,

www.employees.org/~joestone/Sbs/Html/rack_side_s100_q100.htm

and I'm looking for recommendations in terms of a microcontroller.

My brewing system is currently based on an 80286 PC (running DOS) with an IBM DACA (Data Acquisition and Control Adapter) ADIO (Analog/Digital Input/Output) board.

I've grown rather fond of the 80 x 38 ASCII character graphics. :smile:

I have two applications: one which creates recipe files,

www.employees.org/~joestone/Sbs/Html/recipe_page_s100_q100.htm

and the control software (which accepts a recipe file as input),

www.employees.org/~joestone/Sbs/Html/gui_initial_s100_q100.htm

I need to monitor at least two analog inputs (LM34 temperature sensors) and control eight digital outputs (solenoid valves, pumps, electric heater elements, ...).

I'd like to think that I've narrowed my choices down to the C3 and HYDRA. The C3 seems a little better suited for industrial control with its 2 x 16 header of I/O pins and its 2-channel, 12-bit A/D converter. I guess my question is whether the HYDRA with its game development kit would help me to develop my (albeit) simple ASCII character graphics? Or whether I would get sufficient graphics support out of the C3?

Any other suggestions?


Has anyone on the forum developed this type of industrial control application using a C3 or HYDRA?

Joe

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2012-12-05 18:51
    The C3 can do the same graphics as the Hydra, even has essentially the same video I/O connections except that the Hydra uses a switch to turn the buffers on while the C3 uses I/O pin 15 set low to do it. Look at the Digital I/O Board Kit for your 8 high power outputs and 8 inputs that might need optoisolators.

    There are VGA drivers that can handle 80 x 32 text plus small areas of bitmapped graphics. The built-in ROM font has drawing characters (character graphics). The amount of bitmapped graphics is limited by available memory. You'll have a relatively large complex program, so figure mostly on using character graphics.

    The C3 has a built-in micro-SD card socket and there's software to read/write PC-compatible files. If I were doing this, I'd use the flash memory on the C3 to hold the recipe in a convenient format during the "cooking" time. The recipe editor could save a simplified version of the recipe to the flash memory for the control software to use. The programs would be stored on the micro-SD card as well as the recipe files.
  • Mike GreenMike Green Posts: 23,101
    edited 2012-12-05 19:24
    Attached is an archive with C3 FemtoBasic, an integer Basic for the C3. This uses a VGA display of 80 x 40 characters with 8x12 characters and a per-row color setting for foreground/background. Individual characters can be inverted by setting their high-order bit. This Basic supports PC-compatible files on the micro-SD card, flash memory, ADC, and you can control individual I/O pins. It would allow you to test your hardware very easily and interactively. You'll need a PS/2 keyboard for input.
  • wickedbeernutwickedbeernut Posts: 6
    edited 2012-12-05 23:29
    Excellent information Mike. Thank you. I'll order the C3 tomorrow.


    I had seen the Digital I/O Board Kit. I currently use some rather beefy, solid-state relays mounted on heavy-duty heat sinks for the 1500 W water heater elements and solenoid valves (which tend to have a large inrush current) and Potter-Brumfield IO modules to control the pumps:



    I may consider the Digital I/O Board Kit to eliminate my Potter-Brumfield circuit board and the 7406 hex inverters which drive the SSR's. However, what I'm really after are a few more A/D converters.


    I can live with character graphics. My current recipe and control software uses the DOS text mode which has a resolution of 640 x 350 pixels. An 8 x 9 pixel font gave me 80 columns x 38 rows . You're saying the FemtoBasic VGA display will give me 80 columns x 40 rows with an 8 x 12 pixel font. That's almost identical to what I have. I can live with that. Is it possible to edit the font?


    I certainly like the prospect of saving the recipe files on the micro-SD card. Currently, my recipe files are ~1,600 byte text files. In addition, the state of the entire system is logged to a batch file once every minute.
  • kuronekokuroneko Posts: 3,623
    edited 2012-12-05 23:49
    ... VGA display will give me 80 columns x 40 rows with an 8 x 12 pixel font. That's almost identical to what I have. I can live with that. Is it possible to edit the font?
    Yes. Note that this driver can only change colour on a per line basis. If that's sufficient fine. Otherwise, per-character-colour drivers are available although not yet in 80x40 (100x50/100x75 would be the closest).
  • Mike GreenMike Green Posts: 23,101
    edited 2012-12-06 07:41
    Do consider using GCC C for your program development. Most programs on the Propeller involve some kind of interpreter for execution since the native instructions run in "cogs" that only have 512 x 32-bit words of memory. Spin, for example, has an interpreter that gets loaded automatically from ROM on the chip and executes a compact interpretive code from the Propeller's main (32K byte) memory. GCC C will work the same way, but also has a mode (XMM) where it will execute interpretive code from external EEPROM or RAM built into the C3 board. This slows execution down, but is very well suited for the kind of applications you're talking about where the programs are interactive and use slow peripheral devices (pumps, heaters, solenoids), but may be quite complex due to the interaction.
  • wickedbeernutwickedbeernut Posts: 6
    edited 2012-12-06 09:22
    kuroneko wrote: »
    Yes.

    I assume that's yes I can edit the font?
    kuroneko wrote: »
    Note that this driver can only change colour on a per line basis. If that's sufficient fine. Otherwise, per-character-colour drivers are available although not yet in 80x40 (100x50/100x75 would be the closest).

    I'm not after sexy. My current UI is primarily monochromatic:

    It's hard to tell from this picture, but the valves graphically open/close, pipes/vessels fill with water, pumps turn, propane flames flicker, ... The only color I use is with the water heater elements which turn red. I could depict that differently if necessary (I could make them flash).

    I skimmed through the zip file that Mike referred me to. It looks like I can define "fields" with symbolic names such as TargetTemp, ActualTemp, Action, Comment, ...

    Does it support a basic pop-up window? Here you can see that a "Choice" menu pops up in pressing the F5 key from which a user can select from a list of yeasts:
  • wickedbeernutwickedbeernut Posts: 6
    edited 2012-12-06 09:44
    Mike Green wrote: »
    Do consider using GCC C for your program development.

    I'd be very comfortable using C. The current software is written in C. Of course, I'd like to reuse as much of it as I can.

    I'm not too worried about performance. Remember, the current software is running on an 80286 PC. :smile:

    Here's a description as to how the current control software is structured. This is more information than you'll be interested in, but I thought I'd pass it along none the less ...

    The software is designed as a simple state machine. The state machine is driven by the graphics package. The graphics package continuously calls a keyboard exit function when it is not updating or monitoring the display for input. The keyboard exit function serves as somewhat of an interrupt service routine. With each invocation, the interrupt service routine,
    1. Displays the total elapsed time
    2. Writes the state of the system to a batch file every 60 seconds
    3. Notifies the user in the event the system requires input
    4. Animates the pump and fire graphics
    5. Queries the sparge vessel water and boil vessel wort levels and animates the graphics
    6. Queries the sparge and mash temperatures and updates the display
    7. Turns on the sparge and mash heater element and animates the graphics
    8. Invokes a single step of the state machine
    9. Turns off the sparge and mash heater elements
    The entire brewing process is broken down into a series of 34 steps.
    1. Fill the sparge vessel with dough-in water
      1. Open the sparge water solenoid valve
    2. Have we reached the target dough-in water level?
    3. Dough-in water level reached
      1. Close the sparge water solenoid valve
      2. Turn on the sparge electric heater element
      3. Light the sparge stove
    4. Is the dough-in water temperature within the dough-in water temperature delta?
    5. Dough-in water temperature is within the dough-in water temperature delta
      1. Extinguish the sparge stove
    6. Has the dough-in water temperature reached the target dough-in temperature?
    7. …
    (to be continued)
  • wickedbeernutwickedbeernut Posts: 6
    edited 2012-12-06 09:51
    The state machine is implemented using a case-switch statement. Each step of the brewing process is represented by a case of the case-switch statement. One step of the brewing process (one state of the state machine) is executed every time the keyboard exit function is called.



    switch (step) {


    case 1:



    step_profile = 0;



    valve(SPARGE_VALVE, OPEN);



    progress_indicator("Sparge Vessel Filling With Dough In Water");



    step++;



    break;


    case 2:



    if (sparge_actual_water_level >= sparge_target_water_level) {




    step++;



    };



    break;


    case 3:



    progress_indicator("Dough In Water Level Reached");



    valve(SPARGE_VALVE, CLOSED);



    heater(SPARGE_HEATER, ON);



    progress_indicator("Applying Heat With Sparge Heater Element");



    prompt("Light Sparge Burner");



    burner(SPARGE_BURNER, ON);



    progress_indicator("Applying Heat With Sparge Burner");



    step++;



    break;





    In step 4, you can see that if the sparge (dough-in) water temperature is not within the sparge burner temperature delta (5 ºF), the step is not increased.



    case 4:



    if ((sparge_target_temperature - sparge_actual_temperature) <= SPARGE_BURNER_TEMPERATURE_DELTA) {




    step++;



    };



    break;


    case 5:



    progress_indicator("Within Dough-In Water Temperature Delta");



    prompt("Extinguish Sparge Burner"):



    burner(SPARGE_BURNER, OFF);



    step++;



    break;


    case 6:



    if (sparge_actual_temperature >= sparge_target_temperature) {




    step++;



    };



    break;


    …


    };





    A state may perform a series of actions and then increment the step such that the next state is executed the next time the keyboard exit function is called. A state may involve a decision in which the transition to the next state is conditional (e.g., dough-in water level reached?). A series of consecutive states may form a sub-process which is repeated as part of the entire brewing process. In this case, the step may actually be decremented in order to repeat the sub-process.

    For example, each mash step can be thought of as a series of states,



    case 16:



    if (mash_actual_temperature > mash_target_temperature {



    progress_indicator("Mash Step Temperature Reached");



    progress_indicator("Begin Mash Step");



    start_timer("MASHTARG", mash_time[step_profile]);



    step++;



    };



    break;


    case 17:



    update_timer("MASHACTL", start_time);



    if ((end_time - start_time) / 60.0 >= mash_time[step_profile]) {




    stop_timer("MASHTARG", "MASHACTL", &start_time);




    progress_indicator("Mash Step Complete");




    step++;



    };



    break;


    case 18:



    step_profile++;



    if (step_profile < max_steps) {




    mash_target_temperature = mash_temperature[step_profile];




    progress_indicator("Increase To Mash Step Temperature");




    step -= 2;



    } else {




    progress_indicator("Mash Complete");




    heater(MASH_HEATER, OFF);




    pump(MASH_PUMP, OFF);




    step++;



    };



    break;






    The prompt function: writes the message to the action line and the batch log file; saves the current step; sets the step to IN_PROGRESS (0); and waits for user input. If the interrupt service routine is executed and the step is equal to IN_PROGRESS, the computer beeps. There is no "default" case. With the step set to IN_PROGRESS, the state machine doesn't execute a step. Once the user acknowledges the prompt, the step is restored and the state machine resumes the next time the keyboard exit function is invoked.

    The progress_indicator function writes a message to the progress field and to the batch log file along with a time stamp.
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-12-06 10:18
    Just curious; have you seen BrewTroller? One of my co-workers uses it, but I don't know enough about brewing to see what it does vs your system.
  • Mike GreenMike Green Posts: 23,101
    edited 2012-12-06 10:37
    FemtoBasic wouldn't be suitable for your system other than for testing / experimentation. It's too slow and too limited in terms of program space, variables, etc. It does provide a tool for manipulating hardware and trying out ideas and capabilities and I offered it for that purpose. I think GCC C would be a good implementation platform. The only potential problem would be that I/O drivers have to be rewritten / modified to be incorporated into the library and I'm not sure which VGA display drivers have had this done. I know there are sample programs on the Wiki site that use a low resolution VGA display driver and I think I've heard mention of other, higher resolution drivers being converted from Spin / Assembly, but I don't know where they'd be. You might leave a question on the GCC beta forum about this.

    If you want to use ready-to-go tools, you could certainly convert your program from C to Spin ... it's pretty easy and straightforward and there are all sorts of VGA display drivers as I mentioned along with other I/O drivers that you'd need.
  • kuronekokuroneko Posts: 3,623
    edited 2012-12-06 18:07
    I'm not after sexy. My current UI is primarily monochromatic.
    Fair enough, I was looking at the recipe screen initially which would require more colours per line. And yes, you can edit the font. This is not available for all drivers (some use the ROM font) but the one you probably end up with is fine.
  • wickedbeernutwickedbeernut Posts: 6
    edited 2012-12-06 22:00
    Just curious; have you seen BrewTroller? One of my co-workers uses it, but I don't know enough about brewing to see what it does vs your system.

    I'm pouring over it with a fine-tooth comb. The 20x4 character LCD isn't exactly what I had in mind, but the web interface shows promise,
    live.brewtroller.com

    I like the open source concept. All of the I/O is specifically geared towards a brewing system. They offer some great accessories geared towards microcontroller-controlled brewing systems such as motorized stainless steel ball valves.

    Thanks for the pointer!!! I'll let you know what I decide.
  • GadgetmanGadgetman Posts: 2,436
    edited 2012-12-07 00:23
    I don't drink beer(I'm a teetotaler), and don't know more about brewing than what has been shown on Discovery Channel... which means I really have to add my ideas and opinions...

    1. You have 8 COGs. This means you can have a COG dedicated to temperature control. There may be other parts of the system that can also be split off to live in their own COGs. (The User interface can be split off from the state-machine. Makes for a much cleaner program. There's another reason for splitting them, too)
    2. Get a Spinnerette(Propeller-powered Web-server), connect it to the C3 and have them communicate through a serial link. Set up an unused COG to read off system variables from Shared Memory and pass data to the Spinnerette. You should also be able to adjust the process, just as if you were using the keyboard.
  • MJBMJB Posts: 1,235
    edited 2012-12-07 07:11
    ok - everybody suggests what he likes best.
    so my suggestion would be TACHYON
    - http://forums.parallax.com/showthread.php?141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages&highlight=tachyon
    there you can build your functions bottom up
    the temperature controller can easily run in it's own COG
    and you can use the terminal prompt interactively during development

    And one of the aspects I like very much about TACHYON is that SPIN objects can easily be incorporated into the system,
    should some function be missing ans be easily available inside OBEX.
    (I need to correct this - this is primarily true for PASM Objects, I don't know for sure that SPIN COGS can run in parallel to TACHYON )
    1aK+F4PJ7cBm32CUNiyI2GAAAAAElFTkSuQmCC
  • CircuitsoftCircuitsoft Posts: 1,166
    edited 2012-12-07 08:28
    I'm pouring over it with a fine-tooth comb. The 20x4 character LCD isn't exactly what I had in mind, but the web interface shows promise,
    live.brewtroller.com

    I like the open source concept. All of the I/O is specifically geared towards a brewing system. They offer some great accessories geared towards microcontroller-controlled brewing systems such as motorized stainless steel ball valves.

    Thanks for the pointer!!! I'll let you know what I decide.
    He also said something about it not being as open as it used to be, so I wonder... Either way, good luck. Of course we will all push for a prop-based solution, and I really do think that would make sense for your application.
  • D.PD.P Posts: 790
    edited 2012-12-07 09:34
    MJB wrote: »
    ok - everybody suggests what he likes best.
    so my suggestion would be TACHYON
    - http://forums.parallax.com/showthread.php?141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages&highlight=tachyon
    there you can build your functions bottom up
    the temperature controller can easily run in it's own COG
    and you can use the terminal prompt interactively during development

    And one of the aspects I like very much about TACHYON is that SPIN objects can easily be incorporated into the system,
    should some function be missing ans be easily available inside OBEX.


    Can you give a quick example how this is done?

    you can PM me so I don't thread jack this item here, I'm also a Tachyon fan

    thanks
Sign In or Register to comment.