In highly doubt scan rate is going to be a factor. You can buffer hundreds of tests which is kind of like store and forward in the PLC. Unless you are doing more than 4 tests a second scan is a non issue. If the tests are that fast, which no way they are, use @pturmel module.
I think before we devolve into a āwhich way is betterā thread, we should discuss the current method so as to properly define the problem. Thereās not enough here to move beyond mostly speculation.
How is the data being handled right now? If we could see a sample data set, that would be helpful.
We currently donāt have a way to handle the data transfer yet and that is why I am trying to resolve this. Thanks for your time!
All right,
How long is each test?
What is an acceptable sample rate (samples per second)?
100 ms for sampling rate, and test could be as long as 8 mins which is 5000 data points. From what I have seen, it is usually 300s.
Another useful question would be: Is there a time constraint on getting the data from the PLC after a test?
1 Like
- Do not lock up the SCADA interface
- Finish writing data before the next test starts
I would use my module to feed the data directly into the DB as it arrives. I would restructure the sample storage in the PLC to be a 5000 element array of a UDT of the five elements. I would pull multiple samples into an I/O buffer for transfer to Ignition, advancing the tail of the FIFO as Ignition acks each buffer-full. I have a customer using a similar approach to collect 25ms samples with a 100ms RPI, and room in the I/O buffer for 10 samples. Usually transmitting 4 at a time, but can catch up rapidly if packets are dropped. Their FIFO can hold about 10 seconds of data.
FWIW, display of such high density data can be a challenge. Which is why I also created my TimeSeriesDBCache module, and added support for it to my NoteChart module.
4 Likes