(With Apologies to Robert Lamm and The Chicago Transit Authority.)
As I was walking down the street one day a man came up to me and asked me what the time was that was on my HMI time indicator, yeah, and I said:
Uhhh...don't ask me. I seem to only be able to get a 2 second resolution on this thing. It updates like...well...clockwork, but a clock that only works at half the expected rate. Odd thing, too, since the scheduled task script I'm running to update this thing should be firing every 500ms, half the time of the 1 second resolution I'm shooting for. This is a factor of 4 slowdown. And just look at these faceplates! When faulted they're supposed to switch between two colors at a rate of 1 second for each via another scheduled task. Right? Well, I've forced them to fault for testing purposes, and yet, here they sit as bastions of monochromaticity.
At that point the man gave me a funny look and quickly hurried off muttering something about at least still having time enough to cry.
And here I was...
I was still stuck trying to figure out why my custom time indicator wasn't working as I expected. Everything seemed to be programmed up correctly. I wrote a Visual Basic script that was scheduled to run every half-second, which got the local time of the OS and separated it out into its date and time. The date was put into one tag mapped to an I/O control, and the time was put into another tag mapped to a different I/O control. The date display worked perfectly; the time display, however, worked only half-perfectly, changing every two seconds, rather than every second as expected. So I fiddled with the period of the schedule, but each time the result was the same, the one-second resolution was ever elusive. (Naturally, any period higher than 2 seconds worked just as expected.)
At this point in the narrative, one might be thinking: "Just use the built-in Clock element in WinCC, already!"
Well, sure it's an option, but it has a significant limitation in that the date/time string which it displays does not support custom layout and formatting beyond basic font settings. It outputs on one line only with no possibility to split the date and time into two separate lines. A single line date/time output just wouldn't look as nice with the rest of the interface layout. However, the option of using the built-in control did have one thing going for it over the custom design we wanted to use--it actually worked as expected.
The problem got tabled, though, because at that point there were more important matters. For example, we were using faceplates to represent the motors, valves, inputs, and outputs of the system. One of the features we implemented was the ability to flash the faceplates red when the device was faulted. The cycle for the scheduled flash time was set to be every second. The desired result was the faceplate would flash red for a second, return to normal for a second, and then flash red for a second again, and the cycle would continue. We implemented the faceplates, set the flash rate, ran the HMI in the simulator, and upon setting a device to fault, nothing happened. There was no flash even though everything should be set correctly.
So I tried...
I tested many different values for the cycle rate of the scheduled task that caused the flash to occur. I tried 125 milliseconds, 250 milliseconds, and 500 milliseconds. And the results were the same: no flashing. I then tried 2 seconds and saw inconsistent behavior. The flash state would toggle at seemingly random times. It wasn't until I went to 5 seconds that we saw the flash finally occur consistently, but at a rate far slower than desirable.
It struck me that this might justt be related to the issue we saw with the clock. Every sub-two-second time interval had two seconds as an even-numbered multiple. So when 2 seconds was reached, which seemed to be the point at which we the animation would activate, there was nothing to do since the flash had toggled back to off. At 2 seconds, it seemed to be a matter of what processing delays were occurring as to where exactly around the 2 second window the toggle actually fired. (Since these are not high precision timers, there's certainly going to be some wiggle room for when they activate.)
"Maybe it's a simulation issue," I thought. "Let's wait until we can test this on an actual PC running WinCC Pro rather than a simulator."
So we did. And the problem was still there.
At this point...
It was time to swallow my pride and realize that this is clearly a programming error, but where? Searching around the internet didn't reveal too much so I started going through the various title bar menus to see if there was something I was missing. This proved fruitless. I then pulled up one of my HMI screens and brought up the context-sensitive menu and that's when I found it: a little menu item titled "Dynamization Overview." It certainly sounded promising. Selecting this menu brought up the "Dynamization Overview" page and revealed the problem: the default rate at which WinCC Professional HMI screens and their child controls check for tag updates is every two seconds. This means that unless these default values are changed, any animation that should occur faster than two seconds will be throttled.
A couple of side notes here:
- The Dynamization Overview menu option does exist in the title bar menu as well. However, it's context-senstive and only appears when your currently active screen in Portal is a WinCC Professional HMI screen. In all other cases that menu option is hidden.
- The context-senstive quality extends to a situation where you have individual controls selected. You will only see dynamization overviews for controls you've selected. To see all the controls, select them all or make sure only the parent screen is selected.
Now that the problem was found, the fix was easy, and could be accomplished multiple ways. The screen and all its child controls have a "Cycle" field that reveals a dropdown of all possible cyle rates. The easiest fix would be to change the cycle rate of the screen, which would result in faster animations for everything since all controls default to the screen cycle rate. The drawback is this can slow the entire HMI down due to all the refreshes, particularly for a screen with a lot of controls. The better option is to change the cycle rate of the individual controls as needed. Controls that don't need rapid updates won't hog system resources, but features like clocks and flashing can occur at a rate more suited to their purposes.
The update was made. The I/O control for time was set to update at a 500 millisecond rate which resulted in the value changing every second as dictated by the Visual Basic script that polled the system clock. The flashing for faulted equipment was set to update each second and that worked correctly as well.
And at the end of it all, the HMI could now tell you if it was twenty-five or -six to four.