Whether your role is IT or OT, there tends to be an almost universal dislike of having to work with printers. It is likely, for this exact reason, that when tasked with integrating a printer (be it a laser jet printer for labelling packaging, or a label printer to track your products) many users are simply forgoing the integration completely.  That might mean opting for limited integration with a PLC on the line or simply choosing to not integrate at all while continuing to make any configuration changes manually.

In this blog post, continuing our OmniServer Did You Know series, we’ll discuss several methods that users have implemented over the years when needing to use printers in a process and how OmniServer provides an off-the-shelf, easy-to-use alternative for direct integration of most printers with your process control systems.

In case you're not familiar with OmniServer, it is a user-configurable I/O server solution that you can configure through a user-friendly interface to communicate with various devices that do not already have off-the-shelf drivers written for them.

A question that our support engineers at Software Toolbox sometimes receive from both new and veteran OmniServer users alike is whether an item in the OmniServer sequence builder, which is used to build the send and/or receive message for a device protocol, requires a formatting code or not.

Continuing our Tech Support Corner blog series, this blog post covers under what situations a formatting code is required for an item defined in the OmniServer sequence builder of a protocol and when a code isn't required.

OmniServer's main purpose is enabling connectivity without custom code for devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers.  And OmniServer does that in a more efficient and cost-effective manner than writing custom code.

Furthering the goal of efficiency and cost-effectiveness, you may or may not be aware that OmniServer supports CSV import and export for speedy configuration of many things including topics, devices and, in the actual protocol itself, items, registers, topic variables and even messages.  On larger projects, this provides a substantial time savings.

In this post continuing our "OmniServer Did You Know?" blog series, we will cover how to use CSV import and export in OmniServer to facilitate faster configuration on larger protocol implementations.

If you're familiar with OmniServer, you know that OmniServer is frequently used for accessing information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.

With the advent of touchscreen technology and the increasing availability and familiarity with drag-and-drop functionality across computer systems and applications, we feel it is important to evolve the OmniServer user experience to be more inline with current technologies and user expectations regarding ease-of-use.

In this blog post, we will cover a visual protocol builder we've been working on for OmniServer, showing you the key enhancements to the user experience that will make integrating your non-standard devices easier than ever.  And you'll be given the chance to request more information and consideration for our new beta program.

If you're familiar with OmniServer, you likely already know how OmniServer is commonly used to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers either over serial connections or Ethernet connections.

However, with the advent of USB connectivity, many such devices that would have traditionally been a serial/COM device now physically connect to a machine via USB, instead.

Continuing our "OmniServer Did You Know?" blog series, we will cover how OmniServer can easily connect to USB or serial-to-Ethernet devices that are mapped virtually as Serial/COM devices.

The New Year is a time of renewal, new projects, new challenges, and for some of you, new roles, or new people on your teams.

In this blog post, we provide a quick reference to resources from the past year that should be helpful to you and your colleagues.  If you aren't already subscribed to our blog, we encourage you to . We publish new content about once a week, sometimes more often, and you can control when you are notified about new content.

When working with non-standard protocols based on protocol documentation from a device vendor, there will always be some expected amount of testing, trial-and-error and troubleshooting in order to fine tune communications with a device.

Continuing our "OmniServer Did You Know?" blog series, this blog post focuses on how to use the built-in Item Values window in the OmniServer diagnostic tools and the included OPC Test Client to test communications using OmniServer.

With any communication server for collecting process data, there has to be a reliable mechanism built-in for dealing with error responses from the underlying devices.  This is true even for OmniServer as a user-configurable communication server.

Continuing our "OmniServer Did You Know?" blog series, this blog post focuses on how to use error messages and notification items in an OmniServer protocol to properly handle error responses or conditions received from your non-standard process devices.

As part of our continuous improvement process at Software Toolbox, OmniServer is updated several times a year to add additional useful features and tools, and to resolve any known issues.

In this video blog, I will cover updates and enhancements available in OmniServer V3.1.0.5 to help you with usability, performance and troubleshooting while connecting to all of your non-standard devices.

In a nutshell, OmniServer's purpose is to retrieve information from devices that use ‘non-standard’ protocols to communicate such as weight scales, barcode readers, and printers.

Sometimes with some protocols, simply sending one message to a device, or doing nothing but simply transferring data to a client isn't enough. There are some more complex protocols where you will need to send a series of messages to the instrument, or respond to an event coming in from the device or to handle a sequence of handshaking messages. This is where "chained messages" come into play in an OmniServer protocol.

In this second post of a follow-up to our "OmniServer Did You Know?" blog series, we will cover how to chain multiple OmniServer command/request messages together in a protocol to flexibly handle such complex protocols.