CLX driver intermittently does not update

[Gary Foster]

I am building a diagnostic application - displaying status of many PLC tags from 5 PLCs.
Using AdvancedHMI 399yBeta38
All but one PLC driver use a route path (to drill through the backplane to get to other subnets)
So far, I have about 25 screens. all are working. but ...
recently, one screen started to misbehave.
this screen has 4 different drivers to 4 different PLCs. 3 are routed as described above. There are about 80 basiclabels on this screen.
when this screen is opened, the tags of 1 or (usually) more than 1 driver do not update. If I close and reopen the screen, one or more different drivers will not update. At least one driver will not update no matter how many times I close and reopen the screen. A ComError event is raised on the drivers that do not update.
All other screens appear to work reliably. all other screens have fewer than 4 CLX drivers.

Any clues as to the problem?
Is it possible to reset / restart a driver at runtime?
How to workaround the problem?

BTW: cannot say enough good things about the AdvancedHMI package.

[Godra]

Split that screen into 2 screens with 2 drivers each and see if that fixes your issue.

You should also try using the code to stop polling from the screens that are not visible at any time (see that particular code on the MainForm).

[Gary Foster]

Godra, your suggestion worked.
for my education:
it appears that reducing poll rate has no effect. what is the failure mode for this problem?
is there a means to reduce the communication demand or to stagger timing between drivers?
is there a way to measure the comms load?
or reset a faulted driver during runtime?

thank you for the assistance.
r
GF

[Noe]

Which suggestion did work? First, second or both?

[Gary Foster]

The first suggestion was going to be my last ditch effort. I split the screens and that worked - for awhile. problem recurs less intermittently than before.

I already use the code to stop comms when a screen is not visible.

I assume that it is a bandwidth issue?
This is not a high response rate requirement. Throttling the throughput would be acceptable - if I knew how...

if a driver reports a ComError, it appears to stop. no more updates and the ComError count does not increment past 1.
restarting / resetting the driver would be acceptable also - if such a feature is available.

I recall reading somewhere that DataSubscriber gives better throughout than a conglomeration of BasicLabels. Is that correct?

thank you for the response.

[Godra]

You can perform an easy test:

Create a copy of your solution and then, at least on one of your screens, remove the values from all your BasicLabels PLCAddressValue property and leave all those labels where they are.

Add a DataSubscriber2 component, add to it all those values you removed and then access its DataChanged event and manually update BasicLabels values depending on what values were returned. The DataChanged event only fires when the returned values have changed.

If it works any better then you can consider replacing all BasicLabel controls with regular Label controls.