Software Toolbox Technical Blog

Cogent DataHub® (from our developer partner/publisher Skkynet) provides a wide selection of connectivity options to OPC DA, OPC UA, OPC A&E, Databases, Excel, ODBC, DDE, Linux, Modbus.  As you may have already learned recently, DataHub Version 10 now includes support for integration with a wide range of common external historians. This expands your options for which data sources are compatible for historization in your chosen historian solution beyond the historian's native interfaces.

In this blog post, we'll detail how to get started integrating your data sources accessible by DataHub with AVEVA™ Insight, by writing data to your AVEVA Insight instance while also making that same historical data available for trending, visualization and reporting for both DataHub and external historical clients supporting OPC UA Historical Access (HA). 

Cogent DataHub is known for its extensive connectivity to OPC DA, OPC UA, OPC A&E, Databases, Excel, ODBC, DDE, Linux, Modbus.  As you may have already learned, the DataHub Version 10 now includes support for integration with a wide range of common external historians, expanding your options for which data sources are compatible for historization in your chosen historian solution.

In this blog post, we'll detail how to get started integrating your data sources accessible by DataHub with AVEVA™ Historian by writing data to your AVEVA Historian while also making that same historical data available for trending, visualization and reporting for both DataHub and external historical clients supporting OPC UA Historical Access (HA). 

Cogent DataHub is known for its extensive connectivity to OPC DA, OPC UA, OPC A&E, Databases, Excel, ODBC, DDE, Linux, Modbus.  The latest Version 10 release expands connectivity to include a wide range of common external historian solutions for historizing industrial data and integrating historized data with other systems.

In this blog post, we'll highlight some specific key details about which historians are supported and how other DataHub functionality works with those historians to provide flexible options.

An often important task when logging important process data to a database or even to the cloud is verification that the data has been logged. This ensures that data has been successfully logged and will not be lost when overwritten in the downstream process.

In this video blog, we'll step through the configuration required in the OPC Data Logger for logging important process data to a database on condition related to a monitored item and how to perform a writeback to the OPC data source confirming the data has been successfully logged.

With the advent of cloud-based solutions in every industry, it's only natural that you might need to migrate from a traditional locally-hosted SQL database for logging your process data to Azure. Fortunately, logging both to traditional SQL and Azure SQL are similar in many ways and OPC Data Logger makes it possible to log to both for OPC UA and DA data sources.

In this video blog, we'll review the basic setup and architecture for OPC Data Logger and then step through the configuration required for logging to SQL and Azure SQL from an OPC server.

As you are probably aware, OPC Data Logger is an OPC lab-certified solution for dynamic, event driven logging of process data to standard SQL/ODBC databases, including Microsoft Azure SQL, or text/CSV files.  As part of the continuous improvements process for OPC Data Logger, we have regular product releases that provide updates to existing features and new functionality.

In this blog post, I'll cover some flexible new features that you may not be aware of from our most recent releases of the OPC Data Logger available now in V3.7.0.1.

What is the most important feature for any data logger to have? At the end of the day, we are trusting a data logger to take our data and store it.  Now whether that is for reporting, optimization, legal reasons, or simply to retain process data over some period of time in case it might be needed later, we expect the data to be logged without any losses.

This is particularly true in the industrial automation space, where the amount of data that is being logged is growing almost as exponentially as the speed at which the data is needed in order to have a business impact. As such, the prospect of losing data can very quickly result in lost jobs, thousands of dollars in lost production, and legal or financial penalties in case of an audit.

So how much do you trust your data logger to really be logging 100% of the data that it should be? In this blog post, I will address these concerns and highlight the ways OPC UA provides capabilities that software applications can leverage to provide peace of mind.

Does your data logging software force you to define the location where you're logging your data ahead of time?  Wouldn’t it be nice if your logging software could evaluate your data and make a decision on where the data should be logged?

In this first of two posts in a series on dynamic SQL logging, I'll show you how the OPC Data Logger can easily be configured to switch between SQL Tables at runtime, reducing any post-log sorting you have to do in SQL and saving you time and effort in the process.