Control System Library in Go

[arrow]

I have started a control system library (goctrl) in go (http://
github.com/Arrow/GoCtrl). I am not a computer scientist (mechanical
engineer) but in my work I do need to program (mostly in c, albeit
very basic). I'd hope some of the developers on the mailing list would
have some input into how I have structured the library so far as I
know I have lots to improve upon.

The basic ideas for this library were to create two basic structures
(Src and Snk) with associated methods(Source() and Sink() ) and
interfaces (Sourcer and Sinker) that allow custom structures to be
linked together. By source, I'm defining it as a structure that will
furnish a chan float64 that continuously sends values over this
channel, to be received by a sink. I have created a few test structs
using these basics in order to try creating a basic model (RateModel)
and a proportional controller (P_Controller). I have added a few other
functions for stuff like user input, outputting a result over a
netchan and multiplexing a connection, but I wanted to see what others
thought before doing too much more work.

Thanks for any feedback.

[Cory Mainwaring]

I might suggest some comments in your code, as it's currently rather hard to get a quick grasp of what's going on in the code.

[Andrew Gerrand]

Hi there,

The code is quite readable and clean. :-)

But I think you are overcomplicating things with the interfaces.
You're always passing things around with chan int64, so rather than
using interfaces with methods that return a chan int64, why not just
pass around the actual channels? You could even give the channel a
type for clarity, eg:

type SignalChan chan int64

I'm also curious as to why you have the Sinker create the channel. I
would have thought a Source would be more appropriate for this. But
better than either, it would be nice to create the channel independent
of the sources and sinks, that way you can attach any number of each
to either end.

Andrew

[arrow]

I already had that on my todo list. It's one of the main reasons I
tried to explain what I was doing in my original post instead of just
saying here it is, what do you think. Email me if you think there is
anything in particular that I should explain right off start and I'll
prioritize that. I also want to add more to the README so that
everyone can start from there.

On Jul 22, 9:40 pm, Cory Mainwaring <olre...@gmail.com> wrote:
> I might suggest some comments in your code, as it's currently rather hard to
> get a quick grasp of what's going on in the code.
>

[arrow]

The idea behind the Sinker/Sourcer interfaces was that someone writing
their own code could add a custom controller by embedding the Src and
Snk structs. I was trying to make it easy to have a set of functions
like "connect" that will allow me to connect different components
together. I don't think I'd want only one channel since I want to be
able to connect them in a logical manner (eg PID controller -> Motor
Model -> Car Speed Model). Basically I'm trying to leave it open to
many different modelling and simulation functions as well as control
system code.

The Src and Snk types are close to SignalChan. I was considering using
this instead of the struct declaration, but I was just trying to get
it to work and it seemed the easiest way to try it out. That's not to
say I wouldn't want to change it.

As for Sinker creating the channel, my logic was that an output of a
component could be multiplexed to multiple places, whereas the input
should be coming from one place or likely have specific input
requirements (eg PID input vs time step input for I & D). There would
possibly be cases like an adder function (that could accept 1 - n
inputs) but that seemed a bit more specific.

BTW, thank you very much for all the feedback. I've been checking back
to see if there was anyone looking at this, but I was not expecting so
much feedback so quickly! I really appriciate it.




On Jul 22, 9:51 pm, Andrew Gerrand <a...@golang.org> wrote:

[Daniel T]

This is a cool idea and utilization of Go! Graduated with a ME, but
doing DB App programming right now. This would be sooo much terser
and easier to use then ladder logic or the newer PLC language
strains. This does seem like it would make hooking up a PID or other
feedback loops.

I wonder how if it would be good to verify that a source or sink has
received data in the last X, and if not send a msg on an alarm
channel, maybe using time.Ticker to verify a time stamp. That would
mainly be for the net chans, but could also be used to verify there
isn't a dead lock or just a dead i/o.

It's often hard to know what a problem looks like until you dive into
it, but my impression is that this would be a very good application of
goroutines and channels. My main interest in Go has been driven that
it could be used as a controller on very little hardware or supporting
software (bare OS kernel, bare bones). Maybe I'll pull out my
controls book :)

[roger peppe]

On 23 July 2010 03:11, arrow <bloggi...@gmail.com> wrote:
> As for Sinker creating the channel, my logic was that an output of a
> component could be multiplexed to multiple places, whereas the input
> should be coming from one place or likely have specific input
> requirements

i'm not sure that works. if the Sink is creating the channel,
then that channel can be passed to multiple Sources
(i.e. multiple outputs can multiplex onto a single input),
but a Source can be connected to a single destination only.

i do think your current scheme works well, however: channels
manage fan-in automatically, but if multiple sources are
reading from the same channel, they each get a subset
of the values sent down the channel, which is rarely what
you want.