On-the-fly, real-time, dynamic—these are all words we use to describe how we want our software to work. Change is happening all the time in plants, and we need software that can keep pace with it without requiring that systems be shut down and rebooted. That’s why I’m excited to share a new feature we’ve added to KEPServerEX version 5.18 that will make your life easier.
Jun 23, 2015, 8:00 AM
Feb 24, 2015, 12:00 PM
Last week, I described several challenges that SCADA engineers face while determining a remote data acquisition schedule. I also shared the top seven features that our market research identified as helping to resolve those issues. Today, I'm happy to introduce Kepware’s new Scheduler Plug-In for KEPServerEX, which allows our industry-leading communications platform to take on the role of a dedicated polling engine. We’ve designed the Scheduler’s UI with the same clean, minimalist look and feel that users expect from Kepware products. This means we paid attention to reducing mouse clicks and creating intuitive and tidy organizational structures, wizard-driven configuration for more complex features, and a workflow design that is consistent with all of the other tools that you’re used to using within KEPServerEX.
Feb 19, 2015, 4:45 PM
For folks out there in SCADA engineering, whether fresh data is arriving on your control screens or not is particularly important. In certain environments (like high-speed manufacturing systems), the decision process around what data to read when and at what frequency sometimes can be as simple as determining the fastest rate of change of your most frequently changing data point—and then designing your control system to request all of your data at least twice as fast as this rate. Yes, it is extremely nice to have dedicated, fast data pipes for all of your important process data. But for SCADA engineers in environments where devices potentially exist hundreds of miles away from a central SCADA operations center, running dedicated cabling to these locations is cost prohibitive if not logistically impossible. This means that to connect to equipment, an organization is often using leased and shared Ethernet or telephone lines or utilizing wireless data transfer technologies like radio, cellular, and microwave. These transfer mediums don’t usually offer anywhere near the performance that you’d need for a one-size-fits-all style of data collection frequency.
Oct 29, 2013, 4:00 PM
View Kepware's new infographic with feedback from attendees of our KEPServerEX version 5.13 webinar, and discover what your peers are reporting as their biggest issues with scanning and pollingThen, learn how Kepware's new Device Demand Poll can be leveraged to resolve those issues through the additional resources made available in this infographic.
Oct 11, 2013, 7:00 AM
Classic off-the-shelf client/server interfaces like OPC are optimized for collecting information from any data source at some predefined cyclic interval. Within the client application, an end user can browse for information that is contained in one or more servers. The information of interest can then be selected and tied to UI controls for visualization, alarm and event objects for condition monitoring, or trends for historical analysis. As part of this, the end user will also set how often each piece of data should be polled from the data source. Although perhaps over-simplified, the rest of the scenario is as follows: the end user enters Run Mode, the server polls the data sources at the appropriate intervals and sends updates to the client when the value or quality of the data changes, and the client performs the necessary logic on the information as configured by the end user. The process continues until the client application is stopped.