High speed data acquisition

Nearbyatom said:

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?

Click to expand...

I`m having trouble with how much data you are looking at, and what type of communication you want to use. Perhaps your modem is much faster than I am used to.

I`ll just make up some stuff (assumptions);
- 1000 data points, we`ll assume floating point
- assume 4-byte single-precision float, so 4000 bytes
- assume 20 ms sample
- modbus RTU .. assume 19,200 baud at default even parity, 7 data bits, 2 stop bits = 10 bits per byte, plus packet start and CRC ... I`ll ignore that overhead stuff and the delays that the poll-reponse has.

1000 points * 20 ms = 20 seconds
19,200 baud gives you about 1920 bytes per second, at 10 bits each

So for every 1000 data points, you need over 2 seconds to send the data at 19,200 baud. So you could only gather 10 points at this rate and send the data continuous to the modem.

60,000 points would take over 2 minutes.

So I guess you are using a higher baud rate.

115,200 baud seems to be common for USB to serial converters. Not sure if that applies to modems. But if it did, you`d get 11,520 bytes per second. So almost 2800 points of data would fit into each second. At a 20 second poll, you could not quite fit 60,000 points. In my opinion, this is too little headroom for SH*T happens ... for a reliable system.

So the PLC should have a decent FIFO for serial
it might be nice to use an interrupt routine to gather the data
You might need to timestamp at least the first point, to ensure that your polling is not reading old data
The PLC should have room for 2 sets of data, so it is not writing into the values that are being polled. The data is gathered, then copied to a buffer for polling.
You may need to pay attention to retries, data throughput on your modems, and how much delay your system can tolerate.

If you use Modbus RTU, that protocol will ensure that the data is in the correct order when it gets to the destination, and the CRC will ensure that there are no errors and take care of the Nak/Retries. But it has little gotchas like no characters transmitted for 3.5 character transmission times (35 bits) signals end of packet ... the timing gets a bit hairy at higher speeds with packet delays, radio delays, etc.

I think a commercial Modbus solution is a dead end because the commercial products are not made to operate at the throughput rate you need.

I've sat through some Profinet promotions and they emphasized their fast real-time throughput with motion control cited as the premier application.

I haven't a clue how closely Profinet fits your application, but it is an engineered fast protocol solution.