Brooks controller 0254

[Blokk]

Hello,

This post is the follow up after some discussions about this Brooks product. See the prev discussion here:

http://forums.ni.com/t5/LabVIEW/Mass-flow-controller-with-Labview/m-p/3245250/highlight/true#M945301

That time I promised when I get the 3 flow controllers (GF80) and the Controller unit 0254, I will write about my findings.

The product looks nice, very robust and good quality front panel with push buttons and large display. Got it with serial cable, so I just connected to my laptop, and started to test the system with 3 MFCs connected to the control unit.

I decided to use the provided DLL to control the 3 MFCs via the 0254 unit, and also to read out the flows, the PVs of the MFCs.

I did not like to provided LabVIEW examples (full of flat sequence structures, too crowded, etc), but it gave a good idea how to call the DLL, which parameters I need to use.

I put together a LVLIB including the DLL, a private Action Engine, and public subVIs to perform those tasks which I will need for my experiment. Beside, I made a main VI only for testing purpose, I will run this VI now for several days to see communication stability, etc...I do not have gas lines connected to the flow controllers yet, so now I only test the communication... So far so good. I have attached the project zipped, including the lvlib driver and the test VI (this is ONLY a test VI, I know it is not too pretty 🙂 ).

My experiences so far:

• To read the actual flow values of the 3 MFCs takes about 1.5-1.6 seconds, so I will use just a 2 sec sampling time for DAQ in my real project (in a separate loop, not to disturb/slow down my cDAQ samplings)
• when I started to test the unit 0254 first, my GUI became incredibly unresponsive! I had a look at the DLL configuration, and managed to fix this laggy GUI problem by setting the DLL thread to "any thread" instead of using the UI one.
• If I get later the real flow tests done without problems, I will consider the product as usable. So far it looks like it will work, fingers crossed 🙂

[rolfk]

The Brooks 0254 readout unit has actually a simple RS-232 port to communicate with from the PC. Using the Brooks DLL does seem like a pretty roundabout way of doing business. The serial port protocol is trivial enough to implement entirely in LabVIEW through VISA calls. This is a very simple library which only implements the write setpoint and read current value command, but implementing additional commands according to the two provided ones is really not that difficult. The other commands are described in the Brooks 0254 Installation and Operation Manual.

If you have setup the 0254 in network mode, you would have to provide the unit address. In non-network mode you leave the address input at its default value.

[Blokk]

I decided to use the DLL that time because of the reported problems with the unit using direct VISA operations (see Ben's comments about his necessary workaround solution). But I guess if the DLL just do the same commands, and it works so far, I could just use VISA which would be much straightforward of course...it might be Ben had problem with an older firmware, and the recent one is fixed?
Thanks, I will test your llb!

[Blokk]

rolfk, the llb looks very pro (checksum calculation is required also as I see)! Thanks, I will just test it today, actually these are all the functionalities I need: read flow rate values from three Brooks MFC and change their setpoints...

I have two questions regarding to your code:

• I see there is an "address" input. Why this is an option (by default this is not used in your code) in the llb? I thought this device can only be used with RS232, and not with RS485 (so no multiple devices in a daisy chain, so an address would make sense)?
  Sorry, I read now about the address, it is clear now.

• I wonder about the actual reason of the numeric manipulation on the incoming channel value:
  • In the setpoint subVI you double the channel number value
  • In the Get flow value subVI you double the value and Decremenet with 1. Why?

[rolfk · Accepted solution]

---

@Blokk wrote:

rolfk, the llb looks very pro (checksum calculation is required also as I see)! Thanks, I will just test it today, actually these are all the functionalities I need: read flow rate values from three Brooks MFC and change their setpoints...

I have two questions regarding to your code:

• I see there is an "address" input. Why this is an option (by default this is not used in your code) in the llb? I thought this device can only be used with RS232, and not with RS485 (so no multiple devices in a daisy chain, so an address would make sense)?
  Sorry, I read now about the address, it is clear now.

• I wonder about the actual reason of the numeric manipulation on the incoming channel value:
  • In the setpoint subVI you double the channel number value
  • In the Get flow value subVI you double the value and Decremenet with 1. Why?

---

Point 1: I didn't use the address input in my setup but decided to implement it anyways as it was documented in the manual. Most likely one would need to add it to the Initialize function too, for the Query Identification command. These units can apparently be used in a multidrop setup where they are daisy chained in some ways. Since the customer already had two RS-232 ports through an Ethernet to RS-232 hub, he didn't want to try to set it up in this way and risk extra trouble with wiring and debugging of the units, as multidrop communication generally always incurs.

Point2: If you read the manual it somewhere states that the channel to read a value from a physical channel should be odd, while for writing it needs to be even. Not sure what the logic behind this is, but it sure makes parsing on the device side probably easier as you don't have to parse for a trailing ? for query or a xxxx=nnnnn.ddddd for updating a value but simply take the channel number to decide if you need to read or write. In the end any implementation can be considered logic, as long as it works. 

Basically the channel to use in the command turns out as double the number of the physical channel for writes and one less for reads.

As to the problems Ben mentioned, I did have some trouble in the beginning with this unit and there might actually have been someone from the Brooks distributor here in the Netherlands who did something with the units (possibly a firmware upgrade) but this was quite a few years ago, and my memory about the details is rather fuzzy by now.

We also considered to talk directly to the Brooks MFCs through their RS-485 interface without going through the 0254 unit, but that was eventually dropped mostly because the customer had  already used the 0254 in another setup and wanted some display to verify and manually manipulate the MFCs in case of software failure. Those lab people simply want to have physical knobs to push to feel safe.  Never mind that the menu navigation of the 0254 is a bit awkward to operate. 

[Blokk]

Thanks for the very useful info, it helps a lot! 🙂

[Ben]

---

@rolfk wrote:

---

...

As to the problems Ben mentioned, I did have some trouble in the beginning with this unit and there might actually have been someone from the Brooks distributor here in the Netherlands who did something with the units (possibly a firmware upgrade) but this was quite a few years ago, and my memory about the details is rather fuzzy by now.

....

---

My experience was with the 0254s about 2013.

The issues I saw were;

Query them too often they seem to get lost and forget to reply.

Sometimes I would ask for the flow rate on one port and the 0254 would tellme the flow rate of antoher port.

Problems seldom showed up with short term testing. But run them for hours on end and the hicups would show up. They did try a firmware update back about the time I was working with them, but the frimware upgrade did not help with the problems I was seeing.

As evidenced by the code that blokk had shared from Brooks, the wrong port issues was "coded around" by trying multiple times to get a reeading.

I am just sharing the above so that others can skip to the answer based on what I saw.

Ben

[Blokk]

I am just a small player here, so I might be wrong:

I see there is a checksum calculation in the "BR254 Command.vi". Would this checksum test spawn an error if such malfunction happens what Ben described?? I did not have time to start yet, but I will run the MFCs for several days just to be sure they work OK, during the live experiment a malfunction would cause a big problem...

[rolfk]

I honestly have no idea, what malfunction Ben exactly had. If the message returned is for a different channel than the one requested, but the message itself is legitimate, then no, the checksum will of course not cause an error. If the wrong channel is a result of data corruption on the data link then yes it should be able to catch it. If you see that you do randomly receive channel results for channels that you did not request you would have to add an extra check in the Read Value VI to compare the returned channel number with the requested channel number.

One guess I have is that the wrong returned channel error could have happened if the serial port was not properly flushed when it was opened. That could leave data in the receive buffer and when you then send a command to read a new channel, you in fact read the oldest message in the receive buffer which could be for a different channel. Since we do not use Bytes at Serial Ports (which is anyways the wrong way to go about a protocol with a well defined termination character and a clear command response characteristics), if you forget to flush the port when opening the port you can not guarantee that the next data frame you receive corresponds to the last send command.

[Blokk]

rolfk:

Ben described his problem here, and I also added a screenshot of the DLL example code from Brooks: 

http://forums.ni.com/t5/LabVIEW/Mass-flow-controller-with-Labview/m-p/3244680/highlight/true#M945084

In the screenshot you can see the Brooks programmer made it in a way, the setpoint command on the DLL is checked 3 times whether it is done on the correct MFC channel (or address)???

Anyway, I will do an exhaustive testing run with my rig just to be sure...