Twincat 3 4022 Warnung: Zugriff auf VAR_IN_OUT .. von externem Kontext

[RoThe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

bislang wurde die Software einer Anlage immer mit Twincat 3 4018 programmiert.
Auf Wunsch des Kunden sollten wir nun auf 4022 upgraden.

Die durch Compileränderungen nun entstandenen Fehler konnten behoben werden, allerdings stehen ein Haufen Warnungen der selben Art an.

"Zugriff auf VAR_IN_OUT 'Variable' deklariert in 'FB' von externem Kontext 'Methode'.

Mir ist bewusst, dass es sich hier nur um eine Warnung handelt, allerdings sollte das Projekt frei von Fehlern und Warnungen sein..

Wie wäre hier das richtige Vorgehen, wenn man aus einer Methode auf eine VAR_IN_OUT Variable desselben FBs zugreifen möchte?

 

[StructuredTrash]

Die Warnung nervt mich auch. Eigentlich sollte die nicht erscheinen, wenn die Methode als PRIVATE oder PROTECTDED deklariert ist und somit nur aus dem FB heraus aufgerufen werden kann, tut sie aber doch.
Wenn die Methode PUBLIC ist, sollte es nach meiner Meinung sogar ein Fehler sein. Als Ausweg bleibt nur, die VAR_IN_OUT-Variable des FBs auch als VAR_IN_OUT an die Methode zu übergeben.

 

[Guga]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist konfigurierbar. Schau nach C0371 in der Liste (Screenshot).
Guga

 

[RoThe]

Vielen Dank für eure Antworten.
Stimmt, wenn ich den Haken bei der Warnung nehme, kommt die Warnung auch nicht mehr.
Allerdings muss es doch einen Grund dafür geben, dass die Warnung ausgegeben wird, beziehungsweise einen "richtigen" Weg wie es gemacht werden sollte, oder meint ihr der Fehler liegt aktuell noch bei Beckhoff und könnte im nächsten Build behoben sein?

Überall entsprechende VAR_IN_OUT Variablen in den Methoden anzulegen funktioniert an sich, wird allerdings wieder bei einigen anderen Methoden, die dasselbe Interface implementieren, problematisch.

 

[StructuredTrash]

Ich war zu spät. Dies ist eine Antwort auf #3.
Hm, das ist aber ein zweischneidiges Schwert. Ich hab's mal kurz ausprobiert: Wenn ich eine Methode, die auf FB-VAR_IN_OUT zugreift, außerhalb des FBs aufrufe, erhalte ich keine Fehlermeldung. Wenn ich die Warnung ausblende, habe ich gar keinen Hinweis mehr. Ich halte es für das Beste, so etwas erst gar nicht zu tun und FB-VAR_IN_OUT grundsätzlich auch Methoden als VAR_IN_OUT zu übergeben. Die Variablennamen kann man ja gleich lassen. Ich bin zwar kein Fan von verschatteten Variablen, aber in diesem Fall würde ich es gelten lassen.

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

@RoThe
Einen Grund hat das schon. Wenn die Methode außerhalb des FBs aufgerufen wird, zeigen die FB_VAR_IN_OUT-Referenzen wer weiss wohin.

 

[Woife]

Ich habe das gleiche Problem.

@RoThe
Einen Grund hat das schon. Wenn die Methode außerhalb des FBs aufgerufen wird, zeigen die FB_VAR_IN_OUT-Referenzen wer weiss wohin.

Dank diesem Beitrag verstehe ich wo Beckhoff (oder bereits CodeSys?) das Problem sieht. Was aber ist die Alternative?

Eine Action daraus machen? Eine Property verwenden?

 

[Woife]

Ein guter Kompromiss welche mir Beckhoff angeboten hat:

Man kann die Referenzen ja generell mit der Funktion __isvalidref prüfen. Um das dem Kompiler mitzuteilen, kann man dann die Warnung für den geprüften Programmblock explizit deaktivieren. Die geschieht mit Pragmaanweisungen:

{warning disable C0371}
//do something
{warning restore C0371}

Lustigerweise ist auch der Zugriff mit der __isvalidref Funktion bereits eine Warnung wert daher so:

{warning disable C0371}
IF __isvalidref(Referenzvariable} THEN
RETURN;
END_IF

//do Something
{warning restore C0371}

oder hald den Programmblock mit dem IF umschließen und nach dem END_IF die Warnung wiederherstellen.
Dadurch wird man weiterhin gewarnt und bei geprüften Programmblöcken gibt der Kompiler Ruhe. Man muss aber dazu sagen, dass die __isvalidref Funktion nur prüft, ob die Referenz leer ist, aber ein anderer Fehlerfall sollte mit Referenzen normalerweise nicht vor kommen (im Gegensatz zu Pointern). Leer ist sie dann, wenn sie nicht übergeben wurde, oder jemand so schlau ist und mit der REF= Anweisung eine null rein schreibt.

Gruß Woife

 

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
dieser Beitrag hat mir sehr geholfen, hier auch Danke von meiner Seite.
Ich habe jedoch noch eine Verständnisfrage.

Vorbedingung:
Die Methode arbeitet mit den VAR_IN_OUT welche in dem zugehörigen FB deklariert sind.
Diese Methode wird nicht innerhalb des FB aufgerufen. Die Prüfung der Referenz ist jedoch OK und das Programm lauft.

Könnte es passieren, dass nach einiger Zeit, ohne Programmänderung die Referenz auf einmal nicht mehr stimmt?
Sprich die Anlage bleibt stehen, weil die entsprechende Methode nicht mehr abgearbeitet wird.
Oder wenn doch jemand am Programm etwas ändert. Jedoch etwas was mit der Methode, FB, Abrufreihenfolge nicht zu tun hat?
Also man ändert das Programm an einer gan anderen Seite und plötzlich steht die Anlage.

Vielleicht hätte die Frage heißen müssen: Wann wird die Referenz zu den VAR_IN_OUT verändert?

Danke!

 

[StructuredTrash]

Vielleicht hätte die Frage heißen müssen: Wann wird die Referenz zu den VAR_IN_OUT verändert?

In TC3 sind VAR_IN_OUT wohl auch statisch. Zumindest deute ich den Umstand,, dass sich die Grösse eines FBs durch Hinzufügen einer VAR_IN_OUT um 8 erhöht (64 Bit System), so. Wenn Du also den FB einmal aufrufst und dabei zwangsläufig eine gültige Referenz übergibst, bleibt die solange stehen, bis Du dem FB bei einem erneuten Aufruf eine andere Variable als VAR_IN_OUT übergibst.
Ich habe bislang noch nicht ausprobiert, was bei einem Online Change passiert, wenn sich die Adresse der übergebenen Variable dabei ändert. Ich gehe aber davon aus, dass die VAR_IN_OUT-Referenzen in den FBs dabei nicht aktualisiert werden. Wenn Du in einem Programmzyklus Methoden des FBs vor dem eigentlichen FB aufrufst, wird das zu Problemen führen.
Ich habe als Problemlösung mal einem solchen FB eine Aktion spendiert, die keinen Code hat, sondern nur die Übergabe der VAR_IN_OUT sicherstellt, und diese Aktion immer als erstes im Programm aufgerufen.

 

[Gleichrichter1]

Ich habe mal was im Infosystem gelesen:

Methode
Fast ganz unten bei:
Zugriff auf VAR_IN_OUT-Variablen des Funktionsbausteins in einer Methode/Transition/Eigenschaft