Re: Defining enums to express state?

[Torsten Bögershausen <torsten.bogershausen@esss.se>]

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