High speed data acquisition

Nearbyatom

Member
Join Date
Jul 2017
Location
USA
Posts
38
I have an application that requires high speed data acquisition. We are looking to capture data once every 10-20mS. This is for edge computing so once we collect this data, we need to analyze it, and act on it if necessary. Every X minutes (we are talking 10minutes), our modem will poll the PLC and push ALL that data out to the azure cloud.

What's the best way to do this? Our modem takes modbus RTU (hopefully it'll do TCP soon). Our choice of PLC can be anything. We have a preference to AB-Rockwell though. We are looking at National Instruments DAQ solution as well.

Thoughts? Comments?
 
I have an application that requires high speed data acquisition. We are looking to capture data once every 10-20mS. This is for edge computing so once we collect this data, we need to analyze it, and act on it if necessary. Every X minutes (we are talking 10minutes), our modem will poll the PLC and push ALL that data out to the azure cloud.

What's the best way to do this? Our modem takes modbus RTU (hopefully it'll do TCP soon). Our choice of PLC can be anything. We have a preference to AB-Rockwell though. We are looking at National Instruments DAQ solution as well.

Thoughts? Comments?

Personally, I wouldn't base an IIoT/edge computing application on a serial interface. That just seems like the opposite of everything the movement stands for. Modbus RTU is the opposite of future-proofing things.

That said, I would think most mainstream PLCs should be able to log data internally to a big array and then send that data out later. It might not be 100% trivial, but it shouldn't be too complicated. It would pretty much be a big FIFO. The implementation details might change a bit from system to system, depending on whether

The big question is how much data you need to buffer. For 4 B of data (one Real/Float tag, or a DINT), at 10ms over 10 min you're looking at 240KB per tag monitored. In the PLC world, that's a medium amount. Big PLCs would be fine, small PLCs couldn't handle it, and medium PLCs could probably handle storing several tags. In the Siemens world, you'd be looking at a low end 1500 (1511 or 1513). Not sure in the AB world, probably a compactlogix.

Unless you're buffering in the modem?

You'll also need analog cards for the PLC. The cheapest cards out there might be too slow, but you shouldn't need a true High speed analog card. You'd also need to know what resolution you need. I've seen anywhere from 10 bit to 16 bit (15 + sign) in a PLC IO card; the NI solution might be able to go higher.
 
Last edited:
Modbus RTU, TCP or any other protocol that work using request-response will be probably too slow for your needs.

The alternative is to use a publish-subscribe protocol, uses half of messages than request-response and usually uses UDP that has less latency than TCP, examples of publish-subscribe: Ethernet/IP implicit messaging, Devicenet, CC-LInk , OPC UA subcriptions, MQTT ...
 
Have you considered plc push besides modem pull?
It sounds like you’re doing a first proof of concept or IOT experience so I wouldn’t worry to much. Just try. Then afterwards you can specify hardware and software requirements more easily.
 
Depending on how much data you’re trying to get you could definitely handle this with a time based or event based task. A CoDeSys PLC or AB Logix5k based PLC could buffer the data without issue.

You will need someway to transact this data over your data connection. This is a place where a CoDeSys PLC could be helpful. You can execute a stored procedure on a SQL server direct from the PLC to offload the data. An AB PLC will require some sort of transaction manager and OPC server to offload the data.

I would be concerned that an old dial up modem could handle the data connection. I would recommend an LTE cellular or high speed internet connection with a VPN to your database.
 
Our modem takes modbus RTU (hopefully it'll do TCP soon
Thoughts? Comments?


you will have to use something that stores the data locally then pushes it or your system pulls it out. you will never be able to poll anything over a modem connection at 20ms.
 
Have you considered plc push besides modem pull?
It sounds like you’re doing a first proof of concept or IOT experience so I wouldn’t worry to much. Just try. Then afterwards you can specify hardware and software requirements more easily.

Thanks for the response.
I'm going to guess that a modem pull is similar to modbus polling (correct me if I'm wrong)? And that's what we are doing. What is a PLC push?
 
you will have to use something that stores the data locally then pushes it or your system pulls it out. you will never be able to poll anything over a modem connection at 20ms.

So what we are thinking is to buffer in the PLC or data DAQ system. Then every minute or 10 minute we will send the data out.

At 1mS polling, 1000 data points would be collected in 1 second. What's the best way to send 1000 data points? Right now we have a cell modem polling the PLC for data, then packaging the data in a JSON message and send it out. Is that still the best way to send?
 
Modbus RTU, TCP or any other protocol that work using request-response will be probably too slow for your needs.

The alternative is to use a publish-subscribe protocol, uses half of messages than request-response and usually uses UDP that has less latency than TCP, examples of publish-subscribe: Ethernet/IP implicit messaging, Devicenet, CC-LInk , OPC UA subcriptions, MQTT ...

If we buffered 1000-60,000 data points in the PLC (can it even hold that much?) or data acquisition device and send it all out at once every 5-60 seconds that should be fine, right? :confused:
 
Personally, I wouldn't base an IIoT/edge computing application on a serial interface. That just seems like the opposite of everything the movement stands for. Modbus RTU is the opposite of future-proofing things.

That said, I would think most mainstream PLCs should be able to log data internally to a big array and then send that data out later. It might not be 100% trivial, but it shouldn't be too complicated. It would pretty much be a big FIFO. The implementation details might change a bit from system to system, depending on whether

The big question is how much data you need to buffer. For 4 B of data (one Real/Float tag, or a DINT), at 10ms over 10 min you're looking at 240KB per tag monitored. In the PLC world, that's a medium amount. Big PLCs would be fine, small PLCs couldn't handle it, and medium PLCs could probably handle storing several tags. In the Siemens world, you'd be looking at a low end 1500 (1511 or 1513). Not sure in the AB world, probably a compactlogix.

Unless you're buffering in the modem?

You'll also need analog cards for the PLC. The cheapest cards out there might be too slow, but you shouldn't need a true High speed analog card. You'd also need to know what resolution you need. I've seen anywhere from 10 bit to 16 bit (15 + sign) in a PLC IO card; the NI solution might be able to go higher.

We are looking at buffering either at the PLC or on a data acquisition device like NI. Those can read super fast, up to 1microsec. but we will be interested in 1mS. So, at 1 float = 4B/mS That would mean at 1 second that's 1000 data points, or 4KB.

We feel that sending polling and sending every 1mS isn't possible (or is it?)
 
You'd do a lot better if you'd split the scope of your project within two entities: Data Acquisition and Data Transfer.

'One-Size-Fits-All' might work on ball caps, however, not within your project's specifications.

Collect data with a dedicated Process Historian (such as FactoryTalk Historian ME/SE) which, in case of ME, could record at µs frequencies.

Once the data is recorded, 'push' it into the cloud using one of the numerous available data transfer services.

Again, timing is of the essence when recording; 'cloud' connecting services are not (and probably never will be) 'Real Time' as most of the Process Historians are.
 
If we buffered 1000-60,000 data points in the PLC (can it even hold that much?) or data acquisition device and send it all out at once every 5-60 seconds that should be fine, right? :confused:

How much data you can hold depends on the PLC available memory, of course there exist those that can store 60,000 16bits words

I did a little calculation, Modbus RTU is a very limited protocol, can not transmit more than 256 bytes each time, I think it would take between 3 and 4 minutes to transmit the 60000 words at 9600 bauds. If you plan to use AB then Ethernet/IP will be much better.
 
If you have a preference to AB then I would go 5K solution with Ignition MQTT to push to the cloud.


I have worked on NI stuff for years and personally don't like it, but hey that's just my opinion. But is is pricey!
 

Similar Topics

We have two staggered prox. sensors hooked up to an allen bradley vhsc24 point io module. They are counting up and down in encoder mode due to...
Replies
2
Views
1,516
We are exploring options for high speed data acquisition. Currently use AB hardware to do the machine controls and then NI hardware for the high...
Replies
2
Views
2,785
I am trying to figure out how to use a High speed counter module for an incremental encoder. I don't have the exact model number for the encoder...
Replies
4
Views
2,550
I have an application where the customer is looking to trend and log to file, tag variables. The customer wants to log data every 0.5 seconds. We...
Replies
4
Views
1,918
I'm wondering if someone could point me in the right direction here. I have a test fixture traveling at a speed between 10 and 40 mph that has a...
Replies
7
Views
2,850
Back
Top Bottom