Fast PLC datalogging survey

[treellama]

Hi everyone, long-time reader of the forum, first-time poster.

I have a customer that we've built a number of machines for that would like to do some "high-speed" datalogging. They don't really know how fast they want, but the range we're looking at is 5 sensors (load cells) at 30-100 records/second. Ultimately, the data needs to be saved to a CSV file automatically.

We've tested and proposed a couple of solutions. My favorite so far is making the maximum size (65k) datablock in an S7-1200 PLC and filling it during the test (which gives me almost 30 seconds of data at 100Hz). After the test I can read it out in blocks and save it to the memory card using datalog instructions. At the other end, we looked at National instruments hardware that would be 10 times as fast, but our customer feels more comfortable with a PLC-based approach.

So on to the question: Who else is logging data in a PLC, what hardware are they using? Has anyone run across a similar application, and how fast did they manage to get?

Thanks!
Mike

 

[rdrast]

Are you actually sampling the load cell value at 10ms?
That is very fast for a load cell, and most amplifiers have damping anyway.

 

[harryting]

We had do some very fast logging, not that fast though. My first thought is that PLC is not designed for it. We ruled out using a standard historian right off the bat.

As rdrast said, you really have to investigate whether the data is meaningful by looking at every segment of the data path including the instrument involved at that speed. My 2nd thought is that is the customer know what they are doing asking for data like that in the first place. Most likely, they will need an entirely different setup and specialized instruments and power supply. Heck, AC power in US is 60 Hz.

 

[phuz]

Exactly, a couple things at play here.
Ultimately, if the load cells are not updating at 10ms (equivalent to 100 samples per second) OR the PLC scan time is not 10ms or less, then there is no point in trying to datalog that fast.

If those conditions are valid, then it can be done. I've written several VB.NET applications to do datalogging to a CSV for a customer because they didn't have the need for some higher-end historical software.

 

[boneless]

Hi,

I have used DATALOGGER in the past. You will need to have an OPC server running. I've used it with 100 ms speeds.

I too think that the 1200 series is not suitable for these kind of speeds (except perhaps for HSC).

 

[rdrast]

This is exactly where NI's hardware and LabView shine... They are designed for high speed sampling and processing, but again, the entire system has to support that, not just the final connection.

 

[mk42]

Hi everyone, long-time reader of the forum, first-time poster.

I have a customer that we've built a number of machines for that would like to do some "high-speed" datalogging. They don't really know how fast they want, but the range we're looking at is 5 sensors (load cells) at 30-100 records/second. Ultimately, the data needs to be saved to a CSV file automatically.

We've tested and proposed a couple of solutions. My favorite so far is making the maximum size (65k) datablock in an S7-1200 PLC and filling it during the test (which gives me almost 30 seconds of data at 100Hz). After the test I can read it out in blocks and save it to the memory card using datalog instructions. At the other end, we looked at National instruments hardware that would be 10 times as fast, but our customer feels more comfortable with a PLC-based approach.

So on to the question: Who else is logging data in a PLC, what hardware are they using? Has anyone run across a similar application, and how fast did they manage to get?

Thanks!
Mike

First question, what is the customer using the data for? I bet that most PLC based logging will require some manual intervention on the part of the operator to get the data out. If they want to automatically plug the csv file into a scada system, that might be tricky.

I've seen it done like that with the 1200 before, at least for bursts like you describe. I've never looked into how fast the data log commands can actually pump the data onto the memory card, you might be able to use them directly. If you aren't doing much else, you should easily be able to meet the scan time requirement, and at least the analog cards themselves say they have a conversion time under 1ms. However, as many posters said, you need to check the chain to make sure that everything updates as fast as the customer wants. The trick is that to get it off the 1200, you either need to turn it off to remove the memory card, or pull the data off via the web interface.

If all you're doing is logging the data into a DB, and writing it to the card at your leasiure later, I bet you could easily get down to 1ms from a 1200, if the analog values are actually updated at those speeds. Using a 1500 and ET200SP IO, I think we got at least 10000 samples per channel per second on one project. We weren't trying to export the data, though, just monitor it.

If your customer only needs temporary logging, a traditional PLC is probably fine. You could increase that 30 sec length you mentioned by moving to a bigger 1200 or into a 1500. However, if you want something approaching more or less continuous logging at that high speed, you probably do need some kind of PC based system. If national instruments is too out of the box for your customer, a potential middle ground could be a PC based PLC. Siemens has a soft controller version of both their 300 (WinAC RTX) and 1500 (1500S), and I know beckhoff and many others specialize in PC based systems. You still get to program in ladder logic, but you have the advantages of running on a real windows PC, like a hard drive, and potentially being a file server.

 

[treellama]

Thanks everyone! We've already pushed back on our customer on data rate. Their original request was 500 Hz, but when we pressed them they admitted that they picked that based on the response of the load cell - that and they had some NI hardware laying around for their initial trials. Since they don't know what they really need, the question became "what's the fastest you can do?". Based on what I've seen, I don't think they need more than 30 Hz.

I've found both load cell amplifiers and load-cell input cards that are rated to 100 Hz, although they're not common. It seems most load cell inputs are also typically filtered down below 50/60 Hz because of line noise, so I believe the faster inputs are going to be unfiltered.

In my test, scan time of the S7-1200 was less than a ms.

mk42 - I'll check some of the other similar PLC's to see if the 65k limit was across the board for 1200's/1500's or not. Your 1500 is screaming at 10,000 samples/sec - did I read that right? Thanks for all your comments

boneless - I'll check out datalogger. 100ms isn't bad if my OPC server can update that fast. Softwaretoolbox has always been good to me in the past

Anybody have experience streaming data out with TCP sockets?

 

[mk42]

In my test, scan time of the S7-1200 was less than a ms.

mk42 - I'll check some of the other similar PLC's to see if the 65k limit was across the board for 1200's/1500's or not. Your 1500 is screaming at 10,000 samples/sec - did I read that right? Thanks for all your comments.

Anybody have experience streaming data out with TCP sockets?

I've never checked the limit on the 1200s, but I know in the 1500 that as long as you use optimized type DBs, you can make them as big as the data work memory. You aren't limited to the 65kB like you were in the 300's. I think the biggest 1200 only has about 2x that much work memory anyway, so at worst you could just make a 2nd DB and call it a cyclic buffer

I've never benchmarked TCP comms on the 1200, but when I tried it on a 1516, I was able to stream about 10Mbps using TsendC to a 1516 using TrecvC. One important limitation I ran into is that the Tsend command maxes out at a data buffer of 65KB; it won't compile if it is any bigger. I think it took 50-100ms to send that much data. Again, this was on a fairly fast 1500, I'm not sure how well that carries down to a smaller 1500 or a 1200.

I'm pretty sure that's what the math worked out to, at least 10ksamples. We were using a PN IRT bus cycle of 250 microseconds, and using oversampling to get multiple values from the HS analog card per PN cycle. We processed the IO values in a synchronous OB that ran at the same update rate. We weren't really DOING anything with the data, except to check that the values stayed within a variable window. The rest of the control was relatively slow and straightforward, so the system could handle one small part of the program getting processed over and over blindingly fast.