[erlang-questions] Erlang meets physics
Thu Mar 15 14:36:11 CET 2012
What I'm asking is how you actually send data over the wire.
How does eprologix_cmdr:send_query/3 works?
----- Original Message -----
From: Jared Kofron <jared.nance@REDACTED>
To: Pablo Platt <pablo.platt@REDACTED>
Cc: Erlang Questions <erlang-questions@REDACTED>
Sent: Thursday, March 15, 2012 2:32 AM
Subject: Re: [erlang-questions] Erlang meets physics
The translation is a simple pattern match - locator_to_ch_data(<<"cw_freq">>) -> "CW", which is then transformed into
the final string which is passed over the wire.
If you'd like to take a look at the code it's at http://github.com/kofron/dripline. It's very very alpha, although deployed
in limited production it works quite well.
Unfortunately my first project, called hmhj, is closed source due to concerns from the SNO+ collaboration.
On Mar 14, 2012, at 8:33 AM, Pablo Platt wrote:
>> which the device module (in this case hp8340b) translates into the GPIB command "OPCW", and based on the
>> device address (which is governed by the atom in the first argument), dispatches it over a bus handle that it owns
>> in a state variable via bus:send_query/2.
> Can you explain how the device module translate to the GPIB command "OPCW"?
> Is it pure erlang?
> Maybe you can share some code?
> From: Jared Kofron <jared.nance@REDACTED>
> To: Erlang Questions <erlang-questions@REDACTED>
> Sent: Wednesday, March 14, 2012 1:43 AM
> Subject: Re: [erlang-questions] Erlang meets physics
> Hi Pablo-
> My first project was on embedded hardware, and basically consisted of NIFs and Webmachine dispatching.
> Pretty fun stuff.
> My current project is a little more involved, but is also pretty interesting:
> Right now the bus over which communication takes place is abstracted away by having hardware modules
> which translate API functions into their appropriate wire representation and then transmit those representations
> over a handle that they have to the correct bus.
> In essence what I've done is taken instruments and buses and given them something like behaviors.
> Hardware can perform read,write,or configure, for example. So if I want to read the center frequency of a sweeper,
> I might say
> which the device module (in this case hp8340b) translates into the GPIB command "OPCW", and based on the
> device address (which is governed by the atom in the first argument), dispatches it over a bus handle that it owns
> in a state variable via bus:send_query/2.
> At the moment, we only communicate with things over GPIB via ethernet using prologix devices to do the translation
> for us - basically glorified telnet - but it gets the job done. Everything is in a very alpha stage right now for this project,
> but it is working really nicely so far.
> On Mar 13, 2012, at 12:20 PM, Pablo Platt wrote:
> How do you interact with the hardware?
>> Do you use GPIB C libr and wrap it with a NIF?
>> From: Joe Armstrong <erlang@REDACTED>
>> To: Jared Kofron <jared.nance@REDACTED>
>> Cc: Erlang Questions <erlang-questions@REDACTED>
>> Sent: Tuesday, March 13, 2012 12:34 PM
>> Subject: Re: [erlang-questions] Erlang meets physics
>> Great news - spread the word !
>> Just for the record Erlang programmers numbers 1 and 2 (ie myself and
>> Robert Virding)
>> are both ex physicists.
>> When I lecture I often point out the similarity between causality and
>> message reception.
>> You don't know that something has happened until you get a message
>> telling that it has happened.
>> (In physics it's a ray of light, or a photon, or something -
>> forgetting entanglement for the moment)
>> In computing it's the reception of a message.
>> As a ex physicist I know that we can't say anything about simultaneous
>> events occurring
>> at different places in space-time - turn this into computer science
>> and the same arguments
>> apply to things like making sure replicated data is consistent on
>> remote sites - well you can't
>> - at least if you want to change it - Brewer's CAP theorem applies -
>> which for a physicist makes
>> perfect sense.
>> Also as an ex physicist
> I realize that things do actually happen in
>> parallel in the real world,
>> so modelling them in a sequential programming language (if I wanted to do that)
>> is big time crazy - just describe the parallel stuff in a concurrent
>> language and the program
>> writes itself. Wait a few years till we have million core computers
>> and the parallel problems
>> can be solved 1:1 on parallel computers - and programming simulations
>> and so on will be
>> really easy - but don't even think about doing it in a sequential language...
>> On Mon, Mar 12, 2012 at 2:34 AM, Jared Kofron <jared.nance@REDACTED> wrote:
>>> Hi All,
>>> I've been using Erlang at work for a few years now, and I thought I'd throw my experience out there, as
>>> my application is a little different than what you usually see on the list - I am a graduate
> student at the
>>> Center for Nuclear Physics and Astrophysics at the University of Washington, and use Erlang extensively
>>> in my work.
>>> In my experience, something that Erlang is really great at but doesn't receive much attention for these days
>>> is managing and interacting with hardware. In any physics experiment of even modest sizes, you wind up
>>> having to keep track of the state of various pieces of equipment, often modify that state, and constantly
>>> interrogate particular values. For example, we might want to change the current in a magnetic trap, turn
>>> that trap off altogether, or simply read back the voltage drop across our superconducting magnet.
>>> So far, I have deployed Erlang in this zone for two separate experiments (SNO+, a large particle physics
>>> experiment in Canada) and Project 8 (a small nuclear physics experiment here in Seattle). Both times
>>> been great successes, and I have found the reception of Erlang in this market to be great. In general, what
>>> I have done is wrap a hardware management layer with some kind of outside world interface. For SNO+, we
>>> used Webmachine and RESTful control, and for Project 8 we actually conduct all communication
>>> by using CouchDB as a message passing interface.
>>> Physicists are suspicious creatures, but once you demonstrate the feature set that you get for practically
>>> free with OTP, they see the advantage pretty quickly. On top of that, the development cycle for sophisticated
>>> applications can be greatly reduced - more than once it made my group float to the top in terms of meeting
>>> In short, as far as I am concerned, Erlang has found a new niche in the world of Physics, and I intend to
>>> spread the word as much as I can!
>>> erlang-questions mailing list
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions