Data logging from a plc

Hello,

I've been looking for a simple way to log some data, and I was just wondering if someone might know of a better solution than what I've come up with.

We'd like to log 4 tags from a plc (possibly more later) while a trial is running, at 10 samples/s for each tag, although we could probably work with 5 S/s. We'd want an individual file of data for each trial. Trials are only about a minute long, and will be run on demand, maybe 10 a day maximum. Ideally the log file would be readily readable by Excel (.csv), although other forms are acceptable as long as they can be converted to .csv. The ability to access log files remotely would be nice but not a requirement.

The system is an automated hydraulic press that will have a plc. I'm probably going to get an Automation Direct Productivity3000 for the plc.

I'm not really interested in anything that would require a dedicated connection to a pc. I don't see how that would fit in with their shop setup, plus I expect that to possibly be a steep learning curve for me.

I would have expected this to have a simple solution, but I haven't been able to find one (I've tried searching this forum). So far the best I've come up with is to get a Measurement Computing LGR-5325 logger, and retransmit all of the data from the plc through its analog outputs. This should get the job done, but it seems a little overkill in speed, performance, and price ($1500, plus an analog card for the plc), plus it appears each file needs to be individually converted. I'll go with this unless I can find something better shortly.

I've also looked into the Red Lion Data Station Plus (which I found from this forum), but it appears that there is no way to ensure that there is one log file per trial (I'm actually now waiting for confirmation from the salesman about this), plus the sample rates are listed at only 1 sample/second (the salesman said this can be "hacked" to go 5 samples/second, but this makes me wary). This would have been nice because it could log directly to .csv, plus it could allow remote access to the log files.

Anyway, thanks to anyone taking the time to read this!
Matt

Not an expert on AD's controllers, but taking a quick look at the website, it appears that you can attach a USB stick to the Productivity3000. It'd be csv, but if you're looking for simple, that may be the way to go.

Jordan, thanks for responding.
I didn't mention in my post but I spoke with an AD tech about that feature, and it has pretty much the same issues that the Red Lion has - inability to control file creation (limited to once per hour, per day, etc.), and it can't update faster than once per second.

I think that a workaround for the update rate issue would be to buffer data. Then I could store data in, say, 10 tags for 1 pressure value, each one offset by 100 ms. Then I'd have it log all 10 tags each second. But I don't know if this could be coordinated well enough to avoid skipping or duplicating values, plus it would require some extra formatting in Excel, and there's still the file creation issue.

You can roll your own logging with Crimson 3.0 to overcome the limitations you mentioned, or parse the "normal" log files to split up the data to your liking.

The sample rate is high enough that you would do well to buffer the data in the PLC (10 tags, sampled every 0.2 seconds, right?).

A communication channel should be able to handle the rate just fine, but there will be some dithering (not sure if that is the best word) of the time between samples and that may affect the overall outcome.

Catch the data in the PLC and log it once per second (or slower) with whichever tool you choose.

Okie beat me to it, but buffering would definitely be the way to go for this (I read 10 samples/sec.). PLCs and PACs generally have enough memory in them that you could buffer the entire test.

I was trying to think if anything external would be quick enough to handle it, but I keep thinking "no, probably not 100% of the time". I think that there would be something getting lost in the shuffle.

Feeding the data out at a slower rate is a great idea. The only caveat I can think of is the elapsed time between tests. You don't want to accidentally overwrite your buffer if the old data hasn't been written out yet... not that I've ever done anything like that...

Okie, thanks for responding.

I have 4 tags now to log. The 10 tags I mentioned were in regard to buffering one of these at 10 Hz, so if I were to buffer, that would mean 4x10=40 tags (or 4x5=20 tags at 5 Hz) to log each second.

I'm not sure what you mean by "roll your own logging". It still seems to me that Crimson will create files either:

(a) When a certain size is reached, if Update Type is set to Triggered Snapshot. It looks like this would mean that we'd get a new data file at strange intervals, maybe every 3.5 trials.

(b) At a regular interval, when Update Type is set to Continuous Sample. The problem with this would be that they also wouldn't correspond to trials, plus it looks like it would generate lots of files with meaningless data when not in use. By "parse" did you mean look for good data in these files? It seems like that could get to be pretty tedious.

Jordan, I just noticed your post.
Regarding your point about overwriting data, I'm thinking that if the buffer is updated every .1 seconds in a first-in first-out manner, then it wouldn't be too terrible if the logging interval were off only slightly and occasionally - it seems the worst would be some duplicates readings and some skips. But I don't know how frequent or severe these errors would be without trying. This is what makes me wary about this approach.

Maybe Kepware opc is the answer, it has the ability to log to SQL and use triggers generated in the plc.
So for example normal plc comms would not be fast enough as the data you need to log possibly grows (add more logging).
So in the plc move the samples into a word shift then when you have the samples i.e. 10 Block move these to another area then set an internal memory (Flag) this is the trigger for the kepware SQL logger to store the variables to an SQL DB.

Example
shift analog into a shift register at the rate required i.e. 1 second
after 10 seconds you will have 10 readings in the 10 words of the shift register , move these into a scratch area (another 10 registers) and these would be continuously read by the opc server then set an internal bit to 1 when the opc server reads the bit it will log the 10 words to DB
this way you have 10 seconds again before the next shift to log the data.
so rather than read a value every second & log it you now only have to read the data every 10 seconds, not ideal if you want time stamps for every bit of data but if the data is populated in the DB like 20/05/2013 14:30:00, Val 1, Val 2, Val 3 etc.
and you know the time between data i.e. 1 second then you could work out that val 1 would have a time stamp of 20/05/2013 14:29:50 and Val 10 the timestamp of 14:30:00 (or very close).
Not sure of the cost for the Datalogging on Kepserver but the driver license is around £500-700 & assume a similar price for the datalogging, the only other thing you need is a pc with SQLServer Express (Free from Microsoft) and Excel with vba to create queries from the database.
I have done similar systems but not used kepserver Datalog I use VB to create a client for the opc server and log the data to an SQL server, The production staff have automated spreadsheet templates to read the data into excel.

I was thinking in terms of an array (or set of arrays) in the PLC large enough to store the entire test, along with something like Ignition or Kepware Datalog, or Crimson to log the data for you.

Currently, I have an application on an Omron CJ series that has a ring buffer of 100 arrays of 100 integers (Omron's memory map isn't really divisible in those terms I use it for illustration.). There are two processes. One puts data into the ring buffer, the other pulls data back out. The buffer is large enough that, should comms go down for whatever reason, there is enough time to restore operation without loss of data. Data is pulled out of the buffer and into a scratch area where the datalogging action takes place, with whatever package you decide to run with.

However you decide to go, I'd suggest one more datapoint with a "serial number" of the test. That should help delineate one test from another.

Hi,

PeakHMI can easily log many points 10 times a seconds without issue. Our ODBC logger has a lower limit of 100 milliseconds. There can be multiple "loggers."

The question is fetching the data from the external device.

Ethernet, not a problem, 1200 baud serial, depending on the data fetch size, it can be a problem.

Device internal speed could be an issue. For example, the device only handles external communications, one request per scan, at the end of the scan and the internal scan is very long.

Parky, Jordan, Mark, I appreciate the input.

Our company doesn't have an always-on pc currently at this shop that could be used in this way. We just have an operator that brings in his laptob each day & connects to wi-fi. So, we'd either have to add a dedicated pc for this or have the operator set up his laptop for data retrieval each time, and I'm not comfortable recommending either option.

Aside from that, setting up a network with SQL strikes me as intimidating (I really do need to learn how to do it at some point). I've really never worked with databases.

Hi,

PeakHMI can log to Excel or Access, an SQL database is not needed, it is an option, really any database/program with an ODBC driver can be used. Excel and Acess both have ODBC drivers.

It seems lots of people shy away from SQL but installing SQLExpress on a local pc & creating a DB is easy, I had never worked with SQL before but found it relativity easy.
Within a few hours of my first play with SQL I was writing queries & populating databases, there are a few pitfalls these being date/time conversions but just google it & in no time you should be able to do it.

Anyway enough about that most HMI's can log in csv format so the main problem is getting the data in the time frame, storing it in the plc registers seems the way to go then trigger a write to a csv file (depends on HMI of course).

Hi,
You could use PLC Reports http://www.plcreports.com . As far as I understand your demand, it’s doing exactly what you want. I use it‘s Batch Report functionality for this. You can use a bit in the PLC which is monitored by PLCReports. If the bit is true, the logging begins. If the bit goes to false, it creates either an Excel or PDF report. You can decide where to store the file. If you have for instance 100 values per seconds you can write them into a db and read it with an Array Variable of PLC Reports and transfer it to Excel.
Hope this helps