Beckhoff: Frage Interfaces für FB

drfunfrock

Level-1
Beiträge
934
Reaktionspunkte
72
Zuviel Werbung?
-> Hier kostenlos registrieren
Hat jemand schon einmal Interfaces für FB verwendet? Der Sinn müsste doch darin liegen, zur Laufzeit einen FB wechseln zu können. Ich denke da an Umformer oder Regler per HMI zu konfigurieren. Sehe ich das richtig?
 
Habe ich schon verwendet.

Ein Problem ist aber die Instanzierung der verschiedenen FB mit gleichem Interface.

Da es in der SPS Umgebung aus Gründen der Sicherheit keinen "new" Befehl gibt (alles ist bereits statisch instanziiert) kann man zwar von einer FB Instanz zur anderen umschalten aber das kann man auch anders.

Ob es übersichtlicher ist mit Interfaces, ist jedem persönlich überlassen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe ich schon verwendet.

Ein Problem ist aber die Instanzierung der verschiedenen FB mit gleichem Interface.

Da es in der SPS Umgebung aus Gründen der Sicherheit keinen "new" Befehl gibt (alles ist bereits statisch instanziiert) kann man zwar von einer FB Instanz zur anderen umschalten aber das kann man auch anders.

Ob es übersichtlicher ist mit Interfaces, ist jedem persönlich überlassen.

es gibt zwar nicht "new" aber __NEW gibt es schon und man kann damit auch Instanzen zur Laufzeit anlegen. Diese sind aber nicht Onlinechange fähig und man sieht die Instanzen nicht im Engineering System (debuggen im Code ist in dynamischen Instanzen ist also nicht möglich).

Btw. machen interfaces die Sache nicht nur übersichtlicher, aber ich glaube die Diskussion gab es hier schonmal und ich trete sie nicht noch einmal los :)
 
Hat jemand schon einmal Interfaces für FB verwendet? Der Sinn müsste doch darin liegen, zur Laufzeit einen FB wechseln zu können. Ich denke da an Umformer oder Regler per HMI zu konfigurieren. Sehe ich das richtig?

Ja man kann Interfaces für die "späte Bindung" in der SPS verwenden und noch mehr. Du kannst generell verschiedene Bausteine, die das selbe Interface aber implementieren, über einen Interface Pointer aufrufen, also gleich handhaben. Macht den Code generell schöner lesbar (ist zugegeben meine Meinung :) ).
In TwinCAT kann man Interfaces aber generell verwenden um zwischen TwinCAT Modulen zu "kommunizieren". z.B. aus der SPS heraus ein Interface in einer anderen SPS (aber in der selben TwinCAT Runtime) aufrufen. Oder in einem C++ Module, einem Matlab Module ...
 
es gibt zwar nicht "new" aber __NEW gibt es schon und man kann damit auch Instanzen zur Laufzeit anlegen. Diese sind aber nicht Onlinechange fähig und man sieht die Instanzen nicht im Engineering System (debuggen im Code ist in dynamischen Instanzen ist also nicht möglich).

Btw. machen interfaces die Sache nicht nur übersichtlicher, aber ich glaube die Diskussion gab es hier schonmal und ich trete sie nicht noch einmal los :)


Dann habe ich die Doku richtig interpretiert :ROFLMAO:

Ist __NEW dokumentiert? Mein Problem ist, ich habe ein Serienprodukt und muss z.B. verschiedene Umformer einbinden, je nach Kunde. Selbiges könnte man auch mit Reglern, Joysticks etc machen . Ohne dieses Feature ist man sehr viel unflexibler. Die Alternative wäre mit Arrays von Strukturen zu arbeiten (in, out und config). Das Problem, welches ich noch habe ist, wie bekommen ich eine derartige Flexibilität für die IO-Anbindung zustande? Ich habe die letzten Jahre nur mit Omron gearbeitet und nahezu alles war adressbasiert, weil die Klemmen alles per DMA in den Speicher kopieren, so dass man nur ein Array drüber legen musste. Bei den neuesten Omron-SPS kann man mit einem Programm die IO-Anbindung als csv Datei erzeugen und dann ins Programm kopieren. Das spart eine Menge Fehler wenn es um mehr als 30 identische Geräte geht. Mit Beckhoff habe ich noch keine Lösung gefunden, um ein massenweises Point und Klick zu umgehen.
 
Gibt es dafür nicht das Automation Interface von Beckhoff? (scriptgesteuerte Code-Generierung etc.)

richtig, damit kann man den Code erzeugen bzw. Anpassen. Es gibt aber Kunden die haben einen Code für alle Maschinenkombinationen. Bzw. auch welche die die Hardware beim Hochlaufen der Maschine scannen und damit den Maschinentyp erkennen und dann die entsprechenden Objekte erzeugen wollen. Jeder wie es für ihn am besten passt :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mal wieder was dazu gelernt, auch mit der aktuellen Codesys 3.5 SP8/P1 funktioniert das, wenn man in den Applikationseinstellungen Speicher hierfür freigibt.

Aber ob ich das nutze, frage ich mich doch? SPS sollen ja länger durchlaufen als ein Büro PC und wie dann ggf. eine Fragmentierung des Speichess durch andauerndes new/delete nach Monaten/Jahren aussieht ?

Im erstmaligen Zyklus beim Hochlauf allerdings recht interessant als Option und Lösung.
 
Ich denke, Objekte sollten zur Startzeit erzeugt werden, wenn man OO haben will. Ganz ehrlich, ich habe keinen Plan, wie das zu machen wäre. Ich stelle mir gerade verschiedene Umformer mit AnyBus-Ethercat Modul vor, die dann wiederum per ModBus mit dem Umformer kommunizieren. Die Gerätedateien sind einfach Murks. Meine Idee geht mehr dahin, dass man eine Anzahl FB für Geräte in Arrays fest instanziert und dann die FB, die nicht benötigt werden, nicht ausführt. Dafür bekommt jedes Gerät eine Parameterstruktur.. Dafür eignet sich das Interface vorzüglich.
 
Zurück
Oben