Brooks controller 0254

[rolfk]

Not having read the manual about this function I'm not sure what the return value of 1 would mean, but it would seem a bit strange that a return value of 1 means that the message was acknowledged for the right channel. It would seem more likely that the return value of 1 indicates success and 0 indicates failure.

So it doesn't really necessarily have to do with the error that Ben mentions. Maybe the DLL does check the return message to be about the correct channel, but more likely it simply indicates an error when the message wasn't acknowledged, or with a CRC error. Programming something like that in a chain is however a bit amateuristic. It's obviously a repetitive operation with an abortion criteria (no error OR max number of retries has occurred) and such an operation is best implemented using a ...... indeed: while loop! 

The communication being serial and possibly over long cables has of course a certain chance for communication errors. Attempting to catch that by retrying the operation in case of any failure isn't that special for industrial control systems. Of course for many lab situations this seems rather unneccessary and indicative of bad devices, but reality is that in a typical industrial environment you have to live with many electromagnetic and, high dynamic current induced noise signals, that will easily jam a serial port application occasionally. Doing an automatic retry on error can make the difference between a working system and a pile of hardware crap!

In my setup I didn't really see any indication of wrongly returned channels nor frequent CRC or no acknowledge message situations. I have however to mention that the system that I had implemented was similar to the CVT Framework that NI provides, but the individual IO servers that are implemented as deamon will only update the values in the CVT if the read command did executed successful. If there was an error like a CRC error the deamon will not overwrite the last value but change the status attribute for that channel to indicate an error condition. While that error can be queried in the detailed system overview it is not typically visualized in the normal process diagram screen.

On the other hand wrong readings from the wrong channel would result in pretty eratic history graphs for particular channels and that is defininitely not something I had ever noticed on those systems. Considering that the main work on that system was around 2011 and some extension in 2012 and 2013, I'm pretty sure that those units had the same firmware or even earlier one than what Ben was working with.

[Ben]

I should share a liltte more info about the issues I was facing.

1) We were using a single 0254 to support multiple MCFs.

2) I was hammering the 0254's for updates at about 10 updates a second. The error rate seemed to depend on how often I was querying the 0254s.

3) No signs of comm errors were noted. We were using very short serial cables and NI- USB-Serial converters.

4) Error largly were of two types, wrong unit (port 3 instead of port 5 for example) info returned when queying the flow rates AND no reply at all.

5) I saw the problem with multiple 0254s. I tested one at my desk with my built-in serial port of my PC.

6) we deployed the application and 0254s to five different fume hoods and all showed the same issues.

7) Verifying the correct port number in the reply package was used to indicate if the query should be retried and seemed to be a valid work-around.

I am not trying to state that Brooks 0254s are buggy now or will not work under less demanding applciations. I am only saying that the returned messages should be double checked (very the proper port number) if you suspect soemthing weird is happening.

Again just trying to help other "bloody their nose while running into a tree in the dark."

Ben 

[Blokk]

Hello!

I would like to give an update about the Brooks 0254 controller for future readers who find this forum posts. Now we are using the 0254 controller for a while, connected to 3 MFCs. I use the Brooks provided DLL to communicate with the device via RS232. It works fine, very rarely I experienced that, sometimes a new setpoint request was not executed. But this happened just a couple of time through months. And executing the new setpoint once more always fixed the problem, the MFC acted as required, so not a real issue, easy to program around...

Another reason of this update-post is that, I am recently building another experimental rig, and I will need to control a single Brooks GF80 MFC, but we do not want to buy the 0254 controller to save money (and only for a single MFC would be too much). I will order a GF80 MFC with both analogue/RS485 interface options. I would like to communicate digitally (so i do not need an analogue I/O unit as an extra hardware) with the MFC.

I have just found that Brooks give LV driver VIs also for RS485 S-protocol (also DLL based, for LV 32 and 64 bit versions):

https://www.brooksinstrument.com/en/products/accessories-software/product-software/brooks-labview-dl...

So I will try the direct RS485 communication between PC and the GF80 MFC using these VIs and the provided DLL. I will report back about my findings...

[Gregory]

I have been playing around with the serial commands through Rolf's VISA-based drivers. The Brooks 0254 is connected through a USB-serial converter and the computer is Windows 10. I have been noticing that my execution often gets hung up on the VISA read, much longer than the 10 second timeout. The only way to stop the VI is by closing LabVIEW through the task manager. After that, I am locked out of the serial port. If I use a telephony app like TeraTerm it says "access is denied". The only way I have found to reset stuff is to restart the computer. Has anyone else seen this before?

[rolfk]

That sounds like the USB COMM implementation of the USB serial converter might be not quite fully standard compliant. Try with a different converter, preferably a real FTDI based one even if it costs a few bucks more than the cheap chinese counterfeit ones. Saving money on this device for any setup that even remotely resembles an industrial application is definitely the wrong thing to do.

It sounds like the controller on the converter gets stuck somehow and is not responding to the standard Windows device driver queries anymore and the Windows device driver is not prepared to deal with such behaviour.

[Blokk]

At my previous workplace, they still use such controller 0254 at one experiment, which I built for them. I use the Brooks provided DLL to access functions, and it works OK, only with some little bugs. Namely, sometimes the controller does not perform the requested flow rate change, but I programmed this error around, and a second command send always fixes this issue.

Otherwise no problem with the serial communication between PC and the controller (we use a brand usb-serial converter with FTDI chipset, and disabled all Windows related energy saving options in device manager, which might cause issues). 

[Gregory]

---

@rolfk wrote:

That sounds like the USB COMM implementation of the USB serial converter might be not quite fully standard compliant. Try with a different converter, preferably a real FTDI based one even if it costs a few bucks more than the cheap chinese counterfeit ones. Saving money on this device for any setup that even remotely resembles an industrial application is definitely the wrong thing to do.

It sounds like the controller on the converter gets stuck somehow and is not responding to the standard Windows device driver queries anymore and the Windows device driver is not prepared to deal with such behaviour.

---

Ok, great, thank you for the suggestions. I could not find anything about FTDI chipset on the product page for mine. I will try a different adapter out, thanks!

[Ben]

HI Gregory,

You may have seen what I posted earlier in this thread about the issue I had seen with the 0254's but incase you skimmed over that, please take another look.

In short you can make the 0254s work but you also have to double check that they accept the commands and give you what you actually asked for. And do not hammer them hard because they do not much like having to handle a lot of I/O.

Ben

[Gregory]

Hi Ben,

Thanks for your comment. For this application I do need to read the flow from 2 channels at around 1 time per second. I have employed a trick which I use for some less than stellar serial interfaces, where I wait for the bytes at port to reach a steady state before attempting to read the bytes. So far this has helped with the Brooks 0254, but I'd still like to try a different adapter or direct connection to the computer when I get a chance.

[Ben]

---

@Gregory wrote:

Hi Ben,

Thanks for your comment. For this application I do need to read the flow from 2 channels at around 1 time per second. I have employed a trick which I use for some less than stellar serial interfaces, where I wait for the bytes at port to reach a steady state before attempting to read the bytes. So far this has helped with the Brooks 0254, but I'd still like to try a different adapter or direct connection to the computer when I get a chance.

---

I believe that approach should work BUT...

If you ask the 0254 for channel #2, check the response to make sure it replied with channel #2.

Ben