Instanz DBs nur bedingt in den Arbeitsspeicher laden ?

leolilu

Level-1
Beiträge
17
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe SPS Freunde
wie ihr seht bin ich neu hier im Forum.
Ich ahbe beim rumstöbern feststellen können, das hier sehr viele Fachkundige Member anzutreffen sind, die sehr hilfreiche Tips geben.
Ich habe bei mir in der Firma zur Zeit ein Problem.
Ich bin beauftragt worden eine unserer Maschienen zu erweitern.
Es ist ein Kernschiessautomat (KSA 15) bei dem der Kernkastenspeicher erweitert werden soll.
Diese Prozedur hab ich shcon mehrmals durchgeführt, von 500 auf 1000, von 1000 auf 1200, von 1200 auf 1230.
Wie ihr sehen könnt werden die Schritte zum Ende immer kleiner und ich vermute ihr könnt euch schon denken waren...
genau... die 512kb Arbeitsspeicher der 317-2DP CPU (317-2AJ10-0AB0) stösst an seine grenzen.
Jeder Kernkasten besitzt 50 Datensätze, die über einen FB in den entsprechenden Instanz DB eingetragen bzw aus jenen IDB ausgelesen werden. Was bedeutet, aktuell 1230 IDBs mit je 50 Datensätzen, insgesammt 134 Bytes (Word und DINT), welche sich zur Laufzeit alle im Arbeitsspeicher befinden.

Nun meine Frage:
Lässt sich das irgendwie so lösen, dass die IDBs auf der 8MB MMC bleiben und nur in den Arbeitsspeicher geladen werden, wenn auf diese zugegriffen wird ?
Normalerweise werden dei Daten nur benötigt wenn ein Kernkasten neu eingetragen, editiert oder zur Verwendung aufgerufen wird.

Ich würde hier an der Stelle den Code posten allerdings umfässt dieser einige Seiten aber wenn jemand die Zeit und das Interesse hat sich näher damit zu befassen, kann ich den FB, entsprechende aufrufe und ein IDB Beispiel als PDF uploaden.

Vielen Dank schonmal für die Hilfe

LG Leo
 
jo...

Mit SFC83 (READ_DBL) und SFC84 (WRIT_DBL) kannst du DB welche nur auf der MMC sind lesen und in einen Arbeitsdb umkopieren, und diese später auch zurückschreiben!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie oft wird das "Rezept"gewechselt? sprich wieviele gleiche Teile? wenn du nur selten wechselst, dann kannst du auf MMC schreiben.

Aber was ich nicht ganz verstehe, warum 1230IDB´s??

Was ist mit Schreiben von Rezepten in TP / Visu?

Hilf mir Mal:
Du hast x Datensätze die jweils aus 50 Datensätzen bestehen die dein Rezept enthalten. OK
Sind das alles Realwerte oder was?

Und du musst für dieversen verschiedenen Formen (wieviel verschiedene?) jeweils 50 Datensätze vorgeben.

Warum werden die in IDB geschrieben?

sollte doch ausreichen:

ein DB in dem der aktuelle Datensatz als Arayy liegt, der wird bei Formänderung ausgewechselt.

Die Vorlagen liegen entweder in anderen DB´s, der Visu oder auf MMC, oder wo auch immer.

Bei Formwechsel werden die aktuellen Datensätze in den "aktuellen" DB kopiert (zb als Rezept von der Visu), fertig.
 
Mit SFC83 (READ_DBL) und SFC84 (WRIT_DBL) kannst du DB welche nur auf der MMC sind lesen und in einen Arbeitsdb umkopieren, und diese später auch zurückschreiben!

Ok, das bedeutet, ich müsste vorher alle IDBs (1230) als Unlinked markieren, damit deise im Ladespeicher bleiben ?
da diese aber vom FB3 erzeugt werden, und der FB3 die daten über INOUT ändert bzw drauf zugreift, kommt es da nicht zu problemen ?
also der FB3 wird für jeden Kernkasten aufgerufen, ob nun zum editieren oder zum Daten abrufen.
Das bedeutet also ich müsste die IDBs in globale umwandeln und rufe den FB3 nur mit einem IDB auf in diesen ich vorher die Daten des jeweiligen Kernkastens über deine genannten Befehle ablege und nach einer änderung wieder in den entsprechenden GDB auf die MMC lade ?
 
Ich versteh immer noch nicht warum IDB?

Aber Prinzipiell so wie du schreibst, in der CPU sind aktuell nur die Daten die du brauchst, die unbenötigten sind in den diversen DB´s die den jeweiligen Formen entsprechen, oder in einem "Grossen" DB in den jeweiligen Arrrays, aus dem du dann die der Form entsprechenden auf den jeweilig Aktuellen DB / IDB kopierst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
huhu nochmal
tut mir leid wegen der verspätung, hatte gerade feierabend und bin nun daheim :)

also:

Aber was ich nicht ganz verstehe, warum 1230IDB´s??

eine sehr sehr sehr gute Frage... die kann wahrscheinlich nur der Programmierer selbst beantworten
ich hätte das nicht so gelöst, weil ich 1230 IDBs einfach nur für Wahnsinn halte.
ich hab das Programm halt bisher auf die Art erweitert, wie es der Programmierer vorgesehen hatte
und das Programm umschreiben würde Unmengen an Zeit kosten und die Maschine auf den Stand der Erstinbetriebnahme zurücksetzen, was wiederum Ausfallzeiten bedeutet, die die 'gehobene Klasse' nicht begreift bzw nachvollziehen kann.

da nun aber der Speicher voll ist, bleiben nur die Möglichkeiten:
- neue CPU für rund 3-4k eu
- oder das Programm letztendlich doch anpassen

und ich versuche jetzt die schnellste und effektivste Methode zu finden, aus den Müll der mir vorgesetzt wurde irgendwas brauchbares zu machen :/

Was ist mit Schreiben von Rezepten in TP / Visu?

ich muss ehrlich sagen, mit diesem Thema hab ich mich noch nicht auseinander gesetzt, weil ich bisher nur an fertigen Projekten gearbeitet habe.
Die KSA15 wird über ein TP 177B bedient, was schon mal eine gute Voraussetzung darstellt denke ich.
Es wird mich allerdings viel Zeit kosten mich in die Thematik einzuarbeiten.


Hilf mir Mal:
Du hast x Datensätze die jweils aus 50 Datensätzen bestehen die dein Rezept enthalten. OK
Sind das alles Realwerte oder was?

Also es sind zum Beispiel Daten wie Schießdruck, Position Spannbacken, Begasungszeit, Schießkopfposition, etc.
Einige der Werte werden beim Einrichten das Kastens per Hand übers TP eingetragen, andere Daten kommen über Wegaufnehmer.

Wie oft wird das "Rezept"gewechselt? sprich wieviele gleiche Teile? wenn du nur selten wechselst, dann kannst du auf MMC schreiben.

Am Tag werd der Kasten etwa 5 mal gewechselt, neue Kästen werden ehr selten aufgenommen. Allerdings werden bei der Anwahl eines vorhandenen Kastens auch oft Werte geändert bzw korrigiert. Wie oft dabei auf die MMC geschrieben werden müsste kann ich leider nicht sagen.

Was ich aber mit Sicherheit weiß ist, dass die meisten der aktuell gespeicherten Kästen schon Monate oder Jahre nicht mehr benutzt wurden, diese Daten liegen also Sinnloserweise im Arbeitsspeicher.
Vieleicht macht es am meisten Sinn lange nicht benutzte DBs aus den Arbeitsspeicher in den Ladespeicher bzw aud die MMC zu verschieben.
Ließe sich dies mit IDBs realisieren ?

LG Leo


Ps.: danke für die bisher sehr hilfreichen und schnellen Antworten
 
Ja da könntest du ansetzen, bau mal was ein, wo du die letze Verwendung reinschreibst, dann nimm alles was länger wie x Tage nicht benutz wurde und schreib das auf die MMC raus (entsprechend Sichern nicht vergessen) Sichernmacht auch beim laufenden Programm wahrscheinlich Sinn!!!!!!)

grundsätzlich: never tuoch a running System, aber du stehst momentan voll an, Ich würde eine´n totalen Neuanfang bei deinem System mal andenken. Ich kenn zwar keine der zugrunde liegenden Probleme und kann auch nicht nachvollziehnen warum das so gelöst wurde, aber so wie du das beschreibst würde ich mal folgendes machen:

Auflistung der für die Funktion erforderlichen Parameter und der derzeitig in Verwendung stehenden Formen.

Analyse was wird aus bestehenden Daten jeweils 1:1 übernommen;
was wird bei jeder Form angepasst (ist das eventuel bei jeweils der selben Form das Selbe = sind vielleicht die ursprünglich vorgesehenen Parameter einfach falsch und es muss jeweils immer der Formentsprechend etwas geändert werden).

Wenn das entsprechend analysiert wurde: Überprüfung was ist besser -> beibehaltung bzw neue Harware mit bestehendem Programm oder Neuentwicklung eines Programms, das ev. wesentlich geringeren Speicherbedarf hat (zb. Analyse was is immer gleich / ähnlích, . . .) Ausnutzung von MMC / Visu, TP, Rezeptfunktion, . . .

eventuell die 10 meist verwendenten Formen in der CPU lassen und wenn eine der weniger benutzen Formen kommt, aus MMC oder Visu reinkopieren, wenn eine andere kommt, die Daten zurückspeichern und alles aus CPU verwerfen, dann die aktuelloen entweder aus CPU oder Visu neu reinkopieren / verwenden.

Grundsätzlich so wie du die Häufigkeit beschreibst, könntest du das auch mit dem bestehenden Lösen, nur die Daten in MMC reinschreiben / rauslesen, aber ich denke ihr steht einfach irgendwo an.

fg Winnman
 
Ok, das bedeutet, ich müsste vorher alle IDBs (1230) als Unlinked markieren, damit deise im Ladespeicher bleiben ?
da diese aber vom FB3 erzeugt werden, und der FB3 die daten über INOUT ändert bzw drauf zugreift, kommt es da nicht zu problemen ?
also der FB3 wird für jeden Kernkasten aufgerufen, ob nun zum editieren oder zum Daten abrufen.
Das bedeutet also ich müsste die IDBs in globale umwandeln und rufe den FB3 nur mit einem IDB auf in diesen ich vorher die Daten des jeweiligen Kernkastens über deine genannten Befehle ablege und nach einer änderung wieder in den entsprechenden GDB auf die MMC lade ?

Jo, denke so sollts gehen. Du solltest den FB halt nocht nicht mit dem Db aufrufen bis die Systemfunktion zurück gibt das sie fertig kopiert hat!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vielen Dank für die guten Vorschläge

ich werde diese Morgen auf Arbeit prüfen und schauen was für mich Sinn ergibt.

Hier noch eine Frage.
Was passiert wenn ich alle IDBs als unlinked markiere, bzw was müsste ich tun bevor ich den FB aufrufe ?
am besten mal am Beispiel:
Ich will Kernkasten 890 abrufen, Daten vom Kasten stehen im IDB 1090, welche als unlinked markiert ist, demnach nur auf der MMC liegt.
ich vermute wenn ich jetzt den FB3 mit IDB 1090 aufrufe würde die SPS in Stop gehen.
Also müsste ich vorher den IDB1090 in den Arbeitsspeicher kopieren, was dann wie funktionieren würde ?
Ich täte das so lösen, das ich die daten aus dem IDB1090 mit dem SFC83 in einem äquivalenten 'Platzhalter'-DB im Arbeitsspeicher kopiere. Ist der Ansatz so korrekt ?

LG Leo
(*schlafengeht*)
 
Ich will Kernkasten 890 abrufen, Daten vom Kasten stehen im IDB 1090, welche als unlinked markiert ist, demnach nur auf der MMC liegt.
ich vermute wenn ich jetzt den FB3 mit IDB 1090 aufrufe würde die SPS in Stop gehen.
Genau deshalb sollte (und kann ?) man IDB nicht UNLINKED machen, man kann aber den Inhalt von IDB ändern.

Um 2000 Maschinendatensätze (Rezepturen) zu nutzen braucht man nicht 2000 IDB sondern nur 1 IDB und eine "Datenbank"
(Rezepturspeicher). Bei jedem Kastenwechsel kopiert man per SFC83 die zugehörigen Maschinendatensätze in den einen IDB.
Man braucht nur "über" dem IDB eine Verwaltung (Rezepturliste) und eine Anzeige, was gerade in dem einen IDB enthalten ist.

Wenn Du nicht viel am Programm ändern willst, dann gehe zurück zu den 500 (oder weniger) IDB, die die häufigsten Kastendaten
enthalten. Einen IDB mache zu einem "Sonder-Kasten", in den lädst du bei Bedarf die Datensätze per SFC83 aus einem (oder
mehreren) globalen UNLINKED DB per SFC83. Dazu irgendeine Liste mit 2000 (editierbaren) Bezeichnungen der Kasten-Datensätze.
Dieses übergeordnete "Datensätze lesen" und ggf. speichern sollte relativ leicht mit einer einfachen Schnittstelle zum bestehenden
Programm zu programmieren sein.

Harald
 
Wenn an der Maschine ein Display mit Rezepturverwaltung ist, habt ihr irgendwas falsch gemacht. ;) Mach's neu. Sowas gehört in die HMI ggf. auch mit IPC und Datenbank.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich täte das so lösen, das ich die daten aus dem IDB1090 mit dem SFC83 in einem äquivalenten 'Platzhalter'-DB im Arbeitsspeicher kopiere. Ist der Ansatz so korrekt ?

LG Leo
(*schlafengeht*)


Jo denke schon.

Also Ich würde den FB einfach immer mit dem gleichen DB aufrufen, bei wechsel, den FB aufruf sperren, den alten DB rücksichern, den neuen DB in den instanzdb kopieren, den FB wieder freigeben!
 
Wenn an der Maschine ein Display mit Rezepturverwaltung ist, habt ihr irgendwas falsch gemacht. ;) Mach's neu. Sowas gehört in die HMI ggf. auch mit IPC und Datenbank.

Ich stimme dir da zu, allerdings bin ich Instandhalter und es ist weder meine Aufgabe unsere Maschinen neu zu Programmieren noch ist mir die Zeit für solch Projekt gegeben.

Die Lösung die für alle Beteiligten am unkompliziertesten ist, wäre :
Löscht 500 alte Kernkästen und nutzt den Platz für neue...

Nachteil dabei, es kann durchaus noch vorkommen, das die Alten doch nochmal benutzt werden.
Das Einrichten eines neuen Kastens nimmt in etwa 10 Minuten ein.
Man müsste hier nun abwägen ob es das Wert ist.

Fakt ist, das Grundproblem wird dadurch nicht gelöst.

Und da ich gerne Programmiere und so viel wie möglich darüber lernen will, gefällt mir die Änderung des Programms am besten.

PN/DP und Graph&SCL_Freak haben das Wort Datenbank erwähnt, was ist jetzt genau damit gemeint, im HMI, SPS oder extern (zB PC) ?

So wie ich euch verstanden habe könnte ich doch theoretisch alle Daten ab Kasten 1200 im TP177 ablegen und dem Programm einfach sagen, wenn Kastennummer über 1200 hole die Daten vom TP, oder ?

LG Leo


EDIT:
Mir fällt gerade noch was ein, da es ja nicht leicht ist unter 1230 Kästen den zu finden den man gerade braucht, wurde eine Suchfunktion Programmiert, die alle Kästen von 1 bis 1230 nach den eingegebenen Namen durchsucht.... ich vermute mal DBs die auf der MMC liegen lassen sich nicht nach Inhalten durchsuchen, heisst also sie müssen bei der Suche einer nach dem anderen in den Arbeitsspeicher geladen werden. Ich schätze das könnte eine sehr Zeitaufwendige Prozedur werden, oder ?
 
Zuletzt bearbeitet:
EDIT:
Mir fällt gerade noch was ein, da es ja nicht leicht ist unter 1230 Kästen den zu finden den man gerade braucht, wurde eine Suchfunktion Programmiert, die alle Kästen von 1 bis 1230 nach den eingegebenen Namen durchsucht.... ich vermute mal DBs die auf der MMC liegen lassen sich nicht nach Inhalten durchsuchen, heisst also sie müssen bei der Suche einer nach dem anderen in den Arbeitsspeicher geladen werden. Ich schätze das könnte eine sehr Zeitaufwendige Prozedur werden, oder ?

Da konntest du recht haben. Aber da kannst du dir ja noch einen extra DB anlegen, in dem von jedem DB der Name drinnsteht!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da konntest du recht haben. Aber da kannst du dir ja noch einen extra DB anlegen, in dem von jedem DB der Name drinnsteht!

Richtig! Wenn ich die 1230 DBs aus dem Arbeitsspeicher schmeiße bleibt ja für solche Kleinigkeiten mehr als genug Platz, hatte ich nicht bedacht...

Ich werde mich jetzt erstmal reinknien und schauen was bei raus kommt.
 
Zurück
Oben