TIA Bin ich der Einzige der wirklich zufrieden ist mit TIA ?

RogerSchw85 · 27 April 2015

@miasme

Das klingt nach einem Umfangreichen Program. Was hast du für eine Steuerung?

Wie lange hast du dich mit den neuen Steuerungen befasst um das so hinzukriegen?

Ich finde SETIO und GETIO sehr schöne funktionen um Profinet teilnehmer anzusteuern. Das entschlüsseln der Bits direkt in ein Strukt ist sensationell einfach. Und als übergabe gibts du eine Hardwarenummer und schon kannst du Eingänge nachträglich schieben oder Namen ändern ohne dein Program anpassen zu müssen.

Thomas_v2.1 · 27 April 2015

Nur ist an Arrays mit UDT nix neues. Das war alles schon in SCL mit den alten Steuerungen möglich, vollsymbolisch.
Plus die Funktionen mit Any-Zeigern usw. die jetzt nicht mehr möglich sind, bzw. nur mit gleichwertigen Frickelfunktionen wie Peek und Poke.

MSB · 27 April 2015

RogerSchw85 schrieb:
Ich finde SETIO und GETIO sehr schöne funktionen um Profinet teilnehmer anzusteuern. Das entschlüsseln der Bits direkt in ein Strukt ist sensationell einfach. Und als übergabe gibts du eine Hardwarenummer und schon kannst du Eingänge nachträglich schieben oder Namen ändern ohne dein Program anpassen zu müssen.

Man frage sich jetzt schon langsam:
SFC14/15 gibts schon seit mittleren Ewigkeiten, auch bei Step 7.

Die einzige Neuerung ist die HW-ID, welche die Sache vielleich optisch ein wenig verschönert.
Könnten wir jetzt mal über echte Neuerungen Sprechen und nicht alten Wein in zerkratzten neuen Gläsern.

Das gilt übrigens auch für das SCL-Beispiel von miasma.
Die einzige quasi Neuerung oder eher Verbesserung in diesem Thread ist dann also wirklich das Program Alarm, welches es scheinbar wert ist, sich mal näher damit zu befassen.

Ja der SCL-Editor ist besser, aber auch teilweise wieder nicht wg. Spezial Dreck wie " " oder # ... als Variablen-Prefix,
was mich insofern trifft, als das ich gewisse Grundfunktionen habe, die exakt den identischen Code aufweisen bei:
Siemens, Codesys, Panasonic, und wenns sein muss sogar PCWorx.

Mfg
Manuel

Ralle · 27 April 2015

Ich gebs auf, ich glaube, Siemens hat hier ein paar echte Trolle engagiert!

@Miasma
Alles in einem DB oder eben direkt codiert, toll, das ist natürlich einfach, aber darum gings nicht!

@RogerSchw85
Ja, echt sensationell, whow!

@Ronin
Das schau ich mir morgen mal an, könnte was werden, mal sehen.
Aber du hast Recht, nix symbolisch natürlich.

@Ralle
Ende

HelleBarde · 27 April 2015

RONIN schrieb:
Die Störungen heißen schließlich Anlage.Teilbereich.Betriebsmittel.Stoe.Versorgung und Anlage.Teilbereich.Betriebsmittel.Stoe.Betriebsmeldung und nicht Anlage.Teilbereich.Betriebsmittel.Stoe.X1 und .X2
Das ist ja mein Problem. In dem Fall sind Slice-Nummern nicht viel besser als Bitadressen. Da fehlt mir noch die Lösung für.

Ja, symbolisch ist das nicht

Ich hätte gerne, dass man das wie einen UDT definiert und dann innerhalb eines DB mehrere davon verwenden kann.

'n schön' Tach auch
HB

HelleBarde · 27 April 2015

miasma schrieb:
Welche SPS Entwicklungsumgebung bringt denn die Möglichkeit mit Variablennamen zur Laufzeit zusammenzubauen und nutzt dabei die Sprachen die im wesentlichen die IEC 61131 erfüllen ?

Also Variablen zu Laufzeit symbolisch zusammen zu stöpseln ... nee nee nee
ABER
Zeiger auf Variablen, das wäre es
nicht dieser verknorkste Variant.
Abspeichern will ich sie
und im nächsten Zyklus wieder verwenden.

Vielleicht sollten die mal die dritte Ausgabe der 61131 lesen, das Kapitel über die Referenzen

'n schön' Tach auch
HB

HelleBarde · 27 April 2015

Ralle schrieb:
Ich weiß, aber das ist nicht die Lösung die ich brauche, Array ist klar, aber was gibt es denn nun Bausteinübergreifend??? Das kann ja wohl gar nicht sein, dass es dafür kein Mittel gibt. Und wenn nun einige schon das hohe Loblied auf TIA singen und alles voll symbolisch machen und so megazufrieden sind, dann muß es doch wenigsten für die grundlegensten Dinge eine Lösung geben. Etwas von Datenbaustein A nach B zu kopieren, was nicht als Array deklariert ist und das auch noch variabel, ist doch ein absolutes Muß, das kommt doch andauernd vor.

Hi ihr frustrieten Leidensgenossen

Ich hab zwar keine Rezepte, aber Stanzdaten.
Die Daten für ein Bauteil liegen in einem DB. Dieser ist ein ArrayDB. Da stecken beliebig von einem UDT drin. Der UDT ist eine Stanzung, also sowas wie x-y Koordinaten und noch 9 andere Daten.
Und wenn die Stanze jetzt was anderes Stanzen soll, dann muss ich nur einen anderen DB aktivieren.
Der aktive DB steht in einer Variable vom Typ DB_ANY, faktisch ist das eine DB Nummer. Und an die Daten innerhalb des ArrayDB kommt man nur über ReadFromArrayDB dran. Man muss nicht wissen wieviele Stanzungen im ArrayDB drin sind. In jedem Zyklus schau ich nach, ob das Werkzeug wieder oben ist, dann erhöhe ich den Index und greife mit ReadFromArrayDB die nächste Stanzung. Und dann läuft im wesentlichen eine in Graph programmierte Kette ab, welche die Stanze kontrolliert.

Das ist schon in etwa das was in der Prozessindustrie mit Rezepten gemacht wird. Alles einigermaßen flexible und symbolisch. Aber trotzdem nicht voll symbolisch, denn den aktiven DB muss man über dessen Nummer setzen -- wieder so ein Fleck auf der Weste, wo man sich denkt, dass S. sich nix gedacht hat.

Also es geht schon einiges, aber die ArrayDB sind trotzdem irgendwie nur halb gar. Richtige Zeiger auf bekanntem UDT wären da um einiges flexibler.

'n schön' Tach auch
HB

HelleBarde · 27 April 2015

Thomas_v2.1 schrieb:
Nur ist an Arrays mit UDT nix neues. Das war alles schon in SCL mit den alten Steuerungen möglich, vollsymbolisch.
Plus die Funktionen mit Any-Zeigern usw. die jetzt nicht mehr möglich sind, bzw. nur mit gleichwertigen Frickelfunktionen wie Peek und Poke.

Das riecht und schmeckt nach Commodore64.
Welcher Witzbold bei Siemens hat sich eigentlich die Namen einfallen lassen.
Ist das Ironie eines vielleicht ebenfalls frustrieten Entwicklers.

'n schön' Tach auch
HB

RONIN · 27 April 2015

miasma schrieb:
Welche SPS Entwicklungsumgebung bringt denn die Möglichkeit mit Variablennamen zur Laufzeit zusammenzubauen und nutzt dabei die Sprachen die im wesentlichen die IEC 61131 erfüllen ?

Dann wären wir ja wenigstens wieder durchgängig. In den WinCC-Skripten stöpselt man sich ja schon seit Jahren seine Variablennamen zusammen. Wieder ein Punkt mehr in Buch für die totally integrated Automation...

miasma · 27 April 2015

Ralle schrieb:
Ich gebs auf, ich glaube, Siemens hat hier ein paar echte Trolle engagiert!

@Miasma
Alles in einem DB oder eben direkt codiert, toll, das ist natürlich einfach, aber darum gings nicht!

Ende

Worum geht es denn dann bitte, wenn nicht um so einfach wie möglich, so sauber wie möglich, so lesbar wie möglich und so flexibel wie möglich ?

miasma · 27 April 2015

RogerSchw85 schrieb:
@miasme

Das klingt nach einem Umfangreichen Program. Was hast du für eine Steuerung?

Wie lange hast du dich mit den neuen Steuerungen befasst um das so hinzukriegen?

Ich finde SETIO und GETIO sehr schöne funktionen um Profinet teilnehmer anzusteuern. Das entschlüsseln der Bits direkt in ein Strukt ist sensationell einfach. Und als übergabe gibts du eine Hardwarenummer und schon kannst du Eingänge nachträglich schieben oder Namen ändern ohne dein Program anpassen zu müssen.

Das Programm läuft in einer ET200SP CPU 1512F.
Das Entwickeln des Programms hat 2 Wochen gedauert. Ich hatte allerdings schon vorher ein solches Programm in C# realisiert.

Ich nutze TIA von Anfang an und habe schon mit der V 10.5 auf einer 1200er gearbeitet.

Thomas_v2.1 · 27 April 2015

HelleBarde schrieb:
Also Variablen zu Laufzeit symbolisch zusammen zu stöpseln ... nee nee nee
ABER
Zeiger auf Variablen, das wäre es
nicht dieser verknorkste Variant.
Abspeichern will ich sie
und im nächsten Zyklus wieder verwenden.

Wobei das mit dem Abspeichern der Adressen, bzw. Wiederverwendung über mehrere Zyklen z.B. bei Codesys auch nicht zulässig ist, da sich die Adressen bei Programmänderungen im Online-Modus verschieben können.
Das ist aber kein unlösbares Problem wenn man ein neues System darauf auslegt, z.B. mit einer festen Speicherstelle die dann auf die aktuelle zeigt (doppelter Zeiger). Das kann man ja so umsetzen dass der Programmierer das nicht zu Gesicht bekommt.

Das mit den Referenzen in der IEC 3rd Edition habe ich nur in der Überschrift gelesen, Details dazu findet man leider nicht, bzw. sind 350€ für die Norm etwas viel um da nur mal reinzuschauen. Bin mal gespannt was damit erlaubt ist. Zeigerarithmetik muss meiner Meinung nach auch nicht unbedingt erlaubt sein. Und wenn die Zeiger richtig typisiert sein müssen, kann man auch keine großen Schweinereien damit anstellen. Außerdem gibt es eine gute Überprüfung schon zum Übersetzungszeitpunkt. Dieses Variant-Konzept finde ich nicht tauglich, denn da muss ich wieder alles zur Laufzeit prüfen, und Fehlerbehandlungen ausprogrammieren.

JSEngineering · 28 April 2015

Also laut Aussage Siemens soll POKE_BLK dazu genutzt werden, um aus einem beliebigen DB in einen Speicherbeich, mit dem man weiterarbeitet, zu kopieren.
Wenn man sich die Parameter ansieht, kann man die DB-Nummer und den Byte-Offset per DINT vorgeben.
Dann kopiert man sich die Daten in einen Arbeitsbereich und ist damit so flexibel, wie Ralle das glaube ich haben möchte.

Laut Siemens stehen die Befehle auch in der neuesten FW (V4.1) der 1200er zur Verfügung.

Ansonsten sind in der 1500er weiterhin die ANY-Pointer verfügbar, um althergebracht die Probleme zu lösen.

Der VARIANT und VREF sind nicht offengelegt und VARIANT kann nur hart codiert beschrieben werden (VARIANT_PUT).

HelleBarde · 29 April 2015

Hi Thomas

das mit den Referenzen der 3rd Edition schaut eigentlich ganz gut aus. Hier das Beispiel von Seite 46:

Code:

TYPE
  S1: STRUCT
    SC1: INT;
    SC2: REAL;
  END_STRUCT;
  A1: ARRAY[1..99] OF INT;
END_TYPE

VAR
  myS1: S1;
  myA1: A1;
  myRefS1: REF_TO S1:= REF(myS1);
  myRefA1: REF_TO A1:= REF(myA1);
  myRefInt: REF_TO INT:= REF(myA1[1]);
END_VAR


myRefS1^.SC1:= myRefA1^[12]; // in this case, equivalent to S1.SC1:= A1[12];
myRefInt:= REF(A1[11]);
S1.SC1:= myRefInt^; // assigns the value of A1[11] to S1.SC1

Also die Referenzen sind immer typisiert. Man kann ohne Kopieren auf Werte dessen was referenziert ist zugreifen. r^.a ist der Zugriff auf a innerhalb dessen worauf r zeigt. r1 := r2 ist das Kopieren des Zeigers und r1^:= r2^ ist das kopieren der Werte. Ich denke, dass das viele offene Fragen, die wir hier immer wieder durchkauen beantwortet.

Variant löst das alles nicht und lässt uns im Regen stehen. Jetzt darf gewettet werden. Beckhoff und Codesys werden das bestimmt bald alles vollständig drin haben. Ich weiß gar nicht, ob sie das nicht schon haben. Ich tipp mal bei Big S. auf V15 ... in drei Jahren. Kurz vor meiner Rente :-(

'n schön' Tach auch
HB

JSEngineering · 30 April 2015

@HelleBarde:
Guten Morgen!
Ich bin etwas verwirrt von Deiner Aussage. Die Schreibweise, die ich sehe, entspricht der Pointerschreibweise. Und die gibt es doch schon!? ADR()
Wenn wir von Referenzen sprechen, ist das ja was Anderes, eine Referenz belegt keinen Speicher, ist nur ein Synonym für die Variable.

Code:

PROGRAM PLC_PRG
VAR
  MyReference    : REFERENCE TO INT;
  A              : INT;
  MyPointer      : POINTER TO INT;
  B              : INT;
END_VAR
  
MyReference REF= A;
MyReference := 13;
MyPointer := ADR(B);
MyPointer^ := 14;

Die Referenz ist neu, der Pointer ist meines Wissens lange implementiert (zumindest bei Bachmann's M-PLC, einem CoDeSys mit Branding).

Thomas_v2.1 · 30 April 2015

JSEngineering schrieb:
@HelleBarde:
Guten Morgen!
Ich bin etwas verwirrt von Deiner Aussage. Die Schreibweise, die ich sehe, entspricht der Pointerschreibweise. Und die gibt es doch schon!? ADR()
Wenn wir von Referenzen sprechen, ist das ja was Anderes, eine Referenz belegt keinen Speicher, ist nur ein Synonym für die Variable.
...
Die Referenz ist neu, der Pointer ist meines Wissens lange implementiert (zumindest bei Bachmann's M-PLC, einem CoDeSys mit Branding).

Zeiger bzw. Adressoperator und ADR() waren bisher aber nicht in der IEC-Norm.
Ohne die neue Norm zu kennen, vermute ich mal dass man Referenzen nicht addieren kann, d.h. Pointerarithmetik ist dann nicht möglich (mMn aber auch nicht schlimm).

daloeff · 13 Mai 2015

Hallo Jungs,

hab ne Frage zum Program_Alarm, vlt kann mir ja jemand helfen?
Ich habe eine Motoransteuerung in SCL in der diverse Fehlermeldungen generiert werden (z.B.: <Name der Instance> meldet folgenden Fehlercode: <errCodeSEW>)
Die Instance der Ansteuerung wird im Projekt öfters aufgerufen. Jedoch werden nicht alle Alarme generiert. Wenn ich in der HMI unter HMI-Meldungen die Steuerungsmeldungen öffne, fehlen die meisten Störungen?!
- Habe die HMI + Projekt schon komplett neu generiert
- die Texte der Fehlermeldungen in dem Baustein ein wenig geändert und neu generiert
- im Projekt Ordner den "IM" Ordner gelöscht, danach alles neu generiert
Alles hat keinen Erfolg gebracht...
Bei Zylinderbausteinen generiere ich die Laufzeitfehlermeldungen auf die gleiche Art -> funktionieren einwandfrei!

vita-2002 · 14 Mai 2015

rostiger Nagel schrieb:
...

Ziehe ich im Massenmurks, mehre Variablen rein und packe die in ein Block und kopier diese, funktioniert
es und TIA nennt diese selbständig um. Aus...:

Code:

"004-IDB".Taster.Antrieb_Start "004-IDB".Taster.Antrieb_Stop

wird dann

Code:

004-IDB_Taster_Antrieb_Start 004-IDB_Taster_Antrieb_Stop

So will ich das aber nicht, da durch das entfernen des Punktes, sich nicht mehr eindeutig
erkennen lässt wie die Variable strukturiert ist.
....

Wie ist es bei dir eingestellt?:

vita-2002 · 15 Mai 2015

miasma schrieb:
...

Diesen UDT kann ich überall aufrufen und nutzen, in den Stammdaten, im Rezept usw. ...

UDT (PLC-Datentyp) in der Rezeptur? Bei mir geht es nicht: "Ungültige Rezepturvariable für Rezepturelement"

Werner29 · 15 Mai 2015

Thomas_v2.1 schrieb:
Zeiger bzw. Adressoperator und ADR() waren bisher aber nicht in der IEC-Norm.
Ohne die neue Norm zu kennen, vermute ich mal dass man Referenzen nicht addieren kann, d.h. Pointerarithmetik ist dann nicht möglich (mMn aber auch nicht schlimm).

So ist es: ich habe ja am Standard mitgearbeitet, und kann das aufklären. Der Wunsch war klar: wir wollten typsichere Pointer ohne Arithmetik.
Wir wollten aber keine Referenzen die man als solche nicht erkennt. Das Ergebnis ist diese Mischung der Konzepte, für C-Programmierer sicher ungewohnt.
Aus meiner Sicht sind das einfach typsichere Pointer ohne Arithmetik. Typsicher heisst, es gibt keinen Cast von einem Pointer auf den anderen.
Für viele scheint das aber untrennbar verbunden zu sein, und ausserdem haben sich viele Leute an dem Begriff "Pointer" gestört.
Pointer gelten als "unsicher", Referenzen als vergleichsweise sicher. Also haben wir das Referenz genannt und alle waren zufrieden.

In CODESYS (und TwinCAT) ist das nicht exakt so umgesetzt. Wir haben POINTER, die völlig ungetypt sind, bzw. sich wie DWORD verhalten, man kann ganz normal mit denen rechnen
mit allen Vor- und Nachteilen, und man kann ohne CAST einen Pointer von einem Typ auf einen Pointer eines anderen Typs zuweisen. Damit ist deutlich mehr möglich als mit den Standard-
REFERENZ-Typen. Aber man kann auch viel Unheil damit anrichten.

TIA Bin ich der Einzige der wirklich zufrieden ist mit TIA ?

Level-2

Level-1

Level-3

Super-Moderator , User des Jahres 2006-2007

Level-1

Level-1

Level-1

Level-1

Level-3

Level-2

Level-2

Level-1

Level-3

Level-1

Level-3

Level-1

Level-1

Level-2

Level-2

Level-1

Similar threads

Wir schützen deine Privatsphäre