Step 7 Verständnisproblem Instanz-DB

Chris_Rgb

Level-2
Beiträge
39
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wir haben bei uns in der Firma einige neue Anlagen bekommen und ich soll mich von IH Seite um die S7 Projekte kümmern.
Jedoch hab ich in einigen FBs eine Programmierung gefunden deren Sinn ich nicht nachvollziehen kann.

An den FB gibt es eine In-Variable vom Typ INT an die immer die Nummer des Instanz-DB des jeweiligen Aufrufs parametriert ist.
In jedem Netzwerk sind die ersten Anweisungen:
L #i_DB_number
T #t_INDEXWORD
AUF DB [#t_INDEXWORD]

Anschliessend wird meist ganz normal über die Symbolik auf die In/Out/Stat zugegriffen.
Teilweise wird aber auch über direkte Zugriffe in den Instanzen gelesen und geschrieben.

Eine meiner Meinung nach abartige, undurchsichtige Programmierung und ich soll jetzt rausfinden wieso sporadisch bestimmte Fehler nicht gemeldet werden.:evil:

Könnte es sein, das eine nicht sauber Programmierte Temperaturregelung im OB35 den Programmierer zu diesem Konstrukt bewegt hat, oder aber ein Konverter sowas aus einem S5 Baustein gezaubert hat.

Gruß Christian
 
Code:
L #i_DB_number
T #t_INDEXWORD
AUF DB [#t_INDEXWORD]

Aha interessant. Für Berechnungen mit irgendwelchen Datenfeldern braucht man so was unter umständen, könnte man aber auch noch anders machen.
 
Hallo,

wir haben bei uns in der Firma einige neue Anlagen bekommen und ich soll mich von IH Seite um die S7 Projekte kümmern.

Gruß Christian


Lass dir das doch von dem Programmierer erklären wenn es sich um eine neue Anlage handelt.
Meiner Meinung nach ist das nicht nur schlechter sondern sehr schlechter Programmierstiel.

Du kannst ja mal einfach die direkten Zugriffe durch die Symbolischen ersetzen. Vielleicht ist es dann ein wenig leichter zu verstehen oder du kommst drauf warum dies so gemacht wurde.
Vielleicht wollte der/die ProgrammiererIn auf Speicherbereiche zugreifen die Symbolübergreifend sind (zb einzelnes Bit aus Byte) machen, aber keine Ahnung von indirekter Adressierung und des Datenbausteinregisters hat.
 
Wenn wirklich nur Instanzmäßig über IN/OUT/STAT zugegriffen wird oder direkt auf die Instanz (z.B. DIW, DIX und Co.),
dann sind die 3 Zeilen entweder total aus dem Zusammenhang gerissen, oder quasi bedeutungslos.

Ohne Gesamtzusammenhang = vollständigen Baustein ist das ganze eine eher philosophische Frage.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich verstehe nicht wieso man die Instanz-DB Nummer sogar noch händisch eintragen sollte.
Falls man den Baustein z.B. in CFC aufrufen würde müsste man ständig die IDB-Nummern anpassen.
Sollte man die Nummer programmtechnisch wirklich brauchen, würde ich zumindest
Code:
L #i_DB_number
durch
Code:
L DINO
ersetzen
 
Na ja, ich habe sowas auch schon gemacht.
Man braucht es doch sogar, um 'indirekt' zu adressieren. Zum Beispiel habe man 30 Objekte vom Typ "Achse". Diese Objekt haben jeweils einen Datenbaustein.
In dem will man den Wert für einen Softwareendschalter speichern. Und da man faul ist, will man für 30 Achsen nicht 30 mal den Baustein zu allen Objekten aufrufen, sondern sagt dem Standard-Baustein "Softwareendschalter" zum Einen als Eingangswert "E_Achsnummer" in welchen DB er es schieben soll und meinetwegen mit dem Eingang "E_Tu_es" schreibt man den gewünschten Wert in die dafür vorgesehene Adresse unseres DBs der richtigen Achse.
Und da ist der einzige Weg, den ich dafür kenne ist der Umweg über das Wandeln in ne Word und mit AUF den Datenbaustein AUFSCHLAGEN. Heißt glaub wirklich so...
So, und wenn der DB schon mal aufgeschlagen ist, kann man danach per
L E_NeuerSoftwareendschalter
T DBD34 (oder wohin auch immer)
übertragen.
Das DBD34 kann jetzt auch aus einem Pointer bestehen, oder wie auch immer.
Oder wie kann man das sonst lösen?

Ganz klar, finden tut man das über die Referenzdaten nicht, sollte man suchen wo denn der Wert in DBx.DBD34 verdammt nochmal her kommt. ...
 
Man könnte in dem DB einen UDT "ACHSE" anlagen, und diesen UDT an einen IN_OUT Achse anhängen.

Vorteil: Vollsymbolisch + Referenzdaten.

Grüße

Marcel
 
Beispiel:

DB1 "ACHSDB"
UDT1 "ACHSE"

Im UDT1 definierst du die Variablen für eine Achse, dort steht z.B.
Code:
HANDBETRIEB BOOL
AUTOMATIKBETRIEB BOOL
ENDLAGE_GS BOOL
ENDLAGE_AS BOOL

Im DB1 steht dann

ACHSE1 UDT1 (UDT1 kann auch Symbolisch als "ACHSE" angezeigt werden
ACHSE2 UDT1
ACHSE3 UDT1
...

Dein Baustein bekommt nen IN_OUT vom TYP UDT1 ("ACHSE") der z.B. IO_ACHSE heißt.

Nun kannst du z.B. DB1.ACHSE1 an deinen IN_OUT am Baustein schreiben, und intern dann
so darauf zugreifen

Code:
UN IO_ACHSE.ENDLAGE_GS
U IO_ACHSE.AUTOMATIKBETRIEB
= WASAUCHIMMER

Wenns etwas detailierter werden darf schicke ich gern auch Screenshots (Dann aber SCL).
Grüße

Marcel
 
Coole Sache! Danke für den Tipp!
Das Beispiel mit der Achse war in meinem Fall etwas bei den Haaren herbei gezogen, da unsere 'Achsen' generierte (Technologie)Objekte sind, an denen man nichts ändern kann, aber mir fallen schon jetzt ein paar Möglichkeiten ein, bei denen ich deine Lösung einsetzen möchte.

Cheers!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich nutze es für Wiederkehrende Objekte wie z.B. Zylinder, Motoren (Drehzahlgeregelt),

Aber auch mal für eine komplexe Schnittstelle, für die ich nicht extra tausend Variablen an einen Baustein anknüpfen will.

Grüße

Marcel
 
Ach so, wurde jetzt eigentlich Chris_Rgb geholfen? ...

Der AUF-Befehl ist evt. schon sinnvoll, danach symbolisch zu adressieren, wie du auch schreibst, nicht.
Zugriffe auf den Instanz-DB darüber zu adressieren macht für mich spontan mal gar keinen Sinn.
Aber vielleicht solltest du mal die entsprechende Passage veröffentlichen, dann wirds vermutlich klarer.
 
Sorry das ich mich so lange nicht gemeldet habe.

Die Programmierer zu kontaktieren wird schwierig - Maschinenbauer pleite:-x
Kein Wunder bei der Programmierung:p

Ich hab immer noch den Verdacht, das die Temp-Regel FB's im OB35 mit der Sache zu tun haben.
Wie verhält sich die S7 nach einem FB Aufruf im OB35, werden automatisch wieder die alten DB und IDB nach beenden des OB35 aufgemacht oder müssen die händisch im OB35 gesichert und wieder hergestellt werden?

Soweit funktioniert es ja, ist nur furchtbar zu lesen und zu verstehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich würde mal sagen von wo man einen FB aufruft ist ziemlich egal. Da der OB 35 aber ein zeitgesteuerter OB ist, sollte (MUSS) die Abarbeitung des FB's beendet sein, bevor der OB wieder getriggert wird, sonst wird es wahrscheinlich in die Hose gehen.

Gruss

Oliver
 
Sorry das ich mich so lange nicht gemeldet habe.

Die Programmierer zu kontaktieren wird schwierig - Maschinenbauer pleite:-x
Kein Wunder bei der Programmierung:p

Ich hab immer noch den Verdacht, das die Temp-Regel FB's im OB35 mit der Sache zu tun haben.
Wie verhält sich die S7 nach einem FB Aufruf im OB35, werden automatisch wieder die alten DB und IDB nach beenden des OB35 aufgemacht oder müssen die händisch im OB35 gesichert und wieder hergestellt werden?

Soweit funktioniert es ja, ist nur furchtbar zu lesen und zu verstehen.


Nein du muss die alten DB und IDB nummern nicht speichern und wieder herstellen.
Wenn ein OB höherer Priorität aufgerufen wird, dann wird der Stack des zu unterbrechenden OB's gespeichert und nach beenden des höher prioren OB's wieder hergestellt.


Hallo,

ich würde mal sagen von wo man einen FB aufruft ist ziemlich egal. Da der OB 35 aber ein zeitgesteuerter OB ist, sollte (MUSS) die Abarbeitung des FB's beendet sein, bevor der OB wieder getriggert wird, sonst wird es wahrscheinlich in die Hose gehen.

Gruss

Oliver

Der OB35 muss abgearbeitet sein bevor er wieder aufgerufen wird. Ansonsten wird der Zeitfehler-OB (OB 80) gestartet.
 
Danke, gut zu wissen das es so ist wie es sein sollte;)

Was noch sein könnte, diese Bausteine sind angeblich "gewachsene Standardbausteine", das sie durch ein Übersetzungstool aus einem S5 Projekt entstanden sind.
Aber selbst dann sollte man den Standardprogrammierer:sm10::sm10::sm10:.
Bei einer 317er und ca. 10 Temperaturregel FB Aufrufen im OB35 (nur Vergleicher kein PID) und 100ms für den OB35 sollte es keine Zeitprobleme geben.

@godi Danke
 
Zurück
Oben