I am onsite starting up our first production installation, 8.1.12, Vision windows for several HMI screens.
I have a 2 state toggle button on one view, navigating to different views with a tab strip, and after navigating to this view from another view and pushing this button, it can take upwards of 15 to 20 seconds to update the underlying OPC tag/PLC tag, very slow. After updating it once, it ‘seems’ to update more reasonably, a ‘second’ after each subsequent push after that. I could navigate away from the view and back and that behavior ‘seems’ to repeat itself, at least that I’ve been able to observe.
I’ve experimented with update rates for both tag groups and the client in project properties, to no avail yet. In general, to get started, is there something else I can or should look for in settings to update this tag? Thanks much?
Look at your driver diagnostics for that device. Are you actually getting the expected OPC performance?
Hi, Please see the attached screen shot from the Gateway, Status, Connections, Devices, device in question, which seems OK. Is there a better place to get diagnostics from?
As update, I did discover that the Gateway allocated memory was 'critically low' as shown in Gateway status, after I created this post, sorry.
I updated it from 2 GB (defaulted from trial days) to 8 GB and once put it in place and verified, that button push performance I note seems ‘notably’ better in several tries. There does seem to still be a little more delay than should be, such as a ‘few’ (like 4 to 5) seconds upon button push and observing value change sometimes. That is in just several testing tries after changing the allocated memory. Learning as we go and turning the dials and knobs here, if you have any other settings to look for, further detail on those diagnostics. Thanks very much.
Partially clipped at the bottom of the screenshot is “Sampled at 5000ms”. Are any of your subject tags in that tag group? It would explain an apparent 4-5 second delay.
Sorry for the late reply, have been experimenting , working with this, before getting back to this post.
We have had mostly one tag group that most of the tags, including this target belongs to. I have to get better about segregating them more, as we have not yet. I think the 5000 was a setting we had temporarily , as we are still experiencing this issue with it set to 1000 ms, but it doesn’t seem as bad.
In short, there are several buttons on our HMI’s, other physical HMI’s that behave similarly with varying delays of buttons. The Control bit seems to be written immediately, but it is the Indicator bound tag that we are seeing the delay(s) on. I am going to work tomorrow with creating /segregating the tag groups more, some with faster sampling to see what I get. But, if there is any feedback about why the control bit writes are immediate and we are seeing those delays in the indicators back , thanks.
Another thought: CPU and memory resources seem good on both gateway and client computers, however they are connected to 100 Mb port switches, as I understand all we could get for the AB industrial switches, as another thing we can try (1 GB switches)
Changing to 1GB switches is unlikely to make an impact. Won't hurt, though. This new topic might be of interest:
Found an answer that works. Thanks @pturmel . Scan class, in our default tag group, it was set up as leased, maybe best practice, but that seemed to be the issue. I created the new tag group, made that one Direct, with a data mode of polled, 750 ms for these tags in question, and bingo, performs as expected. Since leased is fast when a tag is in an open window, and ‘slow’ otherwise, I think…, that when switching to new windows, which the operators do frequently and using these buttons for the first time after opening, that it was retaining that ‘slow mode’. That’s the way it acted anyway, as subsequent pushes/uses were fine. But, switching to direct mode, navigating between windows, doing the button pushes, and the indicators are updating reasonably now. Thanks again.