Struct-Daten im Multiinstanzbaustein

[JanB1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute

SO, kleine Problem bei dem ich gerade nicht weiterkomme.

Ich habe einen Baustein der intern mit Struct-Daten arbeitet. Nun hat mein Vorgänger für jede Maschine einen einzelnen Baustein gemacht und die Struct-Daten jeweils einzeln intern aufgerufen, das sieht so aus wie unten:

PROGRAM Maschine1

VAR
iWeight:  INT;
END_VAR

iWeight := Maschine1.var1

PROGRAM Maschine2

VAR
iWeight:  INT;
END_VAR

iWeight := Maschine2.var1

PROGRAM Maschine3

VAR
iWeight:  INT;
END_VAR

iWeight := Maschine3.var1

PROGRAM Maschine4

VAR
iWeight:  INT;
END_VAR

iWeight := Maschine4.var1

Nun wollte ich fragen ob man denn diesen Struct-Datenabruf auch ausserhalb einstellen kann, also an einem Bausteineingang den Namen der Maschine angeben und auf Grund dieser Angabe wird dann der zugehörige Datenpunkt abgerufen. Also anstatt dem oben einfach:

FUNCTION_BLOCK Maschine
VAR_INPUT
sMaschine:  STRING;
END_VAR
VAR
iWeight:  INT;
END_VAR

iWeight := Maschine.var1

Problem hier ist halt dass er dann nach der Variable "var1" des Structs mit dem Namen "Maschine" sucht (welche aber gar nicht definiert ist). Ich hab schon an ein Zusammenführen der Strings gedacht, aber das funktioniert auch nicht...

Irgendwie muss das doch gehen, ich komm nur nicht drauf wie...

(Ähm...tschuldigung für die etwas flapsige Ausdrucksweise, keine Ahnung wie ich das hier besser erklären soll)

 

[Verpolt]

FUNCTION_BLOCK Maschine
VAR_INPUT
sMaschinenNr:  INT;
END_VAR
VAR
iWeight:  INT;
END_VAR

iWeight := Maschine[sMaschinenNr].var1

Vielleicht so

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du könntes zunächst Deine Daten in einem ARRAY (ARRAY OF STRUCT) in nur einem DB zusammenfassen, dann könntest Du so schreiben:

VAR_INPUT
  iMaschine:  INT;
END_VAR
VAR
  iWeight:  INT;
END_VAR

  iWeight := Maschine[iMaschine].var1

Wenn Du einen FUNCTION_BLOCK schreibst, kannst Du aber auch 4 Instanzen des FB deklarieren und beim Aufruf der Instanzen jeweils einen anderen STRUCT mitgeben. In dem FB greifst Du dann immer gleich zu:

VAR_IN_OUT
  IOData:  Maschinendatensatz;
END_VAR
VAR
  iWeight:  INT;
END_VAR

  iWeight := IOData.var1

Du könntest die Maschinendaten auch gleich in die Instanz integrieren (in VAR) und bräuchtest die dann nicht übergeben.

Harald

 

[JanB1]

Danke euch beiden schon mal für die Idee mit dem Array. Mal schaun ob ich das so nutzen kann.

Du könntes zunächst Deine Daten in einem ARRAY (ARRAY OF STRUCT) in nur einem DB zusammenfassen, dann könntest Du so schreiben:
Wenn Du einen FUNCTION_BLOCK schreibst, kannst Du aber auch 4 Instanzen des FB deklarieren und beim Aufruf der Instanzen jeweils einen anderen STRUCT mitgeben. In dem FB greifst Du dann immer gleich zu:

VAR_IN_OUT
  IOData:  Maschinendatensatz;
END_VAR
VAR
  iWeight:  INT;
END_VAR

  iWeight := IOData.var1

Du könntest die Maschinendaten auch gleich in die Instanz integrieren (in VAR) und bräuchtest die dann nicht übergeben.

Da sieht definitiv in etwa so aus wie ich das gerne hätte. Hmm...muss es denn unbedingt ein IN_OUT sein oder tuts auch ein IN?

Und wie meinst du das mit der in die Instanz integrieren? Also fest reinschreiben von welcher Maschine er die Daten verwenden soll? Das ist ja genau das was ich eigentlich nicht mehr will weil ich ja dann 4 mal das gleiche Programm hätte mit nur einer kleinen Änderung.

Und war da nicht mal was mit dem Strukturierten Programmieren dass man sich so wenig wie möglich wiederholen soll?

 

[JanB1]

Okay Harald, danke viel mals. Hab's getestet, funktioniert (natürlich auch nur mit nem Input. Hervorragend. So mag ich das. Und wusch, das ganze Riesen-Programm wird um drei Viertel kleiner (der vor mir war n Depp, alles Fest programmiert und jeden Baustein für jede Maschine noch mal einzeln kopiert. Dadurch wurde das Programm vier mal so gross wie nötig. :sb7

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

der vor mir war n Depp

Hmm, vielleicht bist auch Du der Depp, weil Du noch nicht 'rausgefunden hast, warum "der vor Dir" sich entschieden hat, das Programm genau so zu schreiben?

Ist Dir schon aufgefallen daß Deine genial kurze Programmversion langsamer ist als die originale Version mit den "unnötigen" Programmteilen? Hast Du mal die Zykluszeiten verglichen? Kommst Du nun vielleicht in einen für die Maschinen ungünstigen Bereich?

Waren die Maschinendaten vorher in jeweils eigenem DB? Ist da vielleicht noch ein HMI, was alle 4 Maschinen bedient? Vielleicht kann man bei dem HMI die Variablen nur DB-multiplexen?


Apropos Depp: Wo ist eigentlich mein vorheriger Beitrag geblieben? Hab' ich den echt nicht abgeschickt?
Dann nochmal sinngemäß:

VAR_INPUT geht auch. Dann wird die Struktur vor dem Aufruf des FB zunächst in die Eingangsstruktur kopiert.
Bei VAR_IN_OUT wird nur die Adresse der original-Struktur übergeben, ohne zu kopieren. Der FB arbeitet dann direkt mit den original-Daten, die Adressberechnungen für jeden Zugriff sind aber aufwendiger.

Harald

 

[Verpolt]

gelöscht...

wie man sieht

 

[JanB1]

Nein, der vor mir war definitiv ein Depp.

Wir programmieren auf ner Wago SPS, er hat die Bausteine nicht spezielle aufgerufen sondern einfach immer alle aufgerufen als Programme, nicht als funktionsbausteine. Das Programm ist langsam, der General_Reset funktioniert nicht richtig und der Reset für die einzelnen Maschinen resettet in gewissen Fällen auch andere. Die Webvisu schmiert regelmässig ab, er hat hunderte Zeiten (TON und TOF) genutzt, die Variablendeklaration ist nicht einheitlich, er hat teilweise unsinnige mathematische Operationen (Fall 1: "nti1 wird per move in int2 geschrieben, danach wird int1 von int2 subtrahiert, daraus resultiert int3 und mit diesem Wert arbeitet er weiter", Fall2: "int1 wird von int1 subtrahiert und das Ergebnis wird in einen Integer geschrieben um diesen auf null zu setzen" und das sind nur zwei Fälle von vielen in ein und dem selben Baustein). Der Herr hat zum Tarieren eines einzelnen Real-Werts einer Wage ein riesiges Programm geschrieben und nach Absprache mit dem Auftraggeber und gründlicher Analyse des CFS-Programmes meinerseits mit einem weiteren Entwickler sind wird zum Schluss gekommen dass die hälfte des Programmes relativ unnütz ist, respektive man diese hälfte stark vereinfachen kann.

Und ja, ich habe alle Eventualitäten berücksichtigt, es ist wirklich viel unnützer Code drinnen.

Und von der Dokumentation fang ich jetzt nicht an...

:sb6: