When developers visited the site to install and commission the system, they discovered that they could not use the internal sample timers in the particle counters. Instead, they had to redesign the driver so that it would command the particle counters to stop, return a record, and start a new count every 10 minutes. Although this was a radical departure from the original design, it took the development team less than a day to implement. A custom driver with code would have required much more effort.
Weighing trade-offs
While using the U-CON driver can be effective in certain applications, writing an I/O driver may be worth the effort in other applications. When approaching each project, developers should consider a few critical questions:
* Is high-speed data processing a requirement?
* How complex is the protocol?
* Is it important to have a branded or proprietary interface?
* Which HMI/historian or client applications will need access to the data, and should they access the data via open standards or a proprietary API?
* Does the driver need to be distributed via licensing or royalty-free?
* Do you love writing code (and reading manuals)?
The answers to these questions can help guide developers to the best solution. Using U-CON can prove advantageous for most proprietary serial and Ethernet protocols.
Cutting integration time
OPC’s growth has enabled system integrators to easily integrate most programmable logic control and distributed control systems with HMI/SCADA systems. However, many legacy and proprietary systems still do not have an off-the-shelf driver. Previously, the system integrator’s only option in this situation was to write a custom driver at a significant cost.
The Kepware U-CON driver introduces a new option that can significantly reduce the time spent and expense paid to integrate a serial device. Using this driver, development time can drop from an estimated six-plus weeks per project to a few days.
No comments:
Post a Comment