Fast data trending with millisecond resolution

Looking for guidance in fast data trending, historical trending, and export to Excel without losing resolution.

The details:

PLC tags to trend (OPC): 15
Calculated tags to trend (Exprension): 5
Scan Class for all tags: 10msec
Historical scan class for all tags: 10msec

What is the best method to collect the data at the desired rate, display the historical data with millisecond resolution, and export to Excel with the same millisecond resolution?

To date I have just used tried using Easy Chart to view realtime and historic data but cannot find how to achieve msec resolution. And exporting to Excel from Easy Chart only provides seconds resolution.
Do I need to change settings for trending tags or historical tags?

Would Reporting module provide me what I’m looking for?
All suggestions appreciated.

Any tag collection based on TCP (typical OPC) is going to have substantial jitter. Combine that with most languages’ garbage collectors (including java), and you’ll find your 10ms spec difficult to achieve. UDP data transfer from a PLC (like Ethernet/IP I/O or GE EGD) is generally jitter free (< 1ms) but not well supported in Scada systems. I solve these kinds of problems by combining external recording code and Ignition user interfaces and displays.
It also helps to include a very precise time source that all participating devices can synchronize with, like the 1756HP-TIME module for ControlLogix made by HiProm.

As for Excel, once you’ve successfully recorded at high resolution in your database, you simply use Excel’s direct DB drivers to pull any data you need into a spreadsheet. Then you have complete control of the raw data transfer.

I am acquiring my tags from a Controllogix L61.
I have not been optimistic in my superior officers request for 10ms sampling but thought I’d give it a try with Ignition. Previously we had been acquiring data at that rate using the trending feature of RSLogix5k.

Can you be more descriptive regarding your comment “I solve these kinds of problems by combining external recording code and Ignition user interfaces and displays.”?
Do you mean you do the recording code within the processor and then transfer blocks of data to Ignition?

Thanks!

[quote=“gglenn”]I am acquiring my tags from a Controllogix L61.[/quote]That helps. [quote=“gglenn”]Can you be more descriptive regarding your comment “I solve these kinds of problems by combining external recording code and Ignition user interfaces and displays.”?
Do you mean you do the recording code within the processor and then transfer blocks of data to Ignition?[/quote]Mixed.
I’ve written a daemon service for Linux that emulates a Logix ‘Ethernet-Module’ or ‘Ethernet-Bridge’ I/O device, offering either 496 bytes or 496x100 bytes, respectively, of recordable data that can be sent at fast RPIs. I’ve written a matching daemon service for Linux that subscribes to the packets in the I/O daemon, parses packets into variables, and performs bulk inserts into PostgreSQL. I’ve done light testing of this daemon pair down to 1ms RPI without problems.
The PLC code needs to be modified to copy data of interest into the virtual module’s output buffer. I generally recommend that all interesting data be placed into a structured tag and copied with a single ‘CPS’ instruction. Microsecond timestamps for the inserted data can be from packet delivery, Zulu from the ControlLogix GSV WallClockTime extracted from the packet payload, or both.
For all practical purposes, the resulting database content is functionally identical to Transaction group recordings made at RPI intervals, using OPC read mode, but guaranteed to be snapshot at packet boundaries.

We developed our own TCP protocol with Siemens that basically includes a timestamp, tagname, value. All of the values are stored in a buffer in the PLC. In Ignition, we wrote a TCP socket driver using java. It works great parsing millions of events of data every day into a partioned MySQL database.

We are also working mostly with Siemens PLC’s. I’d be very interested in your solution.
Can you share some details?

For now, I will put this on a shelf and accept that 100ms sampling via Ignition will do for now.

For your needs with Siemens PLC’s DNP3, it seems pturmel has a solution.