Refresh WebVisu Client through FBChangeVisu

2021-03-29T05:57:29.551000Z

The solution CODESYS followed was to use the common behavior model and do it this way.

In general I personally think that if you can get the instance path to a variable, someone will simply read/write to it, because it is a quick solution.
Most people are not aware of multi tasking/threading issues.

Best regards,
Marcel

Refresh WebVisu Client through FBChangeVisu

2021-03-29T05:53:21.605000Z

Again it would be way better for you to reproduce and report the issue.

Refresh WebVisu Client through FBChangeVisu

2021-03-27T04:41:59.240000Z

Thanks Marcel and rckalex for all the info.

Marcel, Just wondering, wouldn't all this be much easier to do if one could attach code at session/client, screen, and element levels as many other HMI systems do. For example, to create a client timeout one would just put a timer and a change screen command in a program having context/scope within a client. Same for screens and for elements.

It would make all the "not calling from visu task crashes" go away, would it not?

Anyway thank you for the help is is so much appreciated.

Rick

Refresh WebVisu Client through FBChangeVisu

2021-03-25T16:55:54.794000Z

Marcel,

As written it will refresh any client on that visualization page not just one with an extended duration. I would have to have a different custom filter for every visualization in the project. Prior to posting my question I already had a customer VisuClientIteration and ClientFilter based on your recommendation in this thread (https://forge.codesys.com/forge/talk/Deutsch/thread/f14041c158/?limit=25#9c5f).

Do you see any issue with implementing the custom Iteration with the HandleClient method doing the refresh?

FUNCTION_BLOCK VisuClientIteration IMPLEMENTS VU.IVisualizationClientIteration
VAR_INPUT
END_VAR
VAR_OUTPUT
END_VAR
VAR 
    fbVisuRefresh   : VU.FbChangeVisu;
    fbClientRefreshFilter : ClientFilterRefreshScreen;
    fbTargetedClientFilter : ClientFilterTargeted;
    xRefreshDone    : BOOL;
    eRefreshError   :  VU.ERROR;
    xRefreshBusy    : BOOL;
    xRefreshError   : BOOL;

END_VAR

------------------------------------

GVL.iNumberOfClients:=GVL.iNumberOfClients+1;

    GVL.aStClientInfo[itfClient.ClientId].iClientID := itfClient.ClientId;
    IF GVL.aStClientInfo[itfClient.ClientId].stCurrentVisu <> itfClient.CurrentVisuName THEN
        GVL.aStClientInfo[itfClient.ClientId].timeLastScreenChange := GVL.dwNow;
    END_IF
    GVL.aStClientInfo[itfClient.ClientId].stCurrentVisu := itfClient.CurrentVisuName;
    GVL.aStClientInfo[itfClient.ClientId].wsUserName := itfClient.UserName;
    GVL.aStClientInfo[itfClient.ClientId].sIpAddress := itfClient.GetIPv4Address();
    GVL.aStClientInfo[itfClient.ClientId].ClientType := itfClient.ClientType;
    GVL.aStClientInfo[itfClient.ClientId].timeLastActive := GVL.dwNow;

    IF GVL.aStClientInfo[itfClient.ClientId].timeLastScreenChange < (GVL.dwNow - GVL.dwScreenRefreshDuration) THEN
        gvl.iClientToRefresh := itfClient.ClientId;
        fbVisuRefresh(itfclientFilter := fbTargetedClientFilter, eError => eRefreshError, xExecute := TRUE, xDone => xRefreshDone, xError => xRefreshError, xBusy => xRefreshBusy, sVisuName := itfClient.CurrentVisuName);
    END_IF

In this case the IsAccepted method of the ClientFilterTargeted is checking

IF itfClient.ClientId = gvl.iClientToRefresh THEN
    IsAccepted := TRUE;
END_IF

Refresh WebVisu Client through FBChangeVisu

2021-03-25T07:05:30.045000Z

PROGRAM PLC_PRG
VAR
    changeVisu : VU.FbChangeVisu;
    xExecute: BOOL;
    eError: VU.ERROR;
    xError: BOOL;
    xBusy : BOOL;
    xDone: BOOL;
    itfClientFilter: VU.IVisualizationClientFilter := VU.Globals.AllClients;
END_VAR
----
changeVisu(itfClientFilter := itfClientFilter, eError => eError, xExecute := xExecute, xDone=>xDone, xBusy=>xBusy, xError=>xError, sVisuName := 'Screen');

Refresh WebVisu Client through FBChangeVisu

2021-03-25T06:54:01.656000Z

Implement your own IVisualizationClientFilter.
Accept will be called with IVisualizationClient, which contains the property CurrentVisuName

Refresh WebVisu Client through FBChangeVisu

2021-03-25T06:14:17.143000Z

GetNextClient will produce a warning starting with SP17.

The problem is simple, most of the users access visu data outside of the visu task resulting in possible crashes.

Refresh WebVisu Client through FBChangeVisu

2021-03-25T00:27:25.912000Z

Yes, examples would be very helpful.

Refresh WebVisu Client through FBChangeVisu

2021-03-24T16:51:04.676000Z

Marcel,

Is the official stance to no longer use the method proposed by Rick/illustrated in the sample? Is there a sample project you could point me towards that accomplishes the same using visu utils?

Refresh WebVisu Client through FBChangeVisu

2021-03-24T16:47:12.606000Z

Marcel,

I'll check to see if the behavior is browser agnostic and then report if necessary. In the interim there is an issue that I need to work around. Is there a way to reference the "CurrentVisuName" parameter of the current client as it works through the client filter (VU.IVisualizationClientFilter)?

Recent posts to Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu

Refresh WebVisu Client through FBChangeVisu