At Bronkhorst High-Tech (BHT) we design and manufacture mass flow controllers. To get an idea of what that is: it’s a device about the size of your hand which can measure and control gases or liquids flowing through the device. They are used in a wide variety of laboratory and industrial applications, such as coating machines for the automotive industry, mixture installations in the food industry and all kind of university projects. Throughout this article I will use “instrument” to indicate our hardware products.
All our instruments support several bus protocols, including Modbus, EtherCAT®, DeviceNetTM and FLOW-BUS. The latter protocol is designed by Bronkhorst and is used by our customers as well as BHT in the manufacturing process (in a slightly different form). All our instruments understand FLOW-BUS, the other protocols are optional. To communicate with the instrument we developed a .NET 4.0 assembly that can talk FLOW-BUS and runs on desktop PC’s throughout the company.
There are a couple of problems/limitations that we’re running into lately:
- There is no way a service engineer can easily configure an instrument on-site. He will always need to have a PC or laptop around, which is inconvenient to say the least.
- We have no option to remotely control an instrument
- To control multiple sets (physically at one workspace) we need multiple PC’s
We could do better…
What if we could build a small device that could talk FLOW-BUS with an instrument and expose it through a web API. This would enable a service engineer to quickly analyze and fix an instrument on-site and enable us to control instruments remotely and reduce the number of PC’s. There should be two form-factors.
Mini-adapter (on-site usage)
The size of a credit card which fits in your pocket and contains WiFi for connectivity to any device. This form factor should have one COM port for the instrument.
Communication-box (internal usage)
The size of a media box with a LAN port and multiple COM or USB ports.
We had a few brainstorm sessions and came across the .NET Micro Framework (NETMF). All our software is based on Microsoft technology and mostly .NET these days. As a small development team (about 5 people) it would be very efficient to use our current knowledge of .NET and its software tools. After a bit more investigation we were confident that we could build a NETMF device with the following requirements:
- Talk the FLOW-BUS protocol
- Host a small web application for demo purposes
- Use any WiFi enabled device to access the web application
The hardware setup
Our setup includes the following components:
- Netduino Plus 2
- RS232 shield
- Linksys E1200 wireless router
- BHT instruments (controller and a meter)
- IFI (Instrument FLOW-BUS Interface)
Our hookup diagram:
Depicted the software architecture of our POC software. Each assembly has a different color. A small description for each component:
A tiny NETMF webserver implementation hosted on Github and created by Fredrik Rinsén.
A web controller to read and write FLOW-BUS parameters.
Reads a couple of different measure parameters which will show up in the chart on the demo site.
A lightweight version of our FLOW-BUS protocol.
Provides the streams from and to the serial port.
When the netduino is powered on it will scan the FLOW-BUS network and read a couple of basic parameters for each found instrument (e.g. serial number). The ParameterPoller and the webserver will start their loop and the device will be ready to respond to a web request.
A user can use any WiFi enabled device to connect to the access point and open a browser to a predefined IP. The web application will load and start polling some measure parameters for the instruments. The result is written in a Chart.js line chart.
To start with, it’s been a lot of fun! I’ve never really played with software this close to hardware, but I like it. I also think that this is the perfect time for software engineers to start playing around with IoT devices, because the software tools are improving every day.
If NETMF 4.4 will provide us a reliable TCP/IP stack (it has some known stability issues) we will extend the POC and focus on reliability and performance. If that turns out well, we will ask a hardware company to design the “mini-adapter” form factor based on the netduino (thanks to the open-source blue print!).