ADS-Zugriff auf lokale Variable im FB?

ahds

Level-1
Beiträge
15
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe ein kleines Verständnisproblem beim SPS-Variablenzugriff über ADS, vllt kann mir jemand aushelfen.

Mein aktueller "Testaufbau" ist der folgende:

Auf der SPS läuft ein einfacher Test-FB der (u.a.) die lokale Variable "_test" enthält:
Code:
FUNCTION_BLOCK FB_Test
VAR
  _test : BOOL := FALSE;
END_VAR
...

Die "ADS-Adresse" ist dann - also mit dem Programm, das nichts anderes tut als den FB zu instanziieren und auszuführen: PRG_TestExec._tempFb._test

Und genau auf diese Variable kann ich via ADS zugreifen und manipulieren - obwohl sie keine Input- oder In-Out-Variable ist, sondern eigentlich "lokal".

Wie kann das sein - oder habe ich etwas bei der SPS-Programmstruktur mit ST nicht so ganz verstanden? (Ich bin ja Quereinsteiger aus der Softwarewelt...)


Grüße!
ahds
 
genau so ist es...

so wie die Variable heisst, so kannst du dieses auch als Namen auslesen.

Wichtig ist nur zu erwähnen, dass bei Twincat im PLC-Server unter Optionen das Häckchen für "Sammeleinträge ausgeben" oder so ähnlich gesetzt ist.

MfG CAS
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nicht nur Stilfrage

Hallo,

.... Und genau auf diese Variable kann ich via ADS zugreifen und manipulieren - obwohl sie keine Input- oder In-Out-Variable ist, sondern eigentlich "lokal".

Wie kann das sein - oder habe ich etwas bei der SPS-Programmstruktur mit ST nicht so ganz verstanden? (Ich bin ja Quereinsteiger aus der Softwarewelt...)


Grüße!
ahds

Man kann das zumindest als schlechten Stil bezeichnen. Ein FB sollte den inneren Teil über die "Schnittstelle" (Parameter) von der Aussenwelt abkoppeln. Wer auf Umwegen zugreift (dazu zählen eigetlich auch schon Zeiger) schafft sich selber potentiell Probleme.

Moderne OO Sprachen lassen so etwas gar nicht mehr zu, da gibt es die Modifizierer "public, protected, private" und der Compiler weigert sich so etwas zu fressen.
 
Man kann das zumindest als schlechten Stil bezeichnen. Ein FB sollte den inneren Teil über die "Schnittstelle" (Parameter) von der Aussenwelt abkoppeln. Wer auf Umwegen zugreift (dazu zählen eigetlich auch schon Zeiger) schafft sich selber potentiell Probleme.

Moderne OO Sprachen lassen so etwas gar nicht mehr zu, da gibt es die Modifizierer "public, protected, private" und der Compiler weigert sich so etwas zu fressen.

Ja ich bin es aus meiner bequemen Hochsprachen-Welt gewohnt, dass die Sprachkonzepte von pedantischen Compilern überwacht werden. Und das finde ich jetzt noch umso besser. :cool:

Und dementsprechend überrascht bin ich ja, dass so ein harter Bruch eines Sprachkonzeptes so einfach möglich ist! Wenn man bei der ganzen SPS-Programmiererei überhaupt von "Sprachkonzept" sprechen kann... ST ist ja schon ganz schön "clumsy".

Für mich als Quereinsteiger wäre es jetzt aber doch sehr interessant zu wissen, wie ich die Stilfrage am besten löse. Zumindest eurer Meinung nach.

Lohnt es sich für mich mit "VAR_IN_OUT" zu experimentieren? (Dieses Konzept habe ich, offen gesagt, immer noch nicht ganz verstanden.)
Oder lohnt es sich vllt, für ADS-Zugriff "von außen" immer Structs in VAR_INPUT und _OUTPUT zu definieren?

Für Tipps und Hinweise zu "gutem Stil" bin ich jedenfalls sehr dankbar!

Grüße,
ahds
 
Var_in_out

Lohnt es sich für mich mit "VAR_IN_OUT" zu experimentieren? (Dieses Konzept habe ich, offen gesagt, immer noch nicht ganz verstanden.)
Oder lohnt es sich vllt, für ADS-Zugriff "von außen" immer Structs in VAR_INPUT und _OUTPUT zu definieren?

Für Tipps und Hinweise zu "gutem Stil" bin ich jedenfalls sehr dankbar!

Grüße,
ahds

VAR_IN_OUT entspricht einer Übergabe per adress reference, in C++ ziemlich exakt einer Reference, d.h. einem Zeiger, der nicht in der Adresse verändert werden kann. Vorteil auch, man muss nicht die komplizierte Pointer Schreibweise nutzen, wenn man auf Elemente einer struct zugreift.

Ich übergebe an FB in der Regel structs mit VAR_IN_OUT, ein besseres information hiding ist in ST kaum möglich, wenn man die Effizienz eines Systems nicht in Frage stellen möchte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich übergebe an FB in der Regel structs mit VAR_IN_OUT, ein besseres information hiding ist in ST kaum möglich, wenn man die Effizienz eines Systems nicht in Frage stellen möchte.

So in etwa hatte ich mir das auch vorgestellt - aber in Verbindung mit dem ADS-Zugriff hatte ich da Probleme: Mein Test-Programm hatte das Struct angelegt (_struct) und dem FB als In/Out-Struct durch Aufrufen gesetzt:

Code:
_testFB(InOutData := _struct)

Mit dem Effekt, dass ich zwar per ADS auf Programm._testFB.InOutData zugreifen konnte, aber schreibend die Änderungen nicht "ankamen". Ich nehme an, dass der Aufruf oben in jedem Zyklus dafür gesorgt hat, dass der Inhalt von _struct in den FB geschrieben wurde.

Aber ich nehme eher an, dass ich da noch was falsch mache... ;)

Stellt sich also die Frage, wie ich VAR_IN_OUT-Structs "bestmöglich" mit ADS benutze.


Grüße,
ahds
Grüße,
 
Hallo,
Ich nehme an, dass der Aufruf oben in jedem Zyklus dafür gesorgt hat, dass der Inhalt von _struct in den FB geschrieben wurde.
Genau so ist es!
Wie schon zuvor beschrieben ist eine In/Out variable eine Zeiger auf eine Variable (in deinem Fall "_struct") die vom FB lesend und schreibend bearbeitet werden kann.
Stellt sich also die Frage, wie ich VAR_IN_OUT-Structs "bestmöglich" mit ADS benutze.
Du musst in jedem Fall auf die variable "Programm._struct" zugreifen, welche quasi die variable ist die vom FB lesend & schreibend bearbeitet werden kann.
Wenn du keine zusätzlichen variablen verwenden möchtest, musst du wohl den Umweg über Inputs zum schreiben und Outputs zum lesen gehen.
 
Zurück
Oben