Instrument Control (GPIB, Serial, VISA, IVI)

Showing results for 
Search instead for 
Did you mean: 

Hardware suggestions for a gas mass flow controller

Go to solution

Hello all,

Working on a small project, and the hardware guy ducked out on us, so I'm picking up some of that slack to keep rolling. Wouldn't mind some suggestions from those with experience in this area.


-2 mass flow controllers for nitrogen and butane gases, from 16 psi regulated sources at normal room temperatures, no special ratings really necessary

-Low volume flow into canisters which are open to atmosphere (approximately tens of grams/hour, varies a bit by canister size)

-RS232 or analog input control preferred, but not tied to it, and we haven't bought any control hardware yet

-Device display isn't necessary, wouldn't turn it down though

-Call it a small industrial project. Have some budget, can't throw money at it like crazy though.

-Internal PID control is nice, precalibrated for our gases looks like a nice bonus too.


Our first lead was the various Sierra SmarTrak series, looks like both MKS and Alicat have roughly similar offerings. Any raging success stories with any of those? Deep undying hatred? Other manufacturers I should consider as I drop down the rabbit hole of spec sheets?






0 Kudos
Message 1 of 29

Hello Mark, 


Unfortunately I do not have any experience with the brands and models you are discussing. However, I felt it was important to mention that you should review the NI Drivers Database to check if there are existing instruments drivers already made.


I would first narrow down all of the technical specifications you find relevant and then see what devices in what brands would serve your purpose. After that, I recommend you check the database and see if there are existing drivers for that specific device. I checked and found a few drivers for Gas Mass Flow Controllers, including some from the brands that you mentioned. 


Also, what NI devices are you using? I would like yo know to see if there is more information to pull up more solutions for you.


Have a nice day,


0 Kudos
Message 2 of 29

Hello sebasrasa,

That's good advice for any project, thanks. I did some digging in the technical documents that describe the process requirements, and I think we have flow volume ranges required figured, 33 and 100.5 SCCM are the rough min and max. That's probably the biggest variable when selecting hardware. Premade drivers would be great, the Radwag precision scales it'll also use are already covered for that.


Not sure on NI hardware honestly. They've used USB-6009s, a CRIO, a few 62xx series, and several 3rd party CAN adapters before. I was contemplating an Arduino Mega, for some pretty low speed analog inputs and a fair number of digital outputs that we'll need.


Have fun out there.

0 Kudos
Message 3 of 29
Accepted by topic author markmakeitso

Hey Mark,


Based on this specification alone I think the SmarTrak50 or the SmarTrak 100 from SIERRA, the MF1 from MKS, or the MC 100 sccm to 500 sccm from Alicat could work for you. I would suggest you contact each manufacturer specifically requesting for more information regarding prices and other technical specs. 


For these devices I know that there are existing drivers ready from the Driver Database, so that way you know you can use LabVIEW or MAX to help yourself with the data acquisition. 


I hope this info. helps you.



Sebastián Ramírez Sandí  

Message 4 of 29

Hi Sebastián,

Excellent. I had hoped to get some casual advice here, but you were generous enough to do some good research on my behalf instead. Much appreciated. Will try to guide them towards hardware with existing drivers to save myself some headaches and reduce development time.


Turns out there's a secondary function flow requirement for nitrogen that is much higher than the values above, which might turn into a few extra digital output channels and another MFC, we'll see.


Thanks again for your help, and if I can figure out how to accept your answer for this post I will do so.

0 Kudos
Message 5 of 29

Hi Mark,


I saw this post a little late, but I'd be happy to offer up a VERY BIASED opinion for you (I am a test engineer at Alicat and am the primary person here who updates our LabVIEW code that is available for download on our website). I can't delve into the pros and cons of any other manufacturer's devices, as Alicats are the only ones I have worked extensively with, but I can offer up a response to how the Alciat devices would fit into your checklist:

1) The two gases (N2 and butane) are both on the standard Alicat gas list, where the device has a pre-loaded surface map for temperature and pressure corrections for any selectable gas.

2)  Both of your specified flow rates are well within the operating range of what we can do (likely a single device would be able to work for both, if you prefer switching the selected gas and don't need to run them simultaneously).

3) All devices come standard with RS-232 and analog (0-5 VDC default). The RS-232 implementation is in reality an inverted TTL signal (0-5 VDC instead of -5 to +5 VDC), but in all but the rarest of cases the 232 COM ports today are easily able to communicate with them (usually, the issues I have seen were from customers who needed to make the 232 COM port themselves using circuitry and had level thresholds based on the 232 spec that were not lenient enough for the non-negative voltage ranges). The 232 is also multi-drop, meaning you can connect to multiple devices on a single COM port.

4) Display is there by default.

5) for pricing, contact our application engineering team at or (520) 290-6060.

6) Internal PID is present with user configurable gains (through either the front panel screen or through the serial commands), so you just have to send a setpoint and the device will do the rest.


I'm sure that Sierra and MKS also have good products, so whichever route you wind up going will likely end up serving you well.


Analog vs RS-232 and how it fits into your hardware:

Between 232 and analog, it usually depends on your needs. The analog signal is going to be much faster (Alicat devices update at 1 kHz rate, and I'm sure that Sierra and MKS also update their analog signals quickly), but generally less accurate than the digital output due to things like voltage drop, DAC resolution of the flow controller (Alicat devices currently use a 12 bit DAC for adjusting the analog outputs), signal noise, etc. RS-232 communication speeds depend on the baud rate and the number of data variables being sent. For a baseline, a default Alicat mass flow controller on 19200 baud rate has a data rate that's usually about 30-50 ms between readings (we'll just say 20 Hz for a rough value), which can be increased by removing variables or increasing the baud rate (single variable at 38400 baud rate gets up to ~80-100 Hz).


Added considerations for the 232 vs analog include what hardware you may already have or want to get. 232 COM ports can be quite cheap and I've had good luck with some StarTech USB to RS-232 (9 pin D-SUB) adapters. I think it was a ICUSB2321F from StarTech. If you have a DAQ already and are more comfortable programming for their inputs and outputs, analog is a good choice.


For some added info on the LabVIEW specific details, here's the page for the Alicat LabVIEW drivers: The drivers are all based on VISA read/write commands that simply send command strings over the 232 connection and parse the returns. If you end up going a different route than using LabVIEW, such as an arduino that directly communicates to the devices over a single RS-232 COM port, you can program these string commands in any language but you would need to write the commands and figure out the parsing (I and my colleagues will definitely be here to assist you, but we don't have drivers ready for other programming languages).


End wall of text.


Feel free to let me know if you have any questions, and I will be happy to assist.


Kevin Gudenkauf
Test Engineer
7641 N. Business Park Drive
Tucson, AZ 85743 USA
Phone (520) 290-6060
0 Kudos
Message 6 of 29

Hi Kevin, thanks for your input,


We're still in the requirements stage unfortunately. The plan is to automate a manual flow tube setup that fills carbon canisters used for emissions on small engines. It came up just yesterday that they want to also satisfy a second process document, TP-922 as well as TP-902. So far that doesn't require higher flow rates, but it might require a fourth MFC for conditioned air, as well as a higher flow nitrogen (around 7500 SCCM), and 2 simultaneous MFCs (now 10 to 101 SCCM).


We're definitely locked into LabVIEW for our PC development, but maybe not tied to more NI hardware. An Arduino Mega just gives an easy way to get 15 or 20 digital outputs for flow solenoids, plus some moderate speed analog inputs for a few miscellaneous sensors. Multidrop 232 could be very nice, as otherwise we were looking at a small herd of adapters. Any reasonable response times and TX intervals are probably fine, as these are fairly long, slow processes.


Hopefully we start asking for quotes soon, new hardware in is usually the best part of a project.


This isn't quite a wall of text, sorry. Perhaps a hedgerow?


Thanks again,


0 Kudos
Message 7 of 29

Hi Mark,


Happy to help!


Multiple devices shouldn't be too much of an issue, and the flow rates you specified are all fairly low (Alicat sells products going all the way up to 5000 SLPM, so 7500 SCCM is on the lower side and should be in a range that's fairly easy to work with). I would recommend checking if there are any additional requirements for the devices stated in TP-902 and TP-922. I am wholly unfamiliar with those process documents, but I have run into areas where guidelines or regulations require a certain level of product certification, such as ATEX or CSA ratings for hazardous or explosive zones. It may not be the case for you, but if so there are options of either getting devices that meet these requirements or placing these devices inside of enclosures that do. That said, chances are very good that if these are requirements, you are likely well aware of them.


LabVIEW PC development is usually fairly good as far as drivers go, since many companies provide driver sets to make communication easier. It sounds like the multi-drop 232 could be a good way to attempt, since it would only require a single COM port and should be able to get data rates of about 4 Hz (assuming a data response rate of 50 ms per unit, and 4 units total - since the 232 multidrop requires that only one device is "speaking" on the COM line at a time). The devices themselves would be controlling on a 1 ms internal timing loop. Another bonus would be that if you should find that you do end up wanting to be set up for analog signals, adding more hardware might not bee too big of an issue (though I would recommend settling on whether you want a voltage or current output prior to purchasing your devices). I am not sure what options other companies have for allowing a device to be used for either 232 or voltage/current I/O, so if you are looking to pursue multiple potential paths or to leave your options open that may be a good thing to check when getting quotes.


If you like the idea of RS-232 but prefer other data formats, there are also other options like Modbus if you are more familiar with them. I have had good luck with this Modbus driver library for talking to Modbus devices over RS-232 and RS-485:


Happy hardware hunting! Feel free to let me know if you have any questions, and I will be happy to assist where possible.

Kevin Gudenkauf
Test Engineer
7641 N. Business Park Drive
Tucson, AZ 85743 USA
Phone (520) 290-6060
0 Kudos
Message 8 of 29

Hello Kevin,

I've been working on this project over the last 2 weeks, and we had a meeting yesterday to make some decisions on hardware. Got a few more questions if you're game. I think everything would be fine on the forum, as I'm fairly comfortable flaunting my ignorance in pseudo-public. Okay if I pick your brain a bit more?


Semi-related, is the private message function not working for others? Just me having troubles in both Chrome and Firefox?



0 Kudos
Message 9 of 29

I can't speak to messaging functionality working or not, but I would be happy to offer whatever answers I can. If your questions are more specific to your application or contain any proprietary information and you would prefer to handle them through direct messages, you can reach me at "". Otherwise I'd be happy to answer them here, especially if you think the questions/answers could benefit anyone else looking for similar solutions (with the added benefit that if I don't have a good answer, others can jump in to the rescue).

Kevin Gudenkauf
Test Engineer
7641 N. Business Park Drive
Tucson, AZ 85743 USA
Phone (520) 290-6060
0 Kudos
Message 10 of 29