Experimental Physics and
Industrial Control System

Some comments:

To output things you will use an mmbo rather than an mbbi (?)

I did some experiments on the Raspberry PI, equipped with a PiFace board, that has
8 digital inputs and 8 digital outputs.

The program on the PI is listening on a TCP socket, waiting for commands.
(The usage of TCP/IP is not important here)

I would consider to have an ASCII based command flow instead of sending integers.
You send something like "bc:mtf:setfill=4.8\n" to the device,
and it answers with "OK\n".

Before you attach any EPICS to it, you can use minicom (?) to talk to the device
via a serial channel.
Send the commands from the keyboard, and check what happens in the HW.
Verify that what happens is what should happen.

Try to avoid to split an action into 2 transaction,
like sending "bc:mtf:setfill" first and "4.8" then.

Each action is terminated with a line feed, and either the line can be processesd completely,
or not at all.

Construct the arduino/PI program so that you get an answer for each line, either with "OK\n", or with an error message,
which could be a digit.
Terminate the answer with a "\n" as well.
Doing like this, you can always re-sync in the parser state machine, when something went wrong in the communication.

Having the nice ASCII communication debugged & working, we can take the next step.
Consider using stream device, as Dirk suggested.

This is another example for a protocol file, much more documentation comes with
streamdevice (thanks Dirk)

############
# This is the protocol file for raspberry with PiFace board
Terminator = LF;

setPiFaceBit {
  out "mcp23s17 A \$1 out %{0|1}";
}

#Push buttons pull to ground when pressed
getPiFaceBit {
  out "mcp23s17 B \$1 in";
  in "ok: mcp23s17 \$1 input=%{1|0}";
}




On 27/11/14 18:26, Ryan Pierce wrote:

Thanks, Dirk, for the info!

Sorry if I wasn't clear, but I don't need text strings sent over USB serial to the Arduino. Integers are fine and are probably easier and faster to parse on the Arduino. What Mark suggested using mbbi/mbbo and mapping integers to the strings should be fine.

Now the mention of arguments is interesting here. I'm wondering what EPICS best practices would be to send conceptual commands with arguments? Do you generally set records with the arguments first and then set an mbbi record to command an action?

E.g. if I have a brewing controller "bc" and a mash tun filler "mtf", would best practice be to use an ai record for my set point called bc:mtf:setfill that I'd first set to 4.8, which in and of itself would do nothing, and then have an mbbi record for giving commands called bc:mtf:cmd that I'd set to "StartFill" to begin the filling process? And, say, have an mbbo status record called bc:mtf:status that would transition from "Idle" to "Filling" to "Filled", along with an ao record called bc:mtf:fillvol that I could watch climb from 0 to 4.8?

Thanks again,
Ryan

On 11/24/2014 03:12 AM, Dirk Zimoch wrote:

Hello Ryan,

With StreamDevice, you can format and parse strings (including enums) for devices connected via asyn.

You can write a "protocol file" with commands like this:

fill {
  out "Fill the mash tun with %.1f gallons of water";
}

set_state {
  out "%{Close|Open}";
}

get_state {
  out "state?";
  in "%{Closed|Opening|Open|Closing|Partially Open}";
# be careful with the order of sub strings: "Open" after "Opening" !
}

http://epics.web.psi.ch/software/streamdevice/

Dirk


On 20.11.2014 20:58, Ryan Pierce wrote:

This is probably a really basic question....

The computer controlled brewing project I mentioned on this list a few
months back is coming along quite well. Much of the keg welding and
plumbing is done, and I've made a lot of progress with the control box
that holds the power supplies, relays, Raspberry Pi, Arduino Mega,
status lights, etc. I'm still a long way from actually brewing with it,
as I haven't welded the frame or built out the propane system, but I'd
like to try some integration testing with what I have.

I've been experimenting with async, cmd_response on the Arduino /
Raspberry Pi and have CSS BOY on my laptop. I think I understand how to
use ao records to output temperature, flow rate, fluid levels, etc.

The next task is to model my solenoid valves and motor controlled ball
valves. I'd like to express states, e.g. Open, Closed, Opening, Closing,
  Partially Open, etc. and be able to send commands, e.g. Open, Close,
Nudge Open, Nudge Closed. I also need to send commands with an argument,
e.g. "Fill the mash tun with 4.8 gallons of water" and monitor the progress.

Right now I'd like to display and control this manually in BOY, and
eventually I'd like to learn SNL to set up scripts to automate
frequently used actions.

Does anyone have any suggestions on resources to learn about defining
enums in the db, how they are represented over async, and how to define
command buttons and state indicators in BOY?

Thanks,
Ryan

References:

Defining enums to express state? Ryan Pierce

Re: Defining enums to express state? Dirk Zimoch

Re: Defining enums to express state? Ryan Pierce

Navigate by Date:

Prev: Re: Defining enums to express state? Mark Rivers

Next: Re: usage of CALC Dirk Zimoch

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <2014>  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: Defining enums to express state? Mark Rivers

Next: Incorrect Timestamp in aSubRecord Bruce Hill

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <2014>  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024