Step 7 Globalen DB an SCL übergeben ...

[Dauty]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an alle !

ich hab ein kleines Problem mit den DB's und SCL...
ich möchte gerne zB einen global angelegten DB der für alles mögliche verwendet wird als INOUT an eine SCL Quelle übergeben ...
mit einem DB in den ein Array of UDT's angelegt sind hab ichs schon hinbekommen aber mit dem DB alleine noch nicht....
den DB in der SCL Quelle selber anlegen kann ich leider auch nicht da sonst der Baustein zu groß wird...
ich weiß jetzt nur nicht ob ich einfach nur einen Syntax Fehler hab oder ob das so gar nicht geht ..
ich hoffe es kann mir da jemand von den Profis unter euch helfen könnte
mfg
Dauty

 

[hucki]

Bin zwar nicht der Profi, den Du suchst, aber ich glaube, Du musst den DB bei IN angeben und kannst dann damit schreibend und lesend auf diesen DB zugreifen:

[FONT=Courier New]VAR_INPUT
    // Eingangsparameter
    DatenDB: BLOCK_DB;
END_VAR[/FONT]

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
so, wie ich deine (An-)Frage verstanden habe, funktioniert es nicht.
In dem Moment, wo du dem Baustein (ob AWL oder SCL ist hier egal) den DB als Bezug übergibst kennt deswegen der Baustein innen den DB trotzdem nicht. er kann somit also nicht auf ein symbolisches Adress-Konstrukt zurückgreifen weill es das zum Zeitpunkt des SCL-Script-Erstellens und damit auch beim Compilieren noch gar nicht gibt.
Die einzige Möglichkeit, die du hast, ist etwas Bekanntes zu übergeben - also z.B. einen UDT-Bereich oder ggf. auch den ganzen Datenbaustein, wenn der als UDT deklariert ist. In dem Fall ist dein IN-Parameter aber nicht vom Typ Bleck_DB sondern von dem gewählten UDT-Typ.

Gruß
Larry

Ergänzung / Nachtrag :
Bei der Lösung von Hucki, die du wahrscheinlich auch selber schon einsetzt, kannst du auf die Inhalte des DB nur absolut (also mit direkter Adress-Eingabe) zugreifen ...

 

[hucki]

mit einem DB in den ein Array of UDT's angelegt sind hab ichs schon hinbekommen aber mit dem DB alleine noch nicht....

Ergänzung / Nachtrag :
Bei der Lösung von Hucki, die du wahrscheinlich auch selber schon einsetzt, kannst du auf die Inhalte des DB nur absolut (also mit direkter Adress-Eingabe) zugreifen ...

Hm, hatte das eher andersrum verstanden, also das er das mit den UDTs schon hinbekommen hat.

 

[Dauty]

Hallo Larry & hucki...

also nur als IN put Variable deklaration geht es sicher nur um lesend darauf zuzugreifen und dann auch nur direkt adressiert zB DB10.DBW10 ...
um aber schreib lese zugriff zu hab muss es inout sein...
ich hätte es aber gerne mit symbolischer Adressierung da dies doch besser ist um Programm Fehler zu finden usw .

Larry...
wie meinst du das ?!? das der Datenbaustein beim SCL-Script-Erstellens und damit auch beim Compilieren noch gar nicht gibt?!? den Datenbaustein gibt es ja schön vorher in meinen Programm genauso die UDT'S ?!?
oder werden hierzu UDT's bevorzugt ?!?
das verstehe ich nicht ganz...leider findet man über solche Sachen auch nicht wirklich viel wenn Hans google..

mfg
Dauty

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Larry & hucki...

also nur als IN put Variable deklaration geht es sicher nur um lesend darauf zuzugreifen und dann auch nur direkt adressiert zB DB10.DBW10 ...
um aber schreib lese zugriff zu hab muss es inout sein...

Du kannst dann schon lesen und schreiben. Und der Datenbaustein ist auf jeden Fall nicht mehr absolut angegeben, z.B.:

VAR_INPUT
    // Eingangsparameter
    DatenDB: BLOCK_DB;
END_VAR

DatenDB.DBW10 =: 12;

Ist ja im Prinzip das Gleiche, wie in AWL. Da wird der Block_DB auch nicht als IN_OUT deklariert, weil Du ja nur auf die einzelnen Adressen schreibend zugreifst und nicht der Name des DB überschrieben wird.
Inwieweit DBW10 dann noch durch Symbolik ersetzt werden kann, entzieht sich gerade meinem Wissen.
Bin aber der Meinung, das dann z.B. DatenDB."Störword10" auch noch geht.

Aber wie gesagt, ich bin da nicht so der Profi. Ist nur Übung für mich.

 

[nutellahase]

Also symbolisch geht es nur, wie von Larry bereits geschrieben, wenn du den UDT übergibst. Das heißt du hast in deinem DB ein Array of UDT angelegt. Dann schreibst du in SCL im In_Out Bereicht

My_Udt: Array[1..10] of "UDT_Name" ... verwendest du die "" dann wird der UDT symbolisch erfasst, es geht allerdings auch ohne "" also nur Array [1..10] of UDT_Name

Mit dieser Methode bist du allerdings an das Array "gebunden" sprich du kannst dann nur Arrays gleicher Dimensionen übergeben die von diesem UDT_Typ sind!

EDIT: Der Zugriff erfolgt dann mit: My_Udt[1].UDT_Komponente ...

 

[Larry Laffer]

Larry...
wie meinst du das ?!? das der Datenbaustein beim SCL-Script-Erstellens und damit auch beim Compilieren noch gar nicht gibt?!? den Datenbaustein gibt es ja schön vorher in meinen Programm genauso die UDT'S ?!?
oder werden hierzu UDT's bevorzugt ?!?

Hallo,
im Moment des Compilierens weiß der Compiler nicht, was du irgendwann einmal als Block_DB übergeben möchtest. Du kannst hier ja jeden DB (ungeachtet dessen Aufbau) übergeben. Der Compiler kann aber nur das berücksichtigen was er zur Compile-Zeit schon kennt.
Ein UDT, den du auf der Schnittstelle benutzt, ist schon angelegt (also bekannt) sonst kannst du ihn auch nicht als Variablentyp angeben. Da der UDT vom Aufbau bekannt ist kann der Compiler ihn auch symbolisch (auch mit seinen Unter-Elementen) weiter verarbeiten.

Du hast also nur die beschriebene Möglichkeiten :
- du programmierst den Datenbaustein symbolisch in dein Script (kannst ihn dann aber zur Laufzeit nicht ändern) - also "meinDB".meineGruppe.meineVariable
- du übergibst den DB zur Laufzeit und kannst dann nur absolut auf die Inhalte (und auf die auch nur im Format BYTE, WORD , DWORD) zugreifen
Beides oder eine Vermischung geht nicht.

War es jetzt verständlicher ?

Gruß
Larry

 

[nutellahase]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du hast also nur die beschriebene Möglichkeiten :
- du programmierst den Datenbaustein symbolisch in dein Script (kannst ihn dann aber zur Laufzeit nicht ändern) - also "meinDB".meineGruppe.meineVariable
- du übergibst den DB zur Laufzeit und kannst dann nur absolut auf die Inhalte (und auf die auch nur im Format BYTE, WORD , DWORD) zugreifen
Beides oder eine Vermischung geht nicht.

Es gäbe noch den Umweg über die Lokaldaten! Wenn man es wirklich mit Block_DB symbolisch haben möchte könntest du dir im temp. Bereich deinen UDT anlegen dann kopierst du am Anfang vom Baustein deine Daten in deine UDT-Struktur und am Ende nach der Bearbeitung kopierst du die UDT-Struktur wieder zurück in den DB! Somit könntest du innerhalb des Bausteins symbolisch zugreifen. Ist zwar ein ziemlicher Aufwand aber soweit ich jetzt gelesen habe, sind UDTs im In Out Bereich sowieso Zykluszeitfressend da hier ja auch nur ein Pointer übergeben wird (ich bitte um Korrektur falls diese Aussage falsch ist!).

mfg

 

[Larry Laffer]

@Nutellahase:
Mit dem Pointer liegst du richtig - aber den hast du ja so oder so.
Wenn du den übergebenen DB in deinen Lokalbereich kopieren willst dann mußt du dir da ja auch einen Pointer bauen und die die Daten mit Blockmove (z.B.) da hin kopieren (und am Baustein-Ende auch wieder zurück).
Ich würde diesen Weg aber nicht gehen sondern mir ggf. überlegen, was der Sinn meiner Massnahme sein soll - den könnte uns der TE ja auch noch liefern ...
Generell gilt aber nach meiner Meinung für SCL : so weit es geht alles in dem Baustein (also den für SCL bekannten Bereich) lassen.

Gruß
Larry

 

[Thomas_v2.1]

Es gäbe noch den Umweg über die Lokaldaten! Wenn man es wirklich mit Block_DB symbolisch haben möchte könntest du dir im temp. Bereich deinen UDT anlegen dann kopierst du am Anfang vom Baustein deine Daten in deine UDT-Struktur und am Ende nach der Bearbeitung kopierst du die UDT-Struktur wieder zurück in den DB! Somit könntest du innerhalb des Bausteins symbolisch zugreifen. Ist zwar ein ziemlicher Aufwand aber soweit ich jetzt gelesen habe, sind UDTs im In Out Bereich sowieso Zykluszeitfressend da hier ja auch nur ein Pointer übergeben wird (ich bitte um Korrektur falls diese Aussage falsch ist!)

Der Zugriff eine Struktur im In-Out erzeugt mehr Code. Wobei hier SCL hier effizienteren Code erzeugt als es in direktem AWL möglich ist, weil der Inhalt der Adress- und Datenbausteinregisters nicht wie in AWL bei jedem Zugriff neu geladen werden, sondern nur wenn es notwendig ist.

Das Umkopieren auf Temp-Variablen hat nur eine Tücke. Nämlich wenn aus einem "nebenläufigen" Interrupt auch auf diese Daten zugegriffen wird, dann geht das unter Umständen in die Hose (FB kopiert auf Temp-UDT, OB35 Interrupt schreibt in Global-UDT, FB kopiert seinen alten Temp-UDT wieder in den Global-UDT -> Daten kaputt).
Bei der PC-Programmierung gibt es zu diesem Zweck das Mutex Konzept, also eine Variable die atomar d.h. in einem Programmschritt ununterbrechenbar geschrieben werden kann, und die anzeigt dass jemand gerade Zugriff auf einen Datenbereich hat und der andere Prozess/Thread warten muss. Sowas will man sich in einer SPS aber nicht unbedingt antun wenn es auch anders geht.

Ich habe das mit dem Umkopieren selber auch schon gemacht, und mir ist die Problematik die entstehen kann erst später bewusst geworden. Man sollte es nur im Hinterkopf behalten, da es Fehler erzeugen kann die nur sehr schwer nachzuvollziehen sind.