[erlang-questions] Erlang meets physics

Pablo Platt <>
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?

https://github.com/kofron/dripline/blob/master/src/hp8340b.erl#L100

Thanks



----- Original Message -----
From: Jared Kofron <>
To: Pablo Platt <>
Cc: Erlang Questions <>
Sent: Thursday, March 15, 2012 2:32 AM
Subject: Re: [erlang-questions] Erlang meets physics

Hi Pablo-
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.

JK

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?
> 
> Thanks
> 
> 
> 
> 
> ________________________________
> From: Jared Kofron <>
> To: Erlang Questions <> 
> 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
> 
> hp8340b:read(high_frequency_sweeper,<<"cw_freq">>).
> 
> 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.
> 
> JK
> 
> 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 <>
>> To: Jared Kofron <> 
>> Cc: Erlang Questions <> 
>> 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...
>> 
>> Cheers
>> 
>> /Joe
>> 
>> 
>> On Mon, Mar 12, 2012 at 2:34 AM, Jared Kofron <> 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
> have
>>> 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
>>> goals.
>>> 
>>> 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!
>>> 
>>> Jared
> Kofron
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
>> 
>> 
> 
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list