Beginner

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Steile These. Ich finde es macht für die wenigsten I/Os Sinn diese global zu deklarieren.
Instanziiere ich nach OOP z.B. einen Zylinderbaustein mit darin befindlichen IOs mehrmals, bekomme ich gleichzeitig ohne Mehraufwand die entsprechenden I/Os dazu. TwinCAT sei dank.

-Stirni

Das ist, würde ich sagen, eine Philosophiefrage. Man kann für beide Varianten gute Argumente finden.
Leute aus dem Siemensumfeld sind die zentrale Variante gewohnt, dort ist es ja immer noch so.

 

[Stirni]

Das ist, würde ich ssgen, eine Philosophiefrage. Man kann für beide Varianten gute Argumente finden.
Leute aus dem Siemensumfeld sind die zentrale Variante gewohnt, dort ist ja immer noch so.

Richtig. Es geht halt bei Siemens nicht anders.

-Stirni

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Steile These. Ich finde es macht für die wenigsten I/Os Sinn diese global zu deklarieren.
Instanziiere ich nach OOP z.B. einen Zylinderbaustein mit darin befindlichen IOs mehrmals, bekomme ich gleichzeitig ohne Mehraufwand die entsprechenden I/Os dazu. TwinCAT sei dank.

-Stirni

Die These war ja auch nur meine persönliche Meinung Man kann sich denke ich an Philosophien gewöhnen, die einen machen es lieber so und die anderen so. Grundsätzlich ist kein Ansatz technisch falsch. Da mein erstes und einziges Twincat Projekt jetzt auch schon 6-7 Jahre zurückliegt und ich davor und danach nur in der S7 Welt war, zeigt sich natürlich in meinem Ansatz.

 

[Glon]

Wir nutzen den Ansatz mit den I/Os in den Bausteinen auch und gehen auch soweit, dass wir prüfen welche I/Os tatsächlich mit einer Hardware gemapped sind.
Das führt dazu das z.B. der Zylinderbaustein "weiß" ob er eine Endlagenüberwachung durchführen muss.
Nachteil: Das Interface der SPS wird riesig und man weiß nicht was man Mappen muss, dass geht nur über den Weg des Schaltplans. :/

 

[oliver.tonn]

Wir nutzen den Ansatz mit den I/Os in den Bausteinen auch und gehen auch soweit, dass wir prüfen welche I/Os tatsächlich mit einer Hardware gemapped sind.
Das führt dazu das z.B. der Zylinderbaustein "weiß" ob er eine Endlagenüberwachung durchführen muss.
Nachteil: Das Interface der SPS wird riesig und man weiß nicht was man Mappen muss, dass geht nur über den Weg des Schaltplans. :/

Wobei das Mapping theoretisch auch über Pragmas erfolgen kann und das könnte man mit Hilfe entsprechender Makros aus dem E-Kon Programm bekommen, oder das E-Kon Programm erzeugt das Grundgerüst der Anwendung über Makros selber, das hatte ein Kunde erfolgreich umgesetzt.

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das sind leider zuviele Vorraussetzungen die wir noch nicht erfüllen können.

Wir deklarieren jetzt, unabhängig von der Elektrokonstruktion, die Anzahl der benötigten Aktoren (zb. Zylinder) für das Projekt und Mappen das dann auf die uns zur Verfügung gestellten Hardware.
So können wir frühzeitig entwickeln, obwohl die Hardware noch nicht ganz feststeht.
Der Nachteil ist, Siemensianer drehen durch

Andersrum müsste der Eplaner schon vor uns fertig sein, und wo kämen wir dahin...

 

[Tschoke]

Richtig. Es geht halt bei Siemens nicht anders.

Stimmt so auch nicht wirklich.
Man kann bei Siemens ja DPRD_DAT und DPWR_DAT in den Aktor FBs verwendet.
Was auch oft so umgesetzt wird.
Dann muss man auch nichts global definieren.
Das kommt dann dem Mapping wie bei Beckhoff... recht nah.

Ich persönlich finde es z.B. für boolsche E/As wie z.B. Endlagensensor oder Ventil nicht gut das direkt in den FB zu mappen.
Wenn nämlich z.B. an einem Zylinder Öffner verbaut sind, dann mach ich bei der Globalen Variante einfach ein "not" hin.
Bei der gemappten Variante benötige ich irgendwas zum konfigurieren, z.B. einen Eingang am FB ob Schließer oder Öffner.
Das gleiche gilt für boolsche Ausgänge. Ich finde es nicht Übersichtlich wenn dann ein Aktorbaustein mehr Eingänge für die Konfiguration besitzt als für die eigentliche Funktion.
Bei z.B. einem Umrichter Baustein, oft mit fixem Prozessabbild, finde ich wiederum die mapping bzw. DPRD_DAT/DPWR_DAT Lösung viel besser.
Aber wie schon gesagt wurde ist das eine Geschmackssache.

 

[Stirni]

Stimmt so auch nicht wirklich.
Man kann bei Siemens ja DPRD_DAT und DPWR_DAT in den Aktor FBs verwendet.
Was auch oft so umgesetzt wird.
Dann muss man auch nichts global definieren.
Das kommt dann dem Mapping wie bei Beckhoff... recht nah.

Ich persönlich finde es z.B. für boolsche E/As wie z.B. Endlagensensor oder Ventil nicht gut das direkt in den FB zu mappen.
Wenn nämlich z.B. an einem Zylinder Öffner verbaut sind, dann mach ich bei der Globalen Variante einfach ein "not" hin.
Bei der gemappten Variante benötige ich irgendwas zum konfigurieren, z.B. einen Eingang am FB ob Schließer oder Öffner.
Das gleiche gilt für boolsche Ausgänge. Ich finde es nicht Übersichtlich wenn dann ein Aktorbaustein mehr Eingänge für die Konfiguration besitzt als für die eigentliche Funktion.
Bei z.B. einem Umrichter Baustein, oft mit fixem Prozessabbild, finde ich wiederum die mapping bzw. DPRD_DAT/DPWR_DAT Lösung viel besser.
Aber wie schon gesagt wurde ist das eine Geschmackssache.

Dort muss ja hier eine HW_IO-Adresse angeben und der komplette Bereich wird kopiert.
Beim TC-Mapping kann ich einzelne Bits, Integers bis hin zu Strukturen und Arrays mappen.
Das hat mir der von dir beschriebenen Funktion wenig zu tun.
Funktioniert nur wenn, so wie von dir im letzten Satz beschrieben, ein fixes Prozessabbild kopiert werden soll.

-Stirni

 

[Tschoke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ein Mapping und DPRD_DAT/DPWR_DAT nicht das gleiche ist weiß ich auch.
Ich bezog mich nur auf deine Aussage, das man in der Siemenswelt zentral/global deklarieren muss, da es nicht anders geht.
Und das stimmt so nicht...

 

[charly2]

Hallo,


es geht voran ... Tool-Box schon mal angefasst, PWM programmiert usw...

Ich habe ja so eine Destillationskolonne zu bearbeiten.
Da tauchen zwei "sicherheitsrelevante" Zustände auf.
Einmal der Ventil-Zustand der Kühlung und
einmal der Füllstand im Sumpf.

Wenn ich jetzt das Ethernet-Kabel ziehe, steht die Beckhoff und die "sicherheitsrelevanten" Zustände werden nicht mehr überwacht. Richtig?

Frage: Gibt es eine Möglichkeit solche "sicherheitsrelevanten" Programmteile so in die Steuerung zu brennen, dass sie auch ohne Verbindung zum PC noch funktionieren?

Danke für eine Antwort.

VG Walter

 

[oliver.tonn]

Hallo,


es geht voran ... Tool-Box schon mal angefasst, PWM programmiert usw...

Ich habe ja so eine Destillationskolonne zu bearbeiten.
Da tauchen zwei "sicherheitsrelevante" Zustände auf.
Einmal der Ventil-Zustand der Kühlung und
einmal der Füllstand im Sumpf.

Wenn ich jetzt das Ethernet-Kabel ziehe, steht die Beckhoff und die "sicherheitsrelevanten" Zustände werden nicht mehr überwacht. Richtig?

Frage: Gibt es eine Möglichkeit solche "sicherheitsrelevanten" Programmteile so in die Steuerung zu brennen, dass sie auch ohne Verbindung zum PC noch funktionieren?

Danke für eine Antwort.

VG Walter

Da unterliegst Du einem Irrtum, der BK ist keine SPS, sondern nur ein Koppler, an den I/O-Module angesteckt sind. Die SPS ist Dein Laptop. Für sicherheitsgerichtete Aufgaben müsstest Du eine Safety-Logikklemme, z.B. die EL6910 einsetzen. Das ist eine Safety-SPS und zusätzlich noch Safety Ein- und Ausgangsklemmen, oder eine kombinierte Klemme die I/Os und die Logikklemme enthält. Auf dieser läuft dann ein entsprechendes Safety-Programm. Das wird in Deinem Fall aber schwierig, da an den BK nur K-Bus Klemmen montiert werden können, wobei montiert werden könnten auch E-Bus Klemmen, aber sie funktionieren dann nicht, und die EL6910 ist eine E-Bus Klemme. Wie sich die EL6910 und die Safety I/Os aber bei fehlendem Master, der ja die Netzwerkkarte Deines Laptop ist, sprich beim ziehen des Netzwerkkabels am Laptop, verhält kann ich nicht sagen.

 

[charly2]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke. Schon mal ne wertvolle Auskunft.

VG Walter