Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [science-iwg] Lab automation tooling

Dear Christian,

 

As Jay says we are working quite a bit on control systems at Diamond Light Source. For instance we are adding developments to the Control Systems Studio product which is a collaboration for large scale control front end, for example we use it driving EPICS. Kay has already given some advice about this which I agree with as far as I am familiar with the subject. We also have a group for data acquisition which combines control with scientific requirements, the group where I work. A third group provides data analysis which is mixed with the acquisition to provide a scientifically relevant front end.

 

There must be synergy with IoT and science groups for controlling hardware and completing higher level science. One possibility might be the recent workflows developments with Triquetrum, perhaps actors could be written for IoT devices?

 

At Diamond Light Source we will shortly propose a new science project to do part of this bridging; called Scanning. This scanning project will provide algorithms for coordinating hardware and visualising scientific results. It will depend on the January project for its data layer. It allows any hardware to the driven, so things like MQTT devices and EPICS motors can be integrated along with a host of detector devices. It incorporates a NeXus writing layer for creating binary data files. NeXus is a self-describing open data format based on HDF5. The files that can be visualized and analysed by many different program DAWN and to some extent ICE do; there are many others. It incorporates a python layer for running the scans and connects to commercially available control devices such as the new Zebra box which combines an FPGA with an ARM processor.

 

I appreciate these things are a bit out of your field. However the group offers a friendly way to discover what people are doing and to learn more.

 

All the best,

 

Matthew Gerring

Diamond Light Source

 

 

 

-----Original Message-----
From: science-iwg-bounces@xxxxxxxxxxx [mailto:science-iwg-bounces@xxxxxxxxxxx] On Behalf Of Benjamin Cabé
Sent: 30 April 2016 15:38
To: Science Industry Working Group; kura-dev@xxxxxxxxxxx; jconlon@xxxxxxxxxxxx
Subject: Re: [science-iwg] Lab automation tooling

 

FWIW the Eclipse Kura IoT project is currently looking at leveraging WireAdmin to do exactly what you described :) They call it "Kura Wires"

The idea is to use WireAdmin on top of the existing many services that Kura includes for accessing a system’s GPIOs, communicating using IoT and Industrial protocols, configuring components, etc.

My understanding is that it’s available in a branch of the project right now, but they are working on documenting what’s there so that people can give it a try.

 

See https://github.com/eclipse/kura/issues?q=is%3Aissue+is%3Aopen+label%3AWires

I’ve also cross-posted to the developer mailing list of the project.

 

Benjamin –

 

 

 

Le 30/04/2016 16:27, « John E. Conlon » <science-iwg-bounces@xxxxxxxxxxx au nom de jconlon@xxxxxxxxxxxx> a écrit :

 

>One should also consider the OSGi WireAdmin specification.  It is a DAG

>Dataflow programming model and was intended for devices, sensors and

>actuators (aka IoT).  It has been astonishing to me with all the talk

>of IoT, that very few people have noticed this important specification

>and implementation.  OSGi Components utilizing  WireAdmin, ConfigAdmin,

>MonitorAdmin and Declarative OSGi services make very nice decoupled

>plugins that can be wired together by the user to create DAG dataflows.

>   With these existing implementations and a simple controller to do

>the wiring I successfully implemented a lab automation project and

>other sensor/actuator projects.  Have this working within an RCP or in

>a standalone Server.  The RCP based implementation utilized a Zest

>viewer to visualize the DAG and the statistics generated from the different

>plugins.   For a lark I called it the Information Router aka - iRouter.

> 

>If there is an interest I would be happy to make the source code

>available.  Again this is mostly pure OSGi.

> 

>As a counter argument I am looking at the Apache NiFi which also uses a

>DAG Dataflow model - and unlike my iRouter and WireAdmin currently has

>a very big user community.

> 

> 

> 

>John

> 

>--

>{ name     : "John Conlon",

>   title    : "Principal Consultant",

>   phone    : "(608)620-4938 x100",

>   cell     : "(608)620-8867",

>   email    : "jconlon@xxxxxxxxxxxx",

>   web   : "http://www.verticon.com"}

> 

> 

>On 04/30/2016 06:15 AM, Kasemir, Kay wrote:

>> Hi:

>> 

>> As has been mentioned, integration is often necessary before you get to control and automation.

>> As soon as you have more than one device type you tend to have more than one vendor-specific bus or network protocol.

>> 

>> Natl.Instr.’s Data Sockets, IoT’s MQTT, EPICS’ Channel Access, Tango’s Corba-based protocol are all efforts to get to a common network protocol on which you can then base your control and automation. Which one is best for your lab automation depends on several factors.

>> 

>> NI’s Data Sockets basically defines which data goes via the TCP pipe. You could do a similar thing with Google protobufs. Your network clients directly connect to your network servers. That can be all you need if your control system stays within a room.

>> 

>> MQTT, JMS/Apache MQ, .. add a broker. That can be nice for home automation. Use some public broker in the cloud, and now you can control your fish tank and garage door via your cell phone from anywhere.

>> 

>> On the downside, a broker is a bottleneck on your data rates. A public broker could invite network attacks. Or imagine yourself in the driveway, within sight of the garage door, but to open it you need to reach a broker in the cloud, which right now is not accessible because of a pickup at your ISP. For plant automation you’ll thus prefer a local cluster of redundant & load-sharing brokers. JMS/Apache MQ can do that. EPICS’ Channel Access on the other hand does away with a broker. Clients dynamically locate their servers and then connect directly.

>> 

>> All of these approaches have their pros and cons, so you best look around for a little while, and then pick what suits you best.

>> 

>> -Kay

>> _______________________________________________

>> science-iwg mailing list

>> science-iwg@xxxxxxxxxxx

>> To change your delivery options, retrieve your password, or

>> unsubscribe from this list, visit

>> https://dev.eclipse.org/mailman/listinfo/science-iwg

>> 

> 

> 

> 

>_______________________________________________

>science-iwg mailing list

>science-iwg@xxxxxxxxxxx

>To change your delivery options, retrieve your password, or unsubscribe

>from this list, visit

>https://dev.eclipse.org/mailman/listinfo/science-iwg

 

_______________________________________________

science-iwg mailing list

science-iwg@xxxxxxxxxxx

To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/science-iwg

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 


Back to the top