Bronkhorst Labview Sample Rate (Hz) Changes

[Exchanging7878]

Hello Dear All,

I am using Bronkhorst El-flow series to control air with the flow-bus system. I have 4 different mass flow controller currently. They obtain data 3 times per second, but I wanna get 10 times per second (10 Hz). I could not see where to change this Hy value in the labview sub vi of bronkhorst.

Could you please let me know how to change it or is it possible?

Sincerely.

[Bob_Schor]

In the year since you've joined the LabVIEW Forum, you appear not to have learned LabVIEW, nor to understand how the LabVIEW Forum works.  If you want a LabVIEW Consultant, please go to LabVIEW Developers Seeking Employment which is part of this Forum.  If you want to learn LabVIEW so you can do your own programming, there are numerous self-learning tools to be found on the Web or the first page of this Forum.

If you want us to help you, provide help to us.  Not all of us know about "Bronkhorst EI-Flow series" -- include a manual.  Post your LabVIEW code (preferably not in LabVIEW 2025, which not every experienced developer is using).

"I could not see where to change this Hy value in the labview sub vi of bronkhorst."  We can't "see" it either -- show us.  What is a "Hy value"?  Attach the "labview sub vi of bronkhorst".  And learn the proper spelling of LabVIEW (capitals setters are important!).

Bob Schor

[altenbach]

---

@Exchanging7878 wrote:

I could not see where to change this Hy value in the labview sub vi of bronkhorst.

---

You should never change anything inside a driver subVI (but if you are sufficiently skilled, you can use it as a template for your own tools).

If changing rate is an option, it should be exposed on the connector pane. Is it?

A rate of 3Hz or 10Hz is quite slow and maybe you are using a simple software timed loop and all you need to change is the loop timing in the toplevel VI.

As has been said, once we see your code, we can give more specific advice.

[rolfk]

The Bronkhorst LabVIEW driver is a simple command response driver. It implements its own low level protocol that packages messages together and sends them over the wire and reads the response. While the Bronkhorst Flowbus protocol supports bulk messages (multiple data elements in one package), the LabVIEW driver they provide does not go to the length necessary to support that (and their binary PROPAR protocol is a bit weird in how it wants such messages formatted).

Basically, there is NO data acquisition timing in those VIs other than how fast your application can repeatedly call the Bronkhorst VIs. If that is not fast enough you have to look at your system.

Is your use of the Bronkhorst VIs optimized?

- No opening and closing of the VISA session over and over again but opening it once and then call the acccording Read VIs to read your MFC values repeatedly until you encounter an error or want to stop.

Basically DON'T do this:

This opens the serial port every time, sends the setpoint, reads the direct value, and then the capacity unit (which really never will change during a session unless you send the according command to use a different unit) and then closes the serial port.

But something along these lines instead:

Each of these VIs creates a message of around 20 bytes, sends it off, waits for a response from the device which is again around 20 bytes and then returns the results to you. At 38400 bauds this amounts to at least 10ms bus transfer time plus the time the device needs to respond, and since the Bronkhorst Flowbus really is a multi drop bus where messages have to travel through every device in each direction this can add up to some time too if you have multiple MFCs.

In addition, opening the COM port each time takes a considerable amount of time too.

You want to both minimize the number of Flowbus commands as much as possible as well as avoid opening the serial port over and over again.

I have written applications with up to 10 MFCs and sample their values with 5 samples per second easily.

I have also considered rewriting their driver to support multi-channel per message transfers and asynchronous operation, but it wasn't necessary to get any of the applications so far running and there are many other things to do that are more important.