Software Toolbox Technical Blog

You may or may not be aware that our technical support team at Software Toolbox maintains, updates and adds new content to an extensive knowledge base built from answers to all of your questions from over the years.  We like to frequently review which of our knowledge base articles have been used the most to see what users like you need help with and what is most relevant.

Continuing our Tech Support Corner blog series, this blog post covers the why's and how's of using the popular and powerful network analysis tool called Wireshark as an additional tool in your troubleshooting arsenal.

You've likely already heard about Cogent DataHub and it's MQTT integration capabilities.  The DataHub MQTT Client goes beyond just generically connecting to MQTT Brokers by providing smart connectors for Azure IoT Hub, Google IoT and Amazon IoT Core MQTT Broker services.

The following short video blog demonstrates step-by-step how to easily configure the DataHub MQTT Client for publishing OPC UA and OPC DA data from DataHub to the Azure IoT Hub, as well as, pushing data from the many other data sources supported by Cogent DataHub (such as ODBC, DDE, Modbus and more).

As you are likely already aware, Cogent DataHub Version 9 expands the assortment of data sources you can integrate to include IIoT (Industrial Internet of Things) with MQTT (Message Queuing Telemetry Transport) support.  As with its many other supported data sources (such as OPC), DataHub V9 can act as both a "client" and a "server" for MQTT - with a "server" being an MQTT broker.

The following short video blog demonstrates how truly easy it is to configure the DataHub MQTT Broker for acting as a "gateway" between MQTT Clients in your IIoT cloud and other supported interfaces including OPC, DDE, ODBC and many other data sources.

With the release of Cogent DataHub Version 9, we've expanded the multitude of data sources you can integrate to include IIoT (Industrial Internet of Things) with MQTT (Message Queuing Telemetry Transport) support.

The following short video blog demonstrates step-by-step just how easy it is to configure the DataHub MQTT Client for publishing data from DataHub to any MQTT Broker, as well as, subscribing to data from any MQTT Broker for integration into your systems via DataHub's supported interfaces (such as OPC).

The 2018.3 release of the OPC Data Client toolkit continues to make OPC UA client development easier, more secure and interoperable, while continuing to support OPC DA, A&E, and XML-DA development.

In this blog post I have taken the release notes and boiled it down to the key benefits that might drive you to upgrade, get back on support, renew support, or, if you’re new to OPC client development, try our OPC Data Client toolkit.

Cogent DataHub is known for its extensive connectivity to OPC DA, OPC UA, OPC A&E, Databases, Excel, ODBC, DDE, Linux, Modbus.  The new V9 takes our saying that "once the data is in DataHub, it can go anywhere" to a new level with IoT connectors and more as listed below.

In this blog post, I'll provide insight into these new features and show you how Cogent DataHub delivers secure, scalable, integrated connections within and between your plants, to the cloud and beyond.

If you’ve been following our blog series on custom error detection, you’ll remember that OmniServer provides a large number of pre-defined Error Detection Codes (EDC) for use in different protocols for non-standard device communication.  And, again, it’s not uncommon to find an EDC from a vendor that is not pre-defined due to some specialized handling by the device manufacturer.

As we covered in our previous posts on creating a custom checksum and LRC, OmniServer gives you the ability to build custom EDCs in an OmniServer protocol to handle these situations.  This post, the final of three on custom Error Detection Codes, covers the basics steps to creating a custom CRC (Cyclic Redundancy Check) in an OmniServer protocol.

You may be aware that OmniServer provides a wide variety of pre-defined Error Detection Codes (EDC, also known as CRC, LRC and Checksums) for use in protocols for non-standard device communication.  However, it’s not uncommon to find an EDC that isn’t pre-defined due to some specialized handling by the device manufacturer.

To handle such situations, OmniServer provides the ability to build your own custom EDCs in an OmniServer protocol.  This post, the second of three on custom Error Detection Codes, will cover the basics of creating a custom LRC (Longitudinal Redundancy Check) in OmniServer.