Step 7 Adressen nicht-zugewiesener Variablen und speichernde VAR vs Merker (SCL und allg.)

quantum

Level-1
Beiträge
5
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi, nachdem ich einiges über SCL gelernt habe, kommen folgende Fragen auf.

1. Was passiert mit allen Variablen, die nicht sofort einer Adresse zugewiesen werden, sondern einfach nur als bspw. BOOL oder WORD oder INT deklariert werden?

1.1 Ich frage mich hierbei, wo die Variablen abgespeichert werden, wenn ihnen keine Adresse zugewiesen wird?

1.2 Wird nicht-adressierten Variablen dann eine zufällige Adresse zugewiesen? Kann dadurch aus Versehen eine benutzte Adresse überschrieben werden?

2. Angenommen ich deklariere in einem FB:
...
VAR
bTest : BOOL;
END_VAR
...
Soweit ich es verstanden habe behält diese Variable ihren Zustand oder Wert durch den Instanz-DB. Wo finden Merker dann noch ihren sinnvollen Platz, wenn der DB die Aufgabe übernimmt?

3. Ähnlich zur ersten Frage. IN/OUT-Variablen erhalten ebenfalls keine feste Adresse bei der Deklaration. Es wäre nicht einmal möglich diesen eine Adresse zuzuweisen, da sie ja als IN und OUT Variable zugleich dienen. Dennoch müssen auch IN/OUT-Variablen irgendwo Speicher belegen, wo passiert das?

4. Falls, bezüglich des nicht-adressierten Speichers, die Lösung lautet, dass es einen speziellen Speicher gibt, der diese nicht-adressierten Variablen versorgt,

4.1 welcher Speicher wäre das?

4.2 Wie weiß ich, ob ich diesen Speicher (wenn es ihn gibt) durch nicht-adressierten Variablen überfülle?
 
Zuletzt bearbeitet:
Der Compiler gibt den Variablen automatisch eine freie Adresse im durch VAR_... angegebenen Speicherbereich - bei Speicher mit "Standard-Zugriff" die nächste freie Adresse, bei "optimiertem" Speicher irgendeine (geheimgehaltene) Adresse nach den Optimierungs-Regeln (nach Größe sortiert anordnen). Sollte tatsächlich ein Speicherbereich "überfüllt" werden, dann wird der Compiler das melden.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In welchem Speicher IN/OUT/IN_OUT-Variablen liegen ist vom Baustein-Typ abhängig:
- bei FB liegen die in der Instanz (Instanz-DB (IDB) oder Multiinstanz in einem Mutter-IDB)
- bei FC liegen die in den Lokaldaten (TEMP) des aufrufenden Bausteins und werden im FC als "Vorgänger-Lokaldaten" angesprochen

Harald
 
Ich kann mich Harald nur anschliessen. Der SCL-Compiler macht nichts anderes als die Variablen so anzulegen als wenn du sie selbst in einem Kop/Fup/Awl baustein selbst in der Schnittstelle deklarierst.Und zwecks Merkern... Die haben meiner Meinung garkeinen Sinn mehr, ausser vielleicht Taktmerkerbyte und Logisch-0 und Logisch-1.
 
Danke für die ganzen Antworten. Können automatisch adressierte Variablen nicht anschließend von mir überschrieben werden, wenn ich nicht weiß, welche Adresse verwendet wurde?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Merker haben meiner Meinung nach in den 300/400 CPUs durchaus Sinn. Bei einem Programm welches sehr viele Zugriffe auf Daten aus mehreren DBs hat, wird es irgendwann Einfluss auf die Zykluszeit nehmen.
DB öffnen, Byte und Bit- Adresse analysieren, Variablenwert lesen und verarbeiten dauert Zeit. Wird das öft gemacht, steigt die Zykluszeit.
 
Können automatisch adressierte Variablen nicht anschließend von mir überschrieben werden, wenn ich nicht weiß, welche Adresse verwendet wurde?
Nicht wenn Du ausschließlich direkt über deklarierte Symbole zugreifst. (Ausnahme: mit "AT" Variablen absichtlich auf überlappende Speicheradressen legen)
Bei Merkern mußt Du selbst drauf achten, die Variablen in der Symboltabelle nicht überlappend zu deklarieren.


Merker haben meiner Meinung nach in den 300/400 CPUs durchaus Sinn. Bei einem Programm welches sehr viele Zugriffe auf Daten aus mehreren DBs hat, wird es irgendwann Einfluss auf die Zykluszeit nehmen.
Das gilt schon lange nicht mehr. Bei S7-300-CPU ab 2008 und S7-400-CPU ab 6ES741x-xxxx6 ist es egal, ob auf Merker oder DB oder verschiedene DB zugegriffen wird - die Zugriffszeit ist gleich lang. (nur teilqualifizierte DB-Zugriffe auf den aktuell geöffneten DB/DI dauern etwas länger für das zusätzliche ermitteln der DB-Nummer)

S7-300 Operationsliste schrieb:
Die CPUs verfügen über eine performante Unterstützung für symbolische Programmierung. Die hier verwendeten vollqualifizierten DB-Zugriffe (z. B. DB100.DBX 1.2) verursachen im Regelfall keine zusätzlichen Laufzeiten. Dies gilt auch für den im Zugriff enthaltenen AUF DB Befehl.

Harald
 
Das gilt schon lange nicht mehr. Bei S7-300-CPU ab 2008 und S7-400-CPU ab 6ES741x-xxxx6 ist es egal, ob auf Merker oder DB oder verschiedene DB zugegriffen wird - die Zugriffszeit ist gleich lang. (nur teilqualifizierte DB-Zugriffe auf den aktuell geöffneten DB/DI dauern etwas länger für das zusätzliche ermitteln der DB-Nummer)

Harald

Das mag sein, aber ich habe viele Anlagen an denen ich in unserem Bereich rumschrauben muss, die 14 und mehr Jahre alt sind und dort sehe ich das andauernd.
Wie will man Laufzeiten korrekt einstellen, wenn die SPS eine Zykluszeit von 45ms hat, man das eine Signal aber um 32ms verzögern müsste.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mag sein, aber ich habe viele Anlagen an denen ich in unserem Bereich rumschrauben muss, die 14 und mehr Jahre alt sind und dort sehe ich das andauernd.
Wie will man Laufzeiten korrekt einstellen, wenn die SPS eine Zykluszeit von 45ms hat, man das eine Signal aber um 32ms verzögern müsste.

Ich denke nicht das der TE wissen wollte wie Merker vor 14 jahren eingesetzt wurden.
 
Und was ist wenn man morgen an einer Anlage rumbasteln muss die von 2001 ist? Und sich dann wenn man immer nur das macht was man schon immer gemacht hat, auf einmal dazu führt, dass nichts mehr funktioniert? Antriebe fahren zu lang, Positionen werden nicht mehr getroffen? Als ich vor Jahren angefangen hab, wär ich gleich bei meinem ersten Auftrag froh gewesen das zu wissen.
 
Zuletzt bearbeitet:
Zurück
Oben