Gibt es in s5 Einschränkungen für DB's

mega_ohm

Level-2
Beiträge
691
Reaktionspunkte
52
Zuviel Werbung?
-> Hier kostenlos registrieren
Folgende Hardware- Beschreibung:
- s5-CPU 115U 944B
+ Steckkarten (6ES5-523-3UA11) Adr.: 128
+ Steckkarten (6ES5-523-3UA11) Adr.: 144
+ AI- Steckkarte (6ES5-446-3LA11, 6SE5-491-0LB11) Adr.: 176 - ...
(ich würde meinen, mehrere analoge Eingänge gesehen zu haben. Ich habe das nicht weiter verfolgt. Mich interessiert z.Zt. nur PEW 176.)

Ich hatte mit dieser Anlage und Merkern, lt. E-Plan freien I/O
schon sehr viele "schöne Stunden". Deshalb habe ich mich entschlossen,
für all meine Änderungen an dieser Anlage überhaupt keine Merker mehr zu verwenden.
Ich möchte zukünftig, so wie es mit s7 wunderbar funktioniert, "meinen Kram" in einem eigenen, neuen DB ablegen.
Meine Fragen:
- Ist es in s5 bedenkenlos möglich, z.B. Flankenmerker in DB's zu schreiben/ lesen ?

- Ich habe mal irgendwo gelesen, das DB 0 und DB 1 in s5 für systeminterne Zwecke belegt sind. Ist es in Ordnung, wenn "mein" DB also z.B. der DB 2 ist ?

- Hat jemand noch ein komplettes s5- Kompendium ? Ich konnte mittels Google und bei Siemens nix Gescheites mehr zu dem Thema finden.

- Ist eine CPU- Auslastung von 99,87% ( ich bin daran sicher mit meinen ca. 30 Zeilen AWL nicht Schuld ) in irgendeiner Art problematisch ? Sollte ich irgendwas beachten oder (ohne das eigentliche Programm, welches ich nicht geschrieben habe, komplett umstricken zu müssen) ausführen müssen ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meine Fragen:
- Ist es in s5 bedenkenlos möglich, z.B. Flankenmerker in DB's zu schreiben/ lesen ?

- Ich habe mal irgendwo gelesen, das DB 0 und DB 1 in s5 für systeminterne Zwecke belegt sind. Ist es in Ordnung, wenn "mein" DB also z.B. der DB 2 ist ?

- Hat jemand noch ein komplettes s5- Kompendium ? Ich konnte mittels Google und bei Siemens nix Gescheites mehr zu dem Thema finden.

- Ist eine CPU- Auslastung von 99,87% ( ich bin daran sicher mit meinen ca. 30 Zeilen AWL nicht Schuld ) in irgendeiner Art problematisch ? Sollte ich irgendwas beachten oder (ohne das eigentliche Programm, welches ich nicht geschrieben habe, komplett umstricken zu müssen) ausführen müssen ?
1. kannst du tun, ist aber sehr umständlich, da du in der 115er (ausnahme ist die 945) die datenbits nicht mit = ansprechen kannst
U e0.0
a db2
= d1.0 //das geht nicht
SU d1.0 //das geht. su ist aber nicht vke-abhängig

2.db2 ist ok

4.ja das könnte problematisch werden. wenn du eine änderung machst und den baustein überträgst, wird der zunächst in den noch freien speicher in ag geschrieben. dann wird im ag die startadresse zu diesem baustein geändert. wenn du komprimierst, wird der nicht mehr speicher freigegeben. d.h. es kann sein, das du den zu überschreibenden baustein vorher löschen musst um den neuen überhaupt übertragen zu können.
 
Was für ein Problem hast Du denn eigentlich mit den Merkern?

Ich arbeite in der S5 oft so, dass ich Daten in einem DB "parke".
Am Beginn eins Bausteins Daten vom DB in Merker umkopieren, im Baustein mit Merkern arbeiten, am Ende wieder zurückkopieren.
Die Technik kommt noch aus Zeiten, als Merker noch sehr begrenzt waren.
Hat vor allem Vorteile, wenn eine Anlage aus mehreren gleichen Baugruppen besteht, dann kann man immer die gleichen Merker nehmen.
 
Was für ein Problem hast Du denn eigentlich mit den Merkern?
Ich hatte früher in dem Progi schonmal in der Querverweisliste alle Merker anzeigen lassen. Lt. dieser Liste war MW 236 das letzte verwendete MerkerWord. Ich nahm also MW 250 und schon funktionierte ein Manipulator nicht mehr, verlor immer seine Referenzpositionen. Deswegen wollte ich dieses Mal einen neuen DB, in den ich alles reinschreibe, was ich brauche. Da ich auch Bits schreiben wollte ( in einem vorhergehenden Kommentar wurde ich noch rechtzeitig darauf hin gewiesen, daß das nicht funktioniert ) hatte ich also diesmal Folgendes zurecht getippt:
Code:
A DB 2
L MW 250
T DW 6
...
...
und zum Schluß
...
L DW 6
T MW 250
A DB 100 // dieser wird dann vom nächsten NW im Orginalprogi verwendet

Soweit hat alles gepaßt, bis auf die Kleinigkeit, daß der Manipulator einmal
über einen Initiator gefahren ist. Ich war nicht mehr vor Ort ( es ist erst mehrere Stunden später passiert ), so daß ich jetzt noch nicht weiß, ob es an meiner Progi- Änderung lag, oder tatsächlich der Schaltabstand zum Ini einfach zu weit eingestellt war oder sonstwelche ganz "normalen" Dinge, die ein Ini eben manchmal so nicht macht.

L DW 6 lädt doch ein Word aus dem geöffneten Datenbaustein ?
Also kann ich dieses doch auch auf ein MW transferieren ?

Oder müßte es richtig lauten:
L DW 6
T MB 250
L DW 7
T MB 251 :confused:

Oder könnten andere programm. Ursachen für den einmaligen "Hänger"
die Ursache sein ? Vor der Änderung gab es keine Probleme, ich habe keine Änderungen ( zumindest nicht wissentlich ) am Manipulator vorgenommen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code:
L DW6
T MW250

ist schon richtig, sonst wäre es

Code:
L DR6
T MB250
L DL6
t MB251

Ob jetzt links und rechts richtig ist, dafür übernehme ich keine Gewähr, steht ja hier auch nicht zur Diskussion.

Gruß
 
L DW 6 lädt doch ein Word aus dem geöffneten Datenbaustein ?
Also kann ich dieses doch auch auf ein MW transferieren ?

Oder müßte es richtig lauten:
L DW 6
T MB 250
L DW 7
T MB 251 :confused:

Oder könnten andere programm. Ursachen für den einmaligen "Hänger"
die Ursache sein ? Vor der Änderung gab es keine Probleme, ich habe keine Änderungen ( zumindest nicht wissentlich ) am Manipulator vorgenommen.
fakt ist:
wenn du ein byte lädst und dieses in ein word transt wird der rest mit 0 gefüllt.
wenn du ein word in ein byte transt wird das nur brauchbar klappen, solange du unter dem wert 128 bleibst (vorzeichen beachten)
 
CPU-Auslastung ???

Hallo,

mega_ohm schrieb:
Ist eine CPU- Auslastung von 99,87% ( ich bin daran sicher mit meinen ca. 30 Zeilen AWL nicht Schuld ) in irgendeiner Art problematisch ?

Was meinst Du mit CPU-Auslastung ??
Oder doch eher Speicherauslastung :confused:

Gruß

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So ein Zufall ..

Hallo,

mega_ohm schrieb:
Code:
A DB 2
L MW 250
T DW 6
...
...
und zum Schluß
...
L DW 6
T MW 250
A DB 100 // dieser wird dann vom nächsten NW im Orginalprogi verwendetSoweit hat alles gepaßt, bis auf die Kleinigkeit, daß der Manipulator einmal

Das ist normalerweise in Ordnung, aber ...
Je nach CPU und den Systemeinstellungen können Bausteine auch durch Interrupte unterbrochen werden. Wenn dann z.B. S5 Standard Hantierungsbausteine im Interrupt aufgerufen werden (und diese HTB's verwenden die Merkerbereiche MW 200-254), musst Du auch in der Interruptbearbeitung die MW sichern, sonst hast Du tatsächlich ganz tolle und schwer nachvollziehbare Nebeneffekte. Im Handbuch der von Dir verwendeten S5-115U gibt es ausdrücklich Hinweise dazu.

Gruß

Question_mark
 
Zuletzt bearbeitet:
Korrigiert mich bitte, wenn ich das falsch sehe, aber der Code
von mega_ohm hat doch lediglich den Effekt, einen
Schmiermerker vor seinem Code zu sichern und
nachher wieder zu restaurieren. Was andere Funktionen
damit anstellen bleibt immer noch ungewiss...

Umgekehrt wird m.E. ein Schuh draus:

Code:
A DB 2
L DW 6 // gesichertes Merkerwort laden
T MW 250
...
...
und zum Schluß
...
L MW 250
T DW 6  // Merkerwort wieder sichern
A DB 100 // dieser wird dann vom nächsten NW im Orginalprogi verwendet
 
@argv_user

So seh ich das auch!
Kommt aber drauf an, was er machen will!
Wenn er den Inhalt von DW 6 bitweise verarbeiten will (MW 250 also als Schmiermerker), dann hast Du recht.


@Question_mark:
Oder Interrupts in diesem Baustein einfach sperren, falls möglich!

@Mega_ohm
Hast Du da vielleicht die Bits verwechselt von MB 250 und MB 251?
Obwohl, wenn Du das NUR im MW 250 bearbeitest und ansonsten die Werte
im DB nur speicherst kann Dir da nix passieren.

Ansonsten sollte es mit MW 250 keine Probleme geben.

Vielleicht wird das MW 250 an anderer Stelle im Programm aber so aufgerufen, dass es nicht in der Querverweisliste auftaucht!
Z.B. als indirekte Adressierung?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Korrigiert mich bitte, wenn ich das falsch sehe, aber der Code
von mega_ohm hat doch lediglich den Effekt, einen
Schmiermerker vor seinem Code zu sichern und
nachher wieder zu restaurieren.
Genau das ist der Plan.
Ich brauche ein Word oder besser 16 Bits für Flanken, Verknüpfungen etc.
Erst wollte ich diese, so wie es in s7 möglich ist, direkt in den DB 2
schreiben, was aber nicht geht.
Also brauche ich wieder ein Merkerword.:???:
Ich wollte mir also ein Freies suchen, aber außerhalb des Schmiermerkerbereich ist nix mehr frei. Also war meine Idee eben dieses MW 250, weil es in der Querverweisliste nicht auftaucht.
Ich hatte schon einmal in Merkern des SM- Bereichs rumgekritzelt ( die waren auch nirgends angezeigt ), hatte diese aber vorher nicht gesichert und es ging schief. Diesmal dachte ich, es wäre anders, weil ich ja das MW 250 sichere, danach erst manipuliere, den Kram in meinem DB sichere und danach das MW 250 wieder zurückschreibe.

Würde denn meine Überlegung richtig sein, sobald ich mir ein "schöneres"
MW außerhalb des Schmiermerkerbereichs aussuche ?
 
Hallo

Wenn Du Probleme mit Merker hast, kannst Du auch nicht genutzte Ausgänge nehmen. z.B. Dein Programm braucht A0.0 bis A 70.0 ....dann nimm AW 80 bis Ende als Merker.
Mit Ausgängen und Eingängen kannst Du identisch wie mit Merker hantieren.
Mehrere Male gebraucht in Notfall.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Diesmal dachte ich, es wäre anders, weil ich ja das MW 250 sichere, danach erst manipuliere, den Kram in meinem DB sichere und danach das MW 250 wieder zurückschreibe.

Du willst doch eigentlich nur auf das sichere Wort aus dem DB
bequem zugreifen. Das kopierst du zu Beginn der Funktion
in einen Schmiermerker, werkelst damit rum, und am Ende
speicherst Du das Schmiermerkerwort wieder in den DB.
So kann jeder andere den Schmiermerker benutzen, Dich
braucht es nicht zu kümmern.

Nur hast Du die Mimik gerade falschrum programmiert.
Ich habe dazu einen Verbesserungsvorschlag gemacht,
den solltest Du nochmals durchlesen...
 
Du willst doch eigentlich nur auf das sichere Wort aus dem DB
bequem zugreifen. Das kopierst du zu Beginn der Funktion
in einen Schmiermerker, werkelst damit rum, und am Ende
speicherst Du das Schmiermerkerwort wieder in den DB.
So kann jeder andere den Schmiermerker benutzen, Dich
braucht es nicht zu kümmern.

Nur hast Du die Mimik gerade falschrum programmiert.
Ich habe dazu einen Verbesserungsvorschlag gemacht,
den solltest Du nochmals durchlesen...
Ich brauche ein Merkerword, weil ich in meinem DB nicht bitweise schreiben kann.
Also nehme ich mir ein Merkerword ( ich habe mich jetzt für MW 150 entschieden ), sichere das auf DW 6 in meinem DB 2.
Danach kritzle ich ich in dem MW 150 rum, habe meine Flankenmerker, SR-merker etc. Dann setze ich meine Ausgänge, manipuliere in anderen Datenbausteinen noch ein bischen und schreibe danach für das Originalprogi das MW150 aus meinem DB 2 DW6 wieder zurück. Ich habe dafür einfach ein zusätzliches NW eingefügt.

Was ist an meiner Logik falsch :confused:

PS.: Übrigens war gestern wirklich der Ini "Schuld". Ich habe aber trotzdem MW 150 genommen. Mit den Hantierungsbausteinen und Interrupts wollte ich mich nicht rumärgern. Wenn sporadisch irgendwelche Fehler auftreten, sucht man sich meistens tot, das will ich nicht riskieren.
 
Was ist an meiner Logik falsch :confused:

Tja, es geht um MW 250, nicht um 150.
Das ist ein Schmiermerker, da kann jeder machen mit was er will.
Einen solchen Merker in einen DB zu sichern und hinterher
wieder herzustellen gibt eigentlich keinen Sinn.
Ich dachte eher, Du willst den Merker sichern, dass er
im nächsten Zyklus noch da ist...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1. die s5 bietet noch nicht den komfort der s7 - das handling von dbs ist nicht so einfach. zugriff auf datenbits kann von der 115er serie nur die 945


2. grundsätzlich sollte bei deinem schniermerkerding vielleicht unten nochmal der db2 geöffnet werden - oder werden keine anderen dbs in dem code dazwischen geöffnet?


3. wenn du - egela welches - mw erst in einen db sicherst und später die sicherung aus dem db wieder reinkopierst, dann kannste das bestenfalls als schmiermerker nutzen weil deine daten ja nicht bis zum nächsten zyklus erhalten bleiben --> also nix da mit flankenhilfsmerker.

du must das andersrum angehen.

a) tranfseriere ein dw6 (oder weiß der teufel welches) in irgendein schmiermerkerwort

b)arbeite mit dem schmiermerkerwort

c) sichere das schmiermerkerwort wieder in dw6 damit deine daten dort bis zum nächsten zyklus bleiben, da werden sie wieder gebraucht!


habe mir jetzt nicht alles genau angesehen auf den zwei seiten, aber das scheint dein problem zu sein?
 
das habe ich anders verstanden

es hat wohl folgenden Ablauf
1. Sichern des Schmiermerkerworts
2. Schreiben der eigenen Informationen in den Schmiermerkerbereich
3. Eigener Programmablauf
4. Sichern der eigenen Informationen im Datenbaustein
5. Zurückschreiben des Schmiermerkerwortes
 
Tja, es geht um MW 250, nicht um 150.
Das ist ein Schmiermerker, da kann jeder machen mit was er will.
Einen solchen Merker in einen DB zu sichern und hinterher
wieder herzustellen gibt eigentlich keinen Sinn.
Ich dachte eher, Du willst den Merker sichern, dass er
im nächsten Zyklus noch da ist...
Hmmm...:confused:

Ich habe geschrieben, daß ich mich ( vielen Dank an Alle, die an dieser Diskussion teilnahmen ) für MW 150 schlußendlich entschieden habe.
Meine Progi-änderung [eigentlich >>> Einfügung <<< in ein bestehendes Progi] läuft seit mehr als 11h immer noch sorgenfrei. Ich weiß, daß das noch gar nichts bedeutet. Manche Sorgen ( ich habe es selbst erlebt ) können sogar nach mehr als 4 Jahre erstmalig auftreten.

Der Grund für die Entscheidung für MW 150 ist ganz einfach !
Ich bin schreibfaul !
alt: MW 250 => Neu! => MW 150
= Ziel erreicht ( den Schmiermerkerbereich nicht mehr verwendet)

Mir wurden mögliche (!) Probleme, die im Schmiermerkerbereich auftreten könnten, zumindest für mich überzeugend erklärt.
Deswegen habe ich mich danach spontan für ein anderes MW (MW 150) mit der gleichen 'Mimik' entschieden.
Code:
A DB 2           // DB 2 öffnen
L MW 150      // MW 150 ist neu... wird vor 'meinen Ideen' geladen
T DW 6         // MW 150 wird in DW 6 gesichert
...
<texte texte> // Hier verwirkliche ich meine Gedanken
 
...
L DW 6         // dort habe ich den Zustand von MW 150 vor
                  //  meinen 'Künsten' gesichert !
T MW 150     // MW150 wird in den "Originalzustand" zurückgeschrieben
A DB 100      // dieser wird dann vom nächsten NW im [B]Orginalprogí[/B]
                  // weiter verwendet.


Ich habe alle Komentare zu diesem Thema gelesen.
z.B.: DB's bitweise schreiben.... in s5 geht nicht !

Ich hatte es gelesen, hatte keine Möglichkeit, es über das Wochenende zu ändern. Geschrieben war es, ich wußte es vorher ja nicht besser... "DRAMA"

Um es auszutesten, habe ich vom "lebenden Objekt" (der Anlage) vorher eine Masch.Kopie erstellt, meine Änderungen nach diesem Tipp entsprechend geändert, aber einen bitweisen Zugriff 'stehen' lassen => Die CPU ging in 'Stopp'
'Dolle Show'.:ROFLMAO:

Der Ausfall der Produktionsanlage ( da diese gerade auf ein anderes Produkt umgebaut wurde ) war vernachlässigbar.

PS: !!! Ich habe gelernt, Schmiermerker zu hassen !
 
Zurück
Oben