Data Acquistion Software Suggestions

[agarb]

I am working on instrumenting a lab process where I need to monitor a bunch of sensors and thermocouples. Can anybody recommend a good data acquisiton package? In the past, I've messed around with data logging and trending on the Allen-Bradley PanelView Plus but it is not flexible enough for this project. The data logging saves everything in one file whereas I need one file per run. I'd also like to give the user the ability to manipulate the ranges on the X & Y axis while the process is running. I also need to provide printouts as well as the ability to export the raw data to an Excel spreadsheet. I think I need to move away from a dedicated HMI to more of a PC-based platform, but I don't really know where to start. Suggestions?

 

[jstolaruk]

If there still is some control involved, you could check out National Instruments LabView. At the very least, check out National Instrument's website, they have a lot of different solutions in the area you are getting into.

 

[agarb]

No control required, only instrumentation.

 

[Oakley]

Take a look at the Yokogawa DAQStation.

 

[mjm]

Try Think-n-Do by Automation Direct. By the needs you stated it sounds like that would work for you.

 

[Joe_WaZoo]

How often do you have to log the values?

Joe_WaZoo

 

[agarb]

How often do you have to log the values?

Joe_WaZoo

Slow, perhaps 1 Hz.

 

[val_99]

I had a good luck with Canary lab historical trending software. It is very similar to Wonderware, allows you to scroll, zoom, configure multiple trends etc. They formed allience with Syteck who is specializing in data reporting software, and you can get all bundle - trend and data reporting software from the same source.

 

[surferb]

You do realize that data will accumulate quickly with that kind of logging rate, depending on how many "a bunch of sensors and thrermocouples" are. ...Looking at "files" is probably off track - you should be using a database. For example, Excel supports just over 18 hours of data at that rate (65k rows). You can expect good performance with 10s of millions of rows in a table of an SQL database. Your application should support dynamic graphing and exporting datasets to Excel (.CSV).

Slow, perhaps 1 Hz.

I am working on instrumenting a lab process where I need to monitor a bunch of sensors and thermocouples. Can anybody recommend a good data acquisiton package? In the past, I've messed around with data logging and trending on the Allen-Bradley PanelView Plus but it is not flexible enough for this project. The data logging saves everything in one file whereas I need one file per run. I'd also like to give the user the ability to manipulate the ranges on the X & Y axis while the process is running. I also need to provide printouts as well as the ability to export the raw data to an Excel spreadsheet. I think I need to move away from a dedicated HMI to more of a PC-based platform, but I don't really know where to start. Suggestions?

 

[agarb]

You do realize that data will accumulate quickly with that kind of logging rate, depending on how many "a bunch of sensors and thrermocouples" are. ...Looking at "files" is probably off track - you should be using a database. For example, Excel supports just over 18 hours of data at that rate (65k rows). You can expect good performance with 10s of millions of rows in a table of an SQL database. Your application should support dynamic graphing and exporting datasets to Excel (.CSV).

I can't imagine a situation where we would need to record much more than about 4 hours of data. There will only be 20-30 sensors. This is a lab type environment, not a continuous manufacturing process.

 

[Joe_WaZoo]

Here is an application I recently worked on where we needed to simply take the 4-20mA reading from all of these Ph probe devices, convert that data into a ASCII string to be sent to a PC and also log the data in the Red Lion Modular Controller unit. With a Compact Flash card in the ModCtrl as our hard drive, this system allows them to determine what the log size will be and often to log. The next phase will be to add the PID loops to this rack. Here is a video of the installation and showing the web interface as well.

ModCtrl Video 1

After this project was up and running, the customer then mentioned that they needed to also take Reletive Humidity and Temp measurements from a work cell away from where the main cabinet was located. For ease on this part of their requirements, I installed a simple wireless node from Banner that has both Rh% and Temp in it with the Gateway feeding that data out over ModbusRTU (485) into the ModCtrl for further logging of the data. Here is a video of that in use.

ModCtrl Video 2

After I installed this wireless node and had it up and running (about 20 minutes time) the electrical contractor who pulled all of the wiring for those Ph probes through conduit asked if they could have easily had those units left closer to where the tanks are located and I could have transmitted the 4-20mA devices back to the ModCtrl wirelessly. Yep, that sure could have been dode that away. Might not have been as cheap as the conduit but it sure wouldn't have taken two weeks to wire it up.

Joe_WaZoo

 

[surferb]

In that case you should be fine writing to individual files.

I can't imagine a situation where we would need to record much more than about 4 hours of data. There will only be 20-30 sensors. This is a lab type environment, not a continuous manufacturing process.

 

[Ken Moore]

Just for the record the latest version of excel is not limited to 65k rows, it is over 2 million. I think they went to true 32 bit on the latest version.

 

[surferb]

OK, fair enough. It's 1 million rows for Excel 2007 according to Microsoft.

That still doesn't make it a good idea. In fact, it's a very bad idea for that sort of application. To name a few reasons: you have a single write lock on the entire file, necessarily use a ton of memory, are subject to corruption, lack concurrency/scalability options, and can't reasonably search/query your data if you have to go to several files.

HMIs of the 90s used flat (text) files - this was a mistake. There are many good reasons why the application you describe needs to be running some sort of database backend. I'm sure any vendor you go with can support this.

Just for the record the latest version of excel is not limited to 65k rows, it is over 2 million. I think they went to true 32 bit on the latest version.

 

[CeCo3]

agarb,

There are many choices out there in the world of data acquisition. I haven't checked out the suggestions offered in the other posts, but I'm sure each one is worth a look and offers some advantage over the others. There may be some inexpensive solutions that will fit your needs completely.

I strongly agree with jstolaruk's suggestion to at least check out the National Instruments website (ni.com). They offer:

• A large selection of instruments; some have fixed I/O, others are configurable/expandable
• A large selection of communication types (USB, wireless, Ethernet, etc.)
• A large selection of I/O and measurement types (RTD, LVDT, digital, analog)
• LabView software

LabView is the meat behind all of these potatoes, so to say. Even the base software package (US$1,295) offers a great graphical interface, simulation, interface with various comms, real-time display, integration with a large number of instruments. If you need to modify your acquisition hardware, LabView Base will very likely support it.

CeCo3