Trying to replace Biocommand and MFCS-win with Labview

[JWhitaker]

I'm a research assistant at a small biotech company with no experience in Labview.

To brief you on our needs we are currently trying to replace our datalogging scada software with NI Labview. We currently use Biocommand for a bank of 10 Eppendorf/New Brunswick brand Bioreactors (4x Bioflo 110's and 6x Bioflo 115's). We also use MFCS-WIN for a bank of 2 Sartorius brand Bioreactors (Biostat B+ twin units). Contacting NI reps we were confident we could consolidate our datalogging software into one reliable program on one computer versus two different softwares on 4 computers. We currently use the less reliable software to record data points along our experiments for temperature, dissolved oxygen, agitation, etc and to create programs that automate feed ramps, pump timers, and so forth.

I was able to install NI labview onto our best computer but I am having difficulty with it recognizing our reactor consoles. I am aware that there is no real driver support for both of the brands but was told the Labview DSC was simple to configure with our existing modbus and ethernet connections. A serial-to-usb hub consolidates our modbus cables connected to the Bioflo controllers and an ethernet cable connects our Sartorius controllers. Following the directions from related forum posts I surmised I should create a modbus I/O server and create bound variables to read register assignments. I would also need to create some kind of I/O server for the ethernet connection as well, but I don't know which.

While I was able to create a modbus I/O server I am unable to differentiate which I/O items to bind to those variables. I'm basically at a standstill from this step on.

Would greatly appreciate any guidance!

*Also I am using Labview 11

[Benjamin38]

Hi JW - 

It sounds like you have gone through the appropriate steps to set up your I/O Server and selected it to communicate via Modbus.  There is an online document on this as well (linked below) that was written to help with this process.  It may be helpful to run through it quickly and just make sure that all of your bases are covered from when you set up the network.  

Connect LabVIEW to Any PLC Using OPC

In regards to creating bound variables, it sounds like you may just be unfamiliar with the value and data types of Modbus and what they pertain to.  If you open your HELP in LabVIEW and go to the 'Search' tab.  Type in "Using Modbus I/O Servers" and click on the first return.  There is a list below of what the data item terms are and what value representation exists for each.  You will need to know which of this value types are being written by your PLC devices so that you are reading the appropriate data items.  The attachment on this post is a snapshot of the list in that help file.  

After you create a bound variable, expand the project tree down to the Modus I/O Server, then based on those 'Data Item' types, select add on the ones that are relevant to the data from your bioreactors.  

The help file should be able to get you up and running once you have a solid understanding of what data you should be reading from the PLC side of things.

[vikichopda]

hello Sir,

Did you find any to communicate Bioflo reactor with PC? Please reply.

[helcio]

For the Sartorius, you can build a driver either RS-232 or Ethernet using the communication protocol attached.

For the other, it is easier to use an OPC server. All OPC servers  are  able to communicate with RS-485 modbus, and you go from there.

[FermWorks]

Wish we'd seen this earlier so we could have been more help, but for anyone interested now or in future, we have drivers for Sartorius and other biocontrollers and analytical instruments (Applikon, New Brunswick/Eppendorf, YSI, Cedex, SegFlow.....) as part of our process control product, FermWorks, written in LV. Our customers use FermWorks instead of BioCommand, MFCS, etc. in part because they can mix & match hardware from different vendors, & in part because our LabVIEW app is more flexible for developing new control strategies or new displays. We'd be happy to answer questions, email is fwsupport at wireworkswest.com, website is www.fermworks.com.

[wiebe@CARYA]

---

@FermWorks wrote:

Wish we'd seen this earlier so we could have been more help, but for anyone interested now or in future, we have drivers for Sartorius and other biocontrollers and analytical instruments (Applikon, New Brunswick/Eppendorf, YSI, Cedex, SegFlow.....) as part of our process control product, FermWorks, written in LV. Our customers use FermWorks instead of BioCommand, MFCS, etc. in part because they can mix & match hardware from different vendors, & in part because our LabVIEW app is more flexible for developing new control strategies or new displays. We'd be happy to answer questions, email is fwsupport at wireworkswest.com, website is www.fermworks.com.

---

We're at the start of making a BioCommand driver for a customer.

Is your driver available as a standalone driver? What's the pricing, is that for development, run time, etc? Is it source or pw protected or compiled?

There's not much about it on the website.

[FermWorks]

@wiebe we don't sell the NBS driver as a standalone offering, our FermWorks software has several device protocols embedded into the overall EXE.

Do you have a copy of the biocommand protocol reference handy?

[wiebe@CARYA]

---

@FermWorks wrote:

@wiebe we don't sell the NBS driver as a standalone offering, our FermWorks software has several device protocols embedded into the overall EXE.

Do you have a copy of the biocommand protocol reference handy?

---

The one posted earlier in this thread (Re: Trying to replace Biocommand and MFCS-win with Labview) is the only one I found online (one or two other PDFs, but they have images of the manual).

That manual is actually how I found this thread 😄.

We also have a DCU board, a DCU, a DCU VM, a DCU simulator VI and extensive DCU logs, so I think we're good.

The customer wants to release the source open source eventually, so I guess it was a long shot anyway. Just wanted to make sure not to spend the university's money on duplicating a driver.

Thanks for the reply though!