DE102019217520A1 - Verfahren zur modularen Anpassung einer programmierbaren Steuerung - Google Patents

Verfahren zur modularen Anpassung einer programmierbaren Steuerung Download PDF

Info

Publication number
DE102019217520A1
DE102019217520A1 DE102019217520.1A DE102019217520A DE102019217520A1 DE 102019217520 A1 DE102019217520 A1 DE 102019217520A1 DE 102019217520 A DE102019217520 A DE 102019217520A DE 102019217520 A1 DE102019217520 A1 DE 102019217520A1
Authority
DE
Germany
Prior art keywords
command
function
data
objects
data element
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019217520.1A
Other languages
English (en)
Inventor
Thomas Schroeder
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102019217520.1A priority Critical patent/DE102019217520A1/de
Priority to US17/091,464 priority patent/US11782418B2/en
Priority to CN202011259522.5A priority patent/CN112799351A/zh
Publication of DE102019217520A1 publication Critical patent/DE102019217520A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/18Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form
    • G05B19/4155Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form characterised by programme execution, i.e. part programme or machine function execution, e.g. selection of a programme
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/18Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of programme data in numerical form
    • G05B19/414Structure of the control system, e.g. common controller or multiprocessor systems, interface to servo, programmable interface controller
    • G05B19/4147Structure of the control system, e.g. common controller or multiprocessor systems, interface to servo, programmable interface controller characterised by using a programmable interface controller [PIC]
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426Programming the control sequence
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/36Software reuse
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/31From computer integrated manufacturing till monitoring
    • G05B2219/31229Supervisor, master, workstation controller, automation, machine control
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/34Director, elements to supervisory
    • G05B2219/34013Servocontroller

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Automation & Control Theory (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Manufacturing & Machinery (AREA)
  • Programmable Controllers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur modularen Anpassung einer programmierbaren Steuerung, umfassend Bereitstellen eines Basis-Laufzeitsystems; Definieren von eindeutigen Referenzen (S1, S2, S3; 330, 332, 334; 402, 404, 406, 408, 410, 412, 414) mit einer festgelegten Reihenfolge in dem Basis-Laufzeitsystem, Bereitstellen von mindestens einem Funktionsobjekt (100; F1, F2, F3; 320, 322) mit einer oder mehreren auszuführenden Methoden (104) und mindestens einem Funktionszeiger auf eine oder mehrere der Methoden (104), wobei jeder Funktionszeiger mit einer definierten eindeutigen Referenz verknüpft ist; und Ausführen mindestens eines bereitgestellten Funktionsobjekts (100; F1, F2, F3; 320, 322) auf Grundlage der verknüpften eindeutigen Referenzen.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren, ein Computerprogramm und eine Recheneinheit zur modularen Anpassung einer programmierten Steuerung.
  • Stand der Technik
  • Bei Steuerungen für verschiedenste Anwendungsgebiete, insbesondere im Bereich der Automationssteuerung, werden üblicherweise Berechnungsabfolgen fest in der Architektur der Steuerungssoftware verankert. In eine derartige Struktur hat ein Nutzer der Steuerung nur sehr begrenzte Eingriffsmöglichkeiten. Zwar ist es teilweise möglich, an einzelnen Stellen der Berechnungsabfolge Ergebnisse nachträglich zu modifizieren oder an vorgegebenen Elementen zusätzliche Funktionen zu definieren, aber falls diese einfachen Eingriffe nicht ausreichen, muss eine neue Firmware entwickelt und erstellt werden. Ebenso kann nicht auf Teile der Berechnungsabfolge verzichtet werden, die für die lokale Anwendung gar nicht gebraucht werden. Auch der gemeinsame Datenzugriff in solchen Systemen ist für derartige Eingriffsmöglichkeiten begrenzt. Alle diese Eigenschaften machen eine modulare Verteilung von Funktionalitäten oder Wartung der Steuerung schwierig.
  • Offenbarung der Erfindung
  • Erfindungsgemäß wird ein Verfahren zur echtzeitfähigen modularen Anpassung einer programmierten Steuerung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
  • Insbesondere wird ein Verfahren vorgeschlagen, bei dem zunächst ein Basis-Laufzeitsystem bereitgestellt wird, in dem eindeutige Referenzen mit einer festgelegten Reihenfolge definiert werden. Dann wird mindestens ein Funktionsobjekt mit einer oder mehreren auszuführenden Methoden und mit mindestens einem Funktionszeiger auf eine oder mehrere der Methoden bereitgestellt, wobei jeder Funktionszeiger wiederum mit einer der definierten eindeutigen Referenzen des Basis-Laufzeitsystems verknüpft ist. Anschließend wird mindestens eines der bereitgestellten Funktionsobjekte auf Grundlage der verknüpften eindeutigen Referenzen ausgeführt. Auf diese Weise können Funktionsobjekte in der Form gekapselter Objektklassen zur Ausführung von Programmabläufen in einer Steuerung verwendet werden, wobei die Nutzung der eindeutigen Referenzen (im Folgenden auch als Sektionen bezeichnet) den Ablauf mehrerer Funktionsobjekte in der passenden Reihenfolge sicherstellt, ohne dass zuvor alle Funktionsobjekte vorhanden oder bekannt sein müssen. Als Funktionsobjekte können beliebige Funktionen verwendet werden, die für die Steuerung grundlegend sind, beispielsweise diverse Berechnungen, Transformationen oder einzelne Steuerbefehle.
  • Das Verfahren kann in einer Ausführungsform weiter das Anmelden mindestens eines neuen Funktionsobjekts in dem Basis-Laufzeitsystem umfassen, wobei das Anmelden das Angeben des mindestens einen Funktionszeigers und einer damit verknüpften eindeutigen Referenz sowie das Angeben von durch das Funktionselement verwendeten Datenelementen umfasst. Somit können beispielsweise später entwickelte oder durch einen Kunden oder Fremdanbieter entwickelte Zusatzfunktionen modular und zur Laufzeit (ohne Neustart des Steuerungssystems) zu dem ursprünglichen Basissystem hinzugefügt werden und in bestehende Programmabläufe eingereiht werden, ohne dass die umfassten Funktionsobjekte bereits ursprünglich bekannt sein müssen. Durch die Anmeldung am System können die zusätzlichen Funktionsobjekte von Kommandos (insbesondere in programmierbaren Einheiten) genutzt werden.
  • Gemäß beispielhaften Ausführungsformen werden aus einem oder mehreren der registrierten Funktionsobjekte ausführbare Kommandos gebildet. Dabei können die Kommandos verwendet werden, um aus den Einzelfunktionen der Funktionsobjekte vollständige Ablaufschritte zu bilden, z.B. einen bestimmten Bewegungsablauf eines Aktors. Kommandos können von außen über geeignete Schnittstellen vorgegeben werden und das Verhalten der Steuerung und damit der Maschine definieren.
  • Darüber hinaus kann ein Datenverwaltungsmodul für ein Kommando bereitgestellt werden, welches einen Austausch von Datenelementen zwischen den in dem Kommando enthaltenen Funktionsobjekten verwaltet, wobei der Austausch von Datenelementen mindestens eines der folgenden umfasst: Bereitstellen von mindestens einem Datenelement durch ein Funktionsobjekt, Lesen von mindestens einem Datenelement durch ein Funktionsobjekt. Das Datenverwaltungsmodul erlaubt die Zuordnung und zeitliche Einordnung von Datenzugriffen für beliebige angemeldete Funktionsobjekte in dem Kommando und kann auch weitere Aufgaben in Bezug auf die Daten übernehmen, wie etwa eine Typisierung bzw. Typprüfung der ausgetauschten Daten.
  • Beim Bereitstellen eines Datenelements durch ein Funktionsobjekt kann das Datenelement mit einer der definierten eindeutigen Referenzen im Laufzeitsystem verknüpft werden, bevorzugt mit der Referenz, bei der die Ausführung des entsprechenden Schritts (z.B. einer Berechnung des Datenelements) stattfindet. Damit können Datenelemente verknüpft mit einer eindeutigen Referenz unterschiedliche Berechnungszustände von Daten geben und zugeordnet werden. Bevorzugt kann jedes Datenelement pro Referenz höchstens einmal bereitgestellt werden, um eine eindeutige Zuordnung zu ermöglichen. Ein Datenelement kann jedoch mehrfach geschrieben werden, wenn jeder Schreibzugriff einer separaten Referenz zugeordnet ist. Damit ist es möglich, verschiedene Berechnungszustände des Datenelements abzubilden.
  • So kann beispielsweise eine kommandierte Zielposition in mehreren Sektionen geschrieben werden: initial in einer Sektion „CmdData“ als genau die Werte, die dem Kommando als Parameter mitgegeben wurden, danach in einer Sektion „AbsPosition“, wobei relative Werte in absolute Werte umgerechnet wurden (und damit nur noch absolute Werte in dieser Sektion abgelegt werden), und schließlich in einer Sektion „Offsets“, wobei die absoluten Werte noch zusätzlich durch programmierte Verschiebungen modifiziert werden.
  • Beim Lesen eines Datenelements kann dann wiederum Bezug auf eine der definierten eindeutigen Referenzen des Basis-Laufzeitsystems genommen werden. So kann jedes lesende Funktionsobjekt wählen, auf welchen der Berechnungszustände eines Datenelements es zugreifen möchte. Wahlweise kann beim Lesen eines Datenelements eine Zielreferenz aus den definierten eindeutigen Referenzen des Basis-Laufzeitsystems angegeben werden, wobei dann das gelesene Datenelement einem zuletzt vor der Zielreferenz bereitgestellten Datenelement entspricht, so dass auch unbekannte zusätzliche Modifikationen vor dieser Zielreferenz automatisch mit einbezogen werden, ohne dass das Funktionsobjekt die vorherigen Schritte exakt kennen muss.
  • Im Beispiel von oben kann das Funktionsobjekt nun wählen, ob es die kommandierte Zielposition als originale Parameter (lese Sektion „CmdData“), als absolute Werte (lese Sektion „AbsPosition“) oder als Werte nach der Verschiebung (lese Sektion „Offsets“) bekommen möchte. Sollte keine Verschiebung aktiv sein (und damit die Sektion „Offsets“ kein Datenelement enthalten), kann das Datenverwaltungsmodul automatisch die Daten der letzten Sektion vor der gewünschten Sektion (also aus Sektion „AbsPosition“) bereitstellen. Damit muss das lesende Funktionsobjekt nicht wissen, ob tatsächlich eine Verschiebung aktiv ist oder nicht.
  • Gemäß weiteren Ausführungsformen kann mindestens ein Kommandoparameter für ein Kommando erfasst werden, wobei der mindestens eine Kommandoparameter von Methoden der in dem Kommando enthaltenen Funktionsobjekte aufgerufen werden kann. Kommandoparameter können beispielsweise von einem Datenverwaltungsmodul an Funktionsobjekte als Datenelement weitergegeben werden, wo sie dann für die folgenden Ausführungsschritte verwendet werden können.
  • Zusätzlich ist es möglich, aus einem oder mehreren der Funktionsobjekte Kommandooptionen bilden. Eine derartige Kommandooption kann dann aktiviert werden und bewirkt das Hinzufügen des einen oder mehreren der Funktionsobjekte der Kommandooption zu mindestens einem nachfolgenden Kommando.
  • Dabei kann beispielsweise eine Kommandooption für eine vorgegebene Anzahl von folgenden Kommandos aktiviert sein, oder nur für das nächste Kommando; wahlweise könnte eine Kommandooption aber auch für alle folgenden Kommandos aktiviert sein, bis eine Deaktivierung der Kommandooption aufgerufen wird. Damit können einzelne Funktionen innerhalb eines Kommandos flexibel ein- und ausgeschaltet werden, ohne das gesamte Kommando dauerhaft neu zu entwickeln.
  • Ein Beispiel für eine Kommandooption ist die oben beschriebene Verschiebung der kommandierten Zielposition. Wenn diese Option aktiv ist, fügt sie der Berechnungskette einen weiteren Schritt hinzu. Wenn nicht, werden keine Laufzeit verbraucht und auch kein Speicher belegt. Alle anderen Berechnungsschritte sind komplett unabhängig davon, ob eine Verschiebung aktiv ist oder nicht.
  • In einer Ausführungsform kann eine Erweiterung zu dem Basissystem hinzugefügt werden, wobei die Erweiterung mindestens eines der folgenden umfasst: ein oder mehrere Funktionsobjekte, ein oder mehrere Kommandos, ein oder mehrere Kommandooptionen. Damit kann ein Basissystem zu jedem Zeitpunkt flexibel erweitert werden, sowohl herstellerseitig als auch spezifisch auf bestimmte Kundenanwendungen zugeschnitten. Die Installation einer Erweiterung ist bevorzugt ohne Neustart der Steuerung möglich und damit sehr einfach und schnell umsetzbar. Sobald sich die Erweiterung am Basissystem angemeldet hat, sind die zusätzlichen Kommandos und Kommandooptionen nutzbar und können von außen durch geeignete Schnittstellen aufgerufen werden.
  • In weiteren Ausführungsformen kann eine graphische Benutzerschnittstelle bereitgestellt werden, welche ein Anzeigen der bereitgestellten Funktionsobjekte ermöglicht. Dann kann eine Nutzereingabe erfasst werden, welche eine Auswahl von Funktionsobjekten wiedergibt, und aus den gewählten Funktionsobjekten kann ein ausführbares Kommando gebildet werden. Eine derartige Benutzerschnittstelle ermöglicht es einem Anwender, zusätzliche Funktionalitäten und Bewegungsabläufe einer Steuerung auf einfache Weise umzusetzen, ohne dabei vertieft in die Entwicklung eingreifen zu müssen. Dabei können die verwendeten Funktionsobjekte wieder Teile des ursprünglichen Basissystems sein und/oder später durch eine Erweiterung hinzugefügt werden.
  • Bevorzugt können die Funktionsobjekte Teilfunktionen zur Ansteuerung beispielsweise von einem oder mehreren Aktoren, einem oder mehreren Sensoren, einem oder mehreren Antrieben bilden. Während das Grundprinzip der modularen Erweiterung einer Steuerung durch Funktionsobjekte in praktisch jedem ansteuerbaren System denkbar ist, können insbesondere Steuerungen für Automationssysteme, Universalmaschinen, Bearbeitungszentren und weitere Systeme mit z.B. speicherprogrammierbaren Steuerungen auf diese Weise erweiterbar aufgebaut werden.
  • Eine erfindungsgemäße Recheneinheit, z.B. eine Automationssteuerung ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
  • Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
  • Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
  • Es versteht sich, dass die vorstehend genannten und die nachfolgend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
  • Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
  • Figurenliste
    • 1 zeigt beispielhaft die Bildung eines Kommandos aus ausgewählten Funktionsobjekten;
    • 2 zeigt schematisch Datenzugriffe durch Funktionsobjekte in verschiedenen Sektionen;
    • 3 zeigt einen Austausch von Daten in einem Datenverwaltungsmodul zwischen zwei Funktionsobjekten eines Kommandos gemäß einer möglichen Ausführungsform, und
    • 4 zeigt beispielhaft einen visualisierten Datenfluss bei der Ausführung eines Kommandos in verschiedenen Sektionen.
  • Detaillierte Beschreibung der Zeichnung
  • In 1 ist ein beispielhaftes modulares System zur Anpassung einer programmierten Steuerung gemäß Ausführungsformen der Erfindung schematisch gezeigt.
  • Die Grundlage ist zunächst ein Basissystem einer Steuerung als eingebettetes Laufzeitsystem (embedded system), in dem verschiedene Standardfunktionen implementiert sein können. Dabei kann es sich beispielsweise um grundlegende Steuerfunktionen aller Art für ein Automationssystem handeln. Dieses Laufzeitsystem kann als eine Einheit bereitgestellt werden.
  • Zur Anpassung und Erweiterung dieses Systems können nun Funktionsobjekte 100 vorgesehen sein, bei denen es sich im Wesentlichen um kompilierte Objektklassen handeln kann. Ein Funktionsobjekt sollte zum Einsatz im Laufzeitsystem bestimmte Schnittstellen erfüllen. Dabei kann ein Funktionsobjekt entweder bereits Teil des Basissystems sein und dann zum Laufzeitsystem verbunden sein, oder es kann in einer Erweiterung des Laufzeitsystems enthalten sein.
  • Dabei kann eine Erweiterung als eine gemeinsam genutzte Programmbibliothek mit vordefinierten Schnittstellen vorliegen. Beim Laden einer Erweiterung kann sich diese am Laufzeitsystem anmelden und registriert die zusätzlichen Funktionalitäten, die in ihr enthalten sind. Somit kann eine Erweiterung nachträglich installiert werden und sowohl herstellerseitig eingebunden werden als auch vom Endnutzer der Steuerung entwickelt und/oder modular eingebunden werden. Es können entsprechend auch mehrere Erweiterungen, beispielsweise aus unterschiedlichen Quellen oder zu unterschiedlichen Zeitpunkten, zu einem bestehenden System hinzugefügt werden oder optional auch wieder entfernt oder abgeändert werden.
  • Ein Funktionsobjekt kann sich ebenso beim Laden am Laufzeitsystem anmelden und ist ab dieser Anmeldung bevorzugt im gesamten System verfügbar, beispielsweise auch für zusätzliche Erweiterungen. Dabei wird für jedes Funktionsobjekt ein eindeutiger Name 102 vergeben, der zur Identifikation dient.
  • Durch Funktionsobjekte können beliebige geeignete Einzelfunktionalitäten einer Steuerung umgesetzt sein. Diese können sich beispielsweise auf bestimmte Berechnungsschritte oder Anweisungen für Bewegungen eines Aktors oder einer Maschinenachse beziehen. Dabei erfolgt sowohl die Funktionalität selbst als auch das Anmelden am System in diesem Funktionsobjekt. Zu jedem Funktionsobjekt 100 stehen interne Daten 104 und Methoden 106 zur Verfügung, welche ausschließlich im Funktionsobjekt verfügbar sind. Dabei sind diese Bestandteile auf jedes der in der 1 gezeigten Funktionsobjekte 100a, 100b, ..., 100h übertragbar, wobei es sich versteht, dass jedes Funktionsobjekt unterschiedliche Daten und/oder Methoden aufweisen kann. Die internen Methoden und Daten können von allen Teilfunktionen im jeweiligen Funktionsobjekt gelesen, geschrieben und/oder aufgerufen werden. Von außen sind sie dagegen bevorzugt nicht erreichbar, d.h. die Funktionsobjekte sind vollständig gekapselt. Zum Datenaustausch nach außen, etwa mit anderen Funktionsobjekten, kann ein Datenverwaltungsmodul und Aussprünge der Funktionsobjekte über definierte Schnittstellen verwendet werden, was nachstehend genauer erläutert wird.
  • Am vorgenannten Beispiel einer Steuerung für ein Automationssystem bzw. eine Bearbeitungsmaschine können als vordefinierte oder nachträglich eingebrachte Funktionsobjekte beispielsweise die folgenden vorgesehen sein:
    • - Geometrische Bewegungsfunktionen, wie beispielsweise lineare Bewegung; Kreisbewegung; Bewegung entlang kubischer Splines oder B-Splines;
    • - Eindimensionale Interpolationen, z.B. ein Interpolator zur Erzeugung eines ruckbegrenzten Geschwindigkeitsprofils mit trapezförmigem Beschleunigungsverlauf oder auch ein Interpolator auf Basis einer sin2-Funktion
    • - Normierungs- und Umrechnungsfunktionen, wie z.B. metrische Maße, angloamerikanische Maße, Umrechnungen zwischen Koordinatensystemen wie Polarkoordinaten, kartesische Koordinaten, andere Bezugssysteme;
    • - Verschiebungen, wie etwa Nullpunktverschiebungen, Werkzeugverschiebung, Helmert- Transformation;
    • - Geschwindigkeitsinterpolation mit Ruckbegrenzung;
    • - Kollisionserkennung, z.B. ein- oder dreidimensional mit entsprechenden Toleranzen;
    • - Positionsschaltpunkte;
    • - Umschalten des Antriebsmodus, z.B. auf Ort oder Geschwindigkeit;
    • - Ereignisse, wie etwa Erzeugen oder Warten
    • - Messtaster,
    • - Achsentransformationen;
    • - zusätzliche Transformationen, z.B. Zylindermanteltransformation, Stirnseitentransformation;
    • - Rundungen, Fasen, Eckenrunden;
    • - Werkzeugkorrekturen;
    • - Achskopplungen, z.B. Gantry, Kopplung über elektronisches Getriebe, flexibles Profil;
    • - Kompensationen und Korrekturen.
  • Es versteht sich, dass je nach angesteuertem System und erwünschten Funktionsumfang beliebige andere und/oder weitere Funktionsobjekte verwendet werden können, die entsprechende modulare Bausteine eines Programmablaufs zur Steuerung bilden können.
  • Bevorzugt werden Funktionsobjekte 100 in Kommandos 120 verwendet. Dabei kann ein Kommando eine logische Einheit darstellen, die für einen Schritt im Ablauf der Applikation steht. Dabei kann jedes Kommando 120 eine vordefinierte Gruppe von Funktionsobjekten 100f, 100g, 100h enthalten, die dessen Funktion implementieren. Die verwendeten Funktionsobjekte werden bei der Entwicklung des Kommandos festgelegt. Dabei ist es möglich, die Kommandos bereits herstellerseitig zu definieren und mit dem System vorzugeben. Alternativ oder zusätzlich können aber auch Kommandos modular aus Funktionsobjekten definiert werden, beispielsweise durch einen Maschinenhersteller oder sogar durch den Endanwender. Ebenso ist es möglich, dass fertig definierte Kommandos nachträglich hinzugefügt werden, beispielsweise im Rahmen einer Funktionserweiterung.
  • Beispiele für Kommandos sind etwa Bewegungsabläufe eines Aktors, z.B. die Bewegung des Aktors eines Roboters auf einer Geraden zu einem Punkt im Raum; das Zuschalten von Leistung für einen Antrieb in einer beliebigen Vorrichtung; das Löschen von Fehlern für eine Achse, und weitere Abläufe. Dabei können einfachere oder komplexere Funktionalitäten durch ein Kommando umgesetzt werden, indem die dafür benötigten Funktionsobjekte darin festgelegt werden. Generell bilden die Kommandos bevorzugt die nacheinander ablaufenden Bestandteile einer Steuerungsanwendung, die vom Laufzeitsystem nacheinander abgearbeitet werden.
  • Zur Umsetzung derartiger Funktionalitäten kann ein Kommando auch Parameter enthalten, beispielsweise die Zielposition einer Bewegung. Kommandoparameter können beispielsweise als Wert eines Datenelements in ein oder mehrere Funktionsobjekte eines Kommandos einfließen und entsprechend weiterverwendet werden oder als Parametereinstellung für bestimmte Funktionen eingesetzt werden.
  • Kommandos können über verschiedene übliche Schnittstellen von außen vorgegeben werden, wie etwa REST-API (Representational State Transfer Application Programming Interface); OPC Unified Architecture; SPS (Speicherprogrammierbare Steuerung, z.B. über Funktionsbausteine); Skript (z.B. über eine Erweiterungsbibliothek in Python); Low-Level-C-Interface und weitere.
  • Zur gemeinsamen Verwendung von Daten innerhalb eines Kommandos kann jedem Kommando ein eigenes Datenverwaltungsmodul zugeordnet sein. Dieses Datenverwaltungsmodul dient zum Datenaustausch zwischen den verschiedenen Funktionsobjekten eines Kommandos. Da zum Entwicklungszeitpunkt nicht bekannt sein muss, welche Funktionsobjekte in einem Kommando existieren, können diese nicht direkt miteinander kommunizieren. Das Datenverwaltungsmodul kann alle Funktionen wie Typprüfung und Datenzugriffe aller Art, also z.B. lesende, schreibende und/oder aufrufende Zugriffe übernehmen. Zusätzlich kann über das Datenmodul die Gültigkeit der Datenelemente (erst Schreiben, dann Lesen) sichergestellt werden.
  • Um den Ablauf und Zugriffe in einem derartigen System konsistent zu steuern, können Sektionen definiert werden, bei denen es sich um eindeutige Referenzen im Laufzeitsystem handelt. Dazu kann jede Sektion über einen eindeutigen Namen bzw. Kennzeichner identifiziert werden. Die Sektionen weisen eine definierte Reihenfolge auf. Ebenso können auch zusätzliche Sektionen definiert werden und in die bestehende Reihenfolge eingereiht werden, beispielsweise durch eine angemeldete Erweiterung. Beim Einbringen neuer Sektionen werden diese global im Basissystem bekannt gemacht und eingeordnet.
  • Beispiele für Sektionen in einer beispielhaften Steuerung einer Bearbeitungsmaschine sind etwa: Eingabe der Kommandoparameter, Abschluss der Geometrieaufbereitung, berechnete Sollpositionen verfügbar. Selbstverständlich können beliebige weitere und andere Sektionen definiert sein, die als geeignete Referenzpunkte für die ausgeführten Funktionsobjekte dienen können.
  • Weiter weisen die Funktionsobjekte definierte Schnittstellen auf. Ein Aussprung ist dabei ein Funktionszeiger auf eine Methode in einem Funktionsobjekt mit definierter Schnittstelle. Jedes Funktionsobjekt kann beliebig viele Aussprünge umfassen. Wenn ein Kommando ins System aufgenommen wird, werden alle dazugehörigen Funktionsobjekte angelegt. Danach wird von jedem Funktionsobjekt eine Schnittstellenfunktion gerufen, die es ermöglicht, Aussprünge im Laufzeitsystem anzumelden.
  • Für jeden Aussprung eines Funktionsobjekts soll dabei eine zugehörige Sektion definiert werden, in der der Aussprung aufgerufen werden soll. Durch diese feste Zuordnung von Aussprüngen zu Sektionen mit definierter Reihenfolge wird damit die Ausführungsreihenfolge der Aussprünge über alle Funktionsobjekte hinweg festgelegt, ohne dass dabei die Funktionsobjekte selbst bereits bekannt sein müssten.
  • Darüber hinaus können Sektionen genutzt werden, um unterschiedliche Aufbereitungsstände von Daten darzustellen. Dazu werden Daten beim Bereitstellen bzw. Schreiben mit einer Sektion verknüpft, ab der sie vorhanden sind. Typischerweise handelt es sich dabei um die Sektion, in der der Aussprung bzw. eine Methode läuft, welche die Daten berechnet. Dabei kann ein Funktionsobjekt ein existierendes Datenelement weiter in einer späteren Sektion bereitstellen, wobei das originale zuerst bereitgestellte Datenelement bevorzugt weiter verfügbar bleibt, also nicht ersetzt wird. Die Kombination aus Datenelement (adressiert über eine Datenkennung) und einer Sektion stellt den Berechnungszustand des Datenelements dar.
  • Sowohl für die Bereitstellung von eigenen Daten mittels der Schnittstellen über das Datenverwaltungsmodul als auch für das Anmelden eines lesenden Zugriffs wird also bevorzugt die Angabe der zugehörigen Sektion benötigt. Damit kann der Datenfluss verifiziert werden. Die Reihenfolge der Sektionen kann beispielsweise automatisch aus dem Datenfluss ermittelt oder explizit über eine Konfiguration definiert werden.
  • Beim Auslesen können Daten dann entweder direkt mit einer Sektion verknüpft werden oder mit einer Zielsektion definiert werden. Bei einer festen Verknüpfung mit einer bestimmten Sektion muss ein anderes Funktionsobjekt dieses Datenelement exakt in dieser Sektion schreiben, d.h. es wird genau das Datenelement in der angegebenen Sektion angefordert.
  • Falls dagegen eine Zielsektion definiert ist, wird mit dieser Zielsektion angegeben, dass das Datenelement bis zu dieser Sektion geschrieben sein muss.
  • Je nach Ausführungsform kann eine dieser Varianten der Verknüpfung von Daten mit Sektionen vorgegeben sein oder es kann z.B. eine geeignete Syntax verwendet werden, um beim Zugriff zwischen hart verknüpften Daten und Daten mit Zielsektion zu unterscheiden.
  • Die Verwendung einer Zielsektion gemäß der zweiten Variante macht es möglich, flexibel auf zusätzliche Funktionsobjekte zu reagieren. Wenn ein Funktionsobjekt ein Datenelement mit einer vorgegebenen Zielsektion anfragt, können beliebig viele andere Funktionsobjekte das Datenelement in vorangegangenen Sektionen modifiziert haben.
  • Ein Beispiel für eine derartige Anwendung, bei der Daten mit einer Zielsektion verknüpft sind, ist in 2 gezeigt.
  • Es sind dabei beispielsweise Sektionen S1, S2, S3 definiert, die in dieser Reihenfolge in dem Laufzeitsystem als Referenzen vorgegeben sind.
  • Weiter werden hier zwei Funktionsobjekte F1 und F2 betrachtet. Funktionsobjekt 1 weist einen Aussprung in Sektion S1 auf und schreibt dort das Datenelement D. Das Funktionsobjekt F2 weist einen Aussprung in Sektion S2 auf und schreibt dort ebenfalls das Datenelement D. Im System sind damit zwei Bearbeitungsstände des Datenelements D für die Sektionen S1 und S2 bereitgestellt. Ein drittes Funktionsobjekt F3, das in einem Aussprung in Sektion S3 läuft, kann nun beispielsweise auf diese Daten lesend zugreifen. Dazu kann das Funktionsobjekt angeben, ob es das Datenelement D aus der Sektion S1, D(S1), und damit das Ergebnis des Funktionsobjekts F1, oder das Datenelement D aus der Sektion S2 und damit das Ergebnis des Funktionsobjekts F2 lesen möchte. In einer anderen Variante könnte in dem Funktionsobjekt F3 auch anstelle einer fixen Verknüpfung angegeben sein, dass das letzte bereitgestellte Ergebnis von D vor der Zielsektion S3 gelesen werden soll. Diese Variante ermöglicht, dass immer der zuletzt geschriebene Bearbeitungsstand des Datenelements gelesen wird. Im vorliegenden Fall erhält das Funktionsobjekt F3 damit das Ergebnis des Funktionsobjekts F2 und damit den Bearbeitungsstand D(S2), falls dieses ausgeführt wurde bzw. in dem betreffenden Kommando existiert, und ansonsten das Ergebnis des Funktionsobjekts F1, also D(S1).
  • Falls Daten in einer Sektion nicht modifiziert werden, können sie in einer Ausführungsform jeweils in die folgende Sektion weitervererbt werden, so dass also im obigen Beispiel das letzte geschriebene Datenelement D aus der Sektion S2 in die Sektion S3 und folgende Sektionen vererbt werden kann und mit dieser Angabe bei einem Zugriff ausgelesen werden kann. Damit kann eine lesende Funktion über die gewünschte Sektion steuern, auf welchen Berechnungszustand sie zugreifen möchte. So kann beispielsweise beim Lesen einer Zielposition in einer ersten Sektion auf die unmodifizierte Zielposition zugegriffen werden, während beim Lesen des gleichen Datenelements aus einer definierten zweiten Sektion die Zielposition um eine aktive Nullpunktverschiebung modifiziert sein kann. Falls dabei die Nullpunktverschiebung gar nicht aktiviert ist, kann das vererbte Datenelement der ersten Sektion auch aus der zweiten Sektion gelesen werden. Damit erhält die Funktion bei Zugriff auf die Zielposition der zweiten Sektion den modifizierten Wert, wenn die Verschiebung aktiv ist, und den unmodifizierten Wert, wenn die Verschiebung nicht aktiv ist. Ein Entwickler der entsprechenden Funktion muss dabei keine Rücksicht auf die Nullpunktverschiebung nehmen, da beide Funktionalitäten auf diese Weise entkoppelt sind. Die Möglichkeit der selektiven Aktivierung von einzelnen Funktionsobjekten wird nachstehend noch näher beschrieben.
  • Ein Datenaustausch zwischen Aussprüngen bzw. Methoden innerhalb eines Funktionsobjekts benötigt keinen Zugriff über das Datenverwaltungsmodul, sondern kann über private Member des Funktionsobjekts erfolgen.
  • Weitere Mechanismen können je nach Ausführungsform eingesetzt werden, um die Datenkommunikation zu sichern. Beispielsweise kann bevorzugt festgelegt sein, dass pro Sektion und Datenelement nur eine Bereitstellung (publish) erlaubt ist, so dass eine eindeutige Zuordnung über die Angabe der Sektion möglich ist.
  • Ebenso kann festgelegt sein, dass in jeder Sektion die Schreibzugriffe vor den Lesezugriffen erfolgen müssen, so dass sichergestellt ist, dass ein Funktionsobjekt, das auf einen bestimmten Bearbeitungsstand des Datenelements zugreift, auch das finale Ergebnis erhält, das womöglich erst in dieser Sektion bereitgestellt wurde.
  • Darüber hinaus kann auch festgelegt sein, dass lesende Zugriffe geschützt erfolgen und kein Schreiben mehr möglich ist.
  • Gemäß einer Ausführungsform kann außerdem eine strenge Typprüfung verwendet werden, insbesondere für Daten, die zwischen Funktionsobjekten ausgetauscht werden. Das bedeutet, dass zusätzlich zu den zugrundeliegenden Basis-Datentypen der jeweiligen verwendeten Sprachen (z.B. double, float, int, ...) weitere Datentypen so definiert sein können, dass beispielsweise eine Zielposition immer nur einer Variable für Zielpositionen zugeordnet werden kann und nicht einer Variable für eine Geschwindigkeit, obwohl beide auf demselben Basis-Datentyp basieren können. Es werden also im System bevorzugt zusätzliche, spezifischere Datentypen definiert und dann jedem Datenelement zugeordnet. Damit wird jeweils sowohl der Basis-Datentyp als auch der spezifische Datentyp überprüft, um eine Konsistenz der Daten sicherzustellen. Der Grad der Differenzierung kann beliebig gewählt werden. Die Definition spezifischer Datentypen vereinfacht die Wartung des Systems und die Erweiterungsmöglichkeiten für den Anwender.
  • Gemäß einer Ausführungsform sind im Basissystem bereits eine Reihe von Datentypen vordefiniert. Hinzugefügte Erweiterungen können dann neue Datentypen im System global anmelden, so dass die neuen Datentypen ab diesem Zeitpunkt von allen Funktionsobjekten genutzt werden können.
  • In 3 ist ein Beispiel einer schematischen Darstellung eines Kommandos mit gemeinsamer Datenverwaltung gezeigt. Dabei werden zwei Funktionsobjekte 320, 322 benutzt, von denen eines bereits im Basissystem 310 vorhanden ist, während das andere durch eine nachinstallierte Erweiterung 312 dem System hinzugefügt sein kann. Im vorliegenden Fall kann es sich beispielsweise um Funktionsobjekte für einen Kreispfad 322 und eine Bewegungsinterpolation 312 handeln, welche gemeinsam ein Kommando für eine Kreisbewegung eines Aktors bilden. Beide Funktionsobjekte können sich am Basissystem z.B. an einem Objektmodul 314 registrieren, wie durch die Pfeile von den Funktionsobjekten aus dargestellt ist. Dann kann ein Kommando 300 gebildet werden, das diese beiden registrierten Funktionsobjekte 320, 322 umfasst. Zur Verwaltung der gemeinsam verwendeten Daten ist das zugehörige Datenverwaltungsmodul 302 des Kommandos 300 vorgesehen.
  • Der Ablauf der Funktionsobjekte wird durch mehrere Sektionen mit fester Reihenfolge vorgegeben, indem die Aussprünge der Funktionsobjekte den Sektionen zugeteilt sind. Im vorliegenden Fall sind die Sektionen 330a, 330b, 330c beispielsweise den Ablaufschritten einer Parametervalidierung (validate), Datenvorbereitung (prepare) und Ausführung (execute) zugeordnet. Die in den jeweiligen Funktionsobjekten verwendeten Daten werden dabei über das Datenverwaltungsmodul 302 ausgetauscht. Als denkbare Daten für das Beispiel der Kreisbewegung sind hier dynamische Grenzwerte, Zielposition, Hilfsposition, Pfadlängen, und weitere dargestellt, die als Eingangsgrößen verwendet werden können. Diese können beispielsweise fest vorgegeben sein oder als Kommandoparameter 350 in die verwendeten Daten einfließen. Es ist dann ersichtlich, dass die beiden Funktionsobjekte entsprechend den festen Sektionen ablaufen und in einzelnen Sektionen Daten lesen oder bereitstellen, die dann wiederum in weiteren Aussprüngen von einem der Funktionsobjekte weiterverwendet werden. Beispielsweise werden in einer ersten Sektion 330a zunächst die Daten für Positionen und Richtung im Kreispfad-Funktionsobjekt 322 validiert, während in der nächsten Sektion 330b diese und weitere Daten vorbereitet werden. In jeder Sektion laufen entsprechende Methoden in den Funktionsobjekten ab. Wie ebenfalls sichtbar ist, können auch von einem Funktionsobjekt 322 geschriebene Daten 344 (z.B. eine durch das Funktionsobjekt berechnete Pfadlänge) in einer Sektion bereitgestellt und in der gleichen Sektion durch ein anderes Funktionsobjekt wieder aufgerufen werden. Dies wird möglich, indem bevorzugt vorgegeben ist, dass alle Schreibzugriffe vor den lesenden Zugriffen erfolgen.
  • Im Funktionsobjekt 320 ist anschließend eine interne Datenübergabe zwischen den Sektionen 332 und 334 gezeigt, in den das Datenverwaltungsmodul nicht eingebunden ist. Dagegen werden zu diesem Zeitpunkt im Funktionsobjekt 322 keine internen Daten zwischen den Sektionen weitergegeben. Stattdessen ruft das Funktionsobjekt 322 in der folgenden Sektion 334 zur Ausführung eine eindimensionale Länge 345 ab, die zuvor durch Ausführung des ersten Funktionsobjekts 320 in der gleichen Sektion 334 bereitgestellt wurde. Beide Funktionsobjekte stellen außerdem weitere erzeugte Daten 346, 347, 348, 349 bereit, welche zusammen dann die Bewegungsabfolge an einen Aktor ergeben. Dabei kann es sich beispielsweise um eine Geschwindigkeit 346, eine Beschleunigung 347, einen Ruck (d.h. Ableitung der Beschleunigung) 348 oder eine Einstellposition 349 handeln.
  • Selbstverständlich können Kommandos auch deutlich mehr Funktionsobjekte und komplexere Interaktionen über das Datenverwaltungsmodul umfassen. Ebenso kann ein Kommando aber grundsätzlich auch ein einzelnes Funktionsobjekt umfassen.
  • In weiteren Ausführungsformen können Kommandooptionen umgesetzt werden. Dabei handelt es sich um eine logische Einheit, die ein Kommando modifiziert. Bevorzugt umfasst auch eine Kommandooption intern ein oder mehrere vordefinierte Funktionsobjekte, die dessen Funktion implementieren. Dabei kann eine Kommandooption auch durch genau ein Funktionsobjekt realisiert werden. Kommandooptionen können generell über die gleichen Schnittstellen wie Kommandos (REST, OPC-UA, SPS, Skript, Low-Level C) vorgegeben werden.
  • Optional können Kommandooptionen auch Parameter umfassen, beispielsweise die vorgesehene Verschiebung als Parameterwert für eine Werkzeugverschiebung. Falls eine Kommandooption vorgegeben wird, die derzeit bereits aktiv ist, kann die neue Option mit den angegebenen Parametern die existierende Option überschreiben, so dass auf diese Weise beispielsweise die Parameter einer Kommandooption angepasst werden können.
  • Mögliche Beispiele für Kommandooptionen im Beispielfall einer Maschinensteuerung sind beispielsweise Achstransformationen, Werkzeugverschiebungen, oder Funktionen zum Überschleifen von zwei Bewegungskommandos ineinander. Generell kann jedes Funktionsobjekt oder jede Gruppe von Funktionsobjekten als Kommandooption eingesetzt werden.
  • Eine Kommandooption kann permanent aktiviert werden, d.h. so lange, bis sie wieder explizit abgeschaltet wird, beispielsweise durch einen entsprechenden Befehl. Ebenso kann eine Kommandooption auch spezifisch nur für das nächste Kommando oder für eine vorgegebene Zahl nachfolgender Kommandos gültig sein.
  • Solange eine Kommandooption aktiviert ist, kann sie Instanzen ihrer Funktionsobjekte in allen folgenden Kommandos erzeugen. Auf diese Weise können Kommandos flexibel modifiziert werden und entsprechende Funktionalitäten vorübergehend ein- und ausgeschaltet werden. Wenn ein Kommando ins System kommt, werden also alle zu dem Kommando gehörigen Funktionsobjekte sowie die Funktionsobjekte aller derzeit aktiven Kommandooptionen angelegt und dem Kommando hinzugefügt.
  • Der vorstehend beschriebene modulare Aufbau kann gemäß einer Ausführungsform dazu verwendet werden, einem Endanwender bzw. Kunden den selbständigen Aufbau von zusätzlichen Kommandos und/oder Kommandooptionen zu ermöglichen. Dabei kann für die zusätzlichen Kommandos rein auf die herstellerseitig im Basissystem vorgesehenen Funktionsobjekte zurückgegriffen werden; ebenso können aber weitere Funktionsobjekte, insbesondere durch eine Erweiterung, gezielt entwickelt oder als fertig bereitgestellte Erweiterung für spezifische Anwendungszwecke ins System eingefügt werden. Nachdem die neuen Funktionsobjekte im Laufzeitsystem angemeldet sind, können sie zur Bildung neuer Kommandos und/oder Kommandooptionen verwendet werden. Dabei ist kein Neustart der gesamten Steuerung notwendig; ein Systemreset ist ausreichend und bietet eine wesentlich schnellere Möglichkeit zur Anpassung der Steuerung.
  • In einem Ausführungsbeispiel kann herstellerseitig ein spezielles Funktionsobjekt bereitgestellt werden, beispielsweise einen 1 D-Geschwindigkeitsinterpolator für eine ruckbegrenzte Geschwindigkeitsführung. Dieses Funktionsobjekt kann wiederum in einem ebenfalls bereits im Basissystem vorhandenen Kommando „Bewegung des Aktors eines Roboters auf einer Geraden zu einem Punkt im Raum“ eingesetzt werden. Nun können anwenderseitig zusätzliche Funktionen oder Modifikationen gewünscht sein, beispielsweise soll die Zielposition auf einer speziellen Spline-Bahn angefahren werden. Zu diesem Zweck kann dann ein weiteres Funktionsobjekt entwickelt werden, welches die Bahninterpolation über den Spline umsetzt. Anschließend kann ein neues Kommando erstellt werden, welches sowohl das ursprüngliche Funktionsobjekt mit dem 1 D-Geschwindigkeitsinterpolator sowie das neue Funktionsobjekt für die Spline-Bahn umfasst. Das zusätzliche Funktionsobjekt, das neu erstellte Kommando sowie einige Anmeldefunktionen können dann in eine installierbare Bibliothek bzw. Erweiterung zusammengesetzt werden. Sobald diese Erweiterung an einer Steuerung installiert wird, ist dort - bevorzugt nach einem Systemreset - das neue Kommando verfügbar und kann ausgeführt werden.
  • Als weiteres Ausführungsbeispiel wird nun eine Kombination von herstellerseitigen Funktionen mit nachträglich erweiterten Funktionen durch eine Kommandooption erläutert. Dabei soll auf Wunsch eines Anwenders beispielsweise eine spezielle Kompensationsfunktion bereitgestellt werden, die in dem vorhandenen Basissystem nicht verfügbar ist. Dazu kann zunächst ein entsprechendes Funktionsobjekt „Kompensation“ implementiert werden, das vom Anwender spezifisch entwickelt werden könnte oder auch durch einen Anbieter fertig bereitgestellt sein kann. Das Funktionsobjekt wird dann verwendet, um eine Kommandooption zu bilden. Die Kommandooption mit dem zugehörigen Funktionsobjekt wird dann in eine Erweiterung eingebracht, die in dem Basissystem installiert bzw. angemeldet werden kann. Nach der erfolgreichen Anmeldung und bevorzugt einem Systemreset kann die neue Kommandooption aufgerufen werden.
  • In den folgenden Schritten kann nun zunächst die Kommandooption „Kompensation“ permanent aktiviert werden, so dass sie also aktiviert bleibt, bis eine aktive Abschaltung der Option erfolgt. Als nächstes wird ein erstes Bewegungskommando für eine lineare Bewegung aufgerufen. Alle Funktionsobjekte, die zu diesem ersten Bewegungskommando zugehörig sind, werden nun in einem ersten Kommando instanziiert. Da die Kommandooption aktiv ist, werden außerdem die Funktionsobjekte der Kommandooption in dem ersten Kommando zusätzlich instanziiert. Anschließend werden alle Funktionsobjekte des ersten Kommandos gemäß ihrenr Sektionen abgearbeitet und in jedem Takt eine Sollposition berechnet, welche durch das Funktionsobjekt „Kompensation“ modifiziert und dann ausgegeben wird.
  • Als nächstes wird ein zweites Bewegungskommando für eine Kreisbewegung abgesetzt. Falls die Kommandooption immer noch aktiviert ist, werden auch für dieses zweite Kommando die Schritte wie im ersten Kommando ausgeführt, d.h. die Instanziierung aller Funktionsobjekte des zweiten Bewegungskommandos sowie der Funktionsobjekte der Kommandooption und die Ausgabe der entsprechend modifizierten Positionen.
  • Falls jedoch vor dem zweiten Bewegungskommando eine Deaktivierung der Kommandooption durchgeführt wurde, wird das zweite Kommando ohne die Funktionsobjekte der Kommandooption instanziiert und es werden wieder nicht-modifizierte Soll-Positionen ausgegeben. Damit kann eine zusätzliche Funktion, die in einer Kommandooption enthalten ist, in anderen Kommandos also beliebig ein- und ausgeschaltet werden. Falls die Kommandooption nicht permanent aktiviert wurde, sondern nur beispielsweise für ein einzelnes folgendes Kommando, ist anschließend keine Deaktivierung erforderlich und alle weiteren Kommandos werden wieder unmodifiziert ausgeführt.
  • Gemäß einer Ausführungsform können verschiedene Teile der vorgenannten Ausführungsformen für einen Entwickler oder Endanwender einer derartigen Steuerung visualisiert werden oder auf andere Weise in einer Benutzerschnittstelle dargestellt werden. Beispielsweise können zur Erzeugung von Kommandos/Kommandooptionen aus Funktionsobjekten graphische Darstellungen verwendet werden, die ähnlich wie in 1 die zur Auswahl stehenden Funktionsobjekte als Blockelemente auf einem Display aufzeigen und einen modularen Aufbau eines Kommandos z.B. durch Verschieben der benötigten Funktionsobjekte in ein Kommando darstellen. Auch eigene, etwa durch Erweiterungen hinzugefügte Funktionsobjekte können dabei beliebig integriert werden. Selbstverständlich ist aber auch eine andere Darstellungsweise für eine geeignete Benutzerschnittstelle denkbar, z.B. eine textbasierte oder anhand einer Baumstruktur vorgegebene Option zum Kombinieren von geeigneten Kommandos und Optionen.
  • Ebenso kann der Datenfluss, der beispielsweise aufgrund eines ausgeführten Kommandos ablauft, für einen Anwender über eine geeignete Benutzerschnittstelle visualisiert werden, wie etwa in dem in 4 gezeigten Beispiel als gerichteter Graph, oder auf andere Weise. Damit kann die Berechnungsabfolge mit den unterschiedlichen Funktionsobjekten nachvollzogen werden, was insbesondere die Entwicklung und Anpassung der Systembestandteile vereinfachen kann.
  • Dabei zeigt 4 eine Visualisierung eines Datenflusses, der in einem Ausführungsbeispiel stattfinden kann. Auf der linken Seite sind die Sektionen 402, 404, 406, 408, 410, 412, 414 der zeitlichen Reihenfolge nach von oben nach unten aufgeführt. Dabei sind in dem instanziierten Kommando dieses Beispiels vier Funktionsobjekte vorhanden, wobei auch ein Teil der Funktionsobjekte aus einer oder mehreren Kommandooptionen stammen kann. Die Zugriffsschritte auf der rechten Seite der Figur geben jeweils in der oberen Hälfte das Funktionsobjekt und seinen verwendeten Aussprung an, während in der unteren Hälfte die verknüpfte Sektion angegeben ist. Die Pfeile zwischen den Schritten zeigen auch die Übergabe von Datenelementen bzw. Parameterwerten an.
  • In einer ersten Phase werden die Daten und Parameter vorbereitet.
    1. 1. In der ersten Sektion TST_Input, 402 wird in Schritt 430 der Kommandoparameter 420, TST_TargetPos, mit dem Inhalt {54;23} vom System, d.h. vom Datenverwaltungsmodul des Kommandos bereitgestellt.
    2. 2. Der Aussprung job1 des ersten Funktionsobjekts DummySender nutzt in Schritt 432 das Datenelement 420 (TST_TargetPos) aus dieser Sektion 402. Dabei werden die Schritte 430 und 432 beide in derselben Sektion 402 ausgeführt.
    3. 3. In der nachfolgenden Sektion 404 (TST_PrepOffset) liest der Aussprung des zweiten Funktionsobjekts DummyOffset in Schritt 434 das Datenelement 420 (TST_TargetPos), modifiziert es und schreibt das Datenelement als modifiziertes Element 422 wieder mit seinem neuen Wert {64;43}.
    4. 4. In der Sektion 406, TST_PrepGeometry verwendet nun in Schritt 436 der Aussprung job1 des dritten Funktionsobjekts DummyPath diese modifizierte Zielposition 422, berechnet die Bahnlänge (17,3) und stellt diese als TST_PathLength 424 bereit. Dabei wurde als Zielsektion die Sektion 406, TST_PrepGeometry angegeben. In internen Variablen kann das Funktionsobjekt zusätzliche Daten speichern, die aber nicht allgemein bereitgestellt werden.
    5. 5. Zum Abschluss der Vorbereitung wird in Sektion 408 noch der Aussprung job1 vom vierten Funktionsobjekt Dummylpo gerufen, Zugriffsschritt 438. Dieser verwendet die zuvor berechnete Bahnlänge TST_PathLength 424. Der Aussprung berechnet ein Geschwindigkeitsprofil vor und speichert die dazugehörigen Daten intern, aber stellt sie nicht allgemein bereit.
  • In der folgenden Phase werden die weiteren Berechnungen und Datenmanipulationen für die Endausgabe des Kommandos ausgeführt.
    • 6. In der Sektion 410, TST_Ecexlpo, stellt das Laufzeitsystem den aktuellen Zeitstempel 426 TST_CurrentTime mit dem Wert (0,45) bereit.
    • 7. Dieser Zeitstempel 426 wird ebenfalls in Sektion 410 vom Aussprung 442, job2 des vierten Funktionsobjekts Dummylpo genutzt. Auf Basis der in Aussprung 438, job1 berechneten Daten und der aktuellen Zeit 426 wird eine interpolierte Länge 428 TST_InterpolatedLength (0,123456) bestimmt und publiziert.
    • 8. Der Aussprung job2 des Funktionsobjekts DummyPath wird schließlich in Sektion 412, TST_ExecGeometry gerufen, nutzt die interpolierte Länge 428 TST_InterpolatedLength und berechnet in Schritt 444 daraus und mit seinen internen Daten die interpolierte Position 429 TST_InterpolatedPos {24,21 ;-273,15} und stellt diese im System zur Verfügung.
    • 9. Da keine weiteren Aussprünge angemeldet sind, kann das System in Sektion 414 schließlich in Schritt 446 TST_Output die fertig berechnete Sollposition auslesen und an die Antriebe schicken.
  • Es versteht sich, dass die vorstehenden beispielhaften Ausführungsformen nur verwendet wurden, um verschiedene Grundprinzipien der vorliegenden Erfindung getrennt voneinander zu verdeutlichen und dass diese beliebig erweitert, abgeändert und miteinander kombiniert werden können. Insbesondere können beispielsweise in allen Beispielen, die sich auf die Verwendung von Kommandos beziehen, auch Kommandooptionen wie beschrieben eingesetzt werden; es können beliebige neue Funktionsobjekte und weitere Sektionen angemeldet werden; es können beschriebene Datenelemente und Abläufe durch andere, angepasst an die jeweilige technische Anwendung, ersetzt werden; es können in allen Beispielen weniger oder mehr Funktionsobjekte, Kommandos, Datenelemente etc. eingesetzt werden, als sie hier zur Beschreibung verwendet wurden.

Claims (15)

  1. Verfahren zur modularen Anpassung einer programmierbaren Steuerung, umfassend Bereitstellen eines Basis-Laufzeitsystems; Definieren von eindeutigen Referenzen (S1, S2, S3; 330, 332, 334; 402, 404, 406, 408, 410, 412, 414) mit einer festgelegten Reihenfolge in dem Basis-Laufzeitsystem, Bereitstellen von mindestens einem Funktionsobjekt (100; F1, F2, F3; 320, 322) mit einer oder mehreren auszuführenden Methoden (104) und mindestens einem Funktionszeiger auf eine oder mehrere der Methoden (104), wobei jeder Funktionszeiger mit einer definierten eindeutigen Referenz verknüpft ist; und Ausführen mindestens eines bereitgestellten Funktionsobjekts (100; F1, F2, F3; 320, 322) auf Grundlage der verknüpften eindeutigen Referenzen.
  2. Verfahren nach Anspruch 1, weiter umfassend: Anmelden mindestens eines neuen Funktionsobjekts (322) in dem Basis-Laufzeitsystem, wobei das Anmelden das Angeben des mindestens einen Funktionszeigers und einer damit verknüpften eindeutigen Referenz sowie das Angeben von durch das Funktionsobjekt verwendeten Datenelementen umfasst.
  3. Verfahren nach Anspruch 1 oder 2, weiter umfassend: Bilden eines ausführbaren Kommandos (120; 300) aus einem oder mehreren der Funktionsobjekte (100g, 100f, 100h; 320, 322).
  4. Verfahren nach Anspruch 3, weiter umfassend: Bereitstellen eines Datenverwaltungsmoduls (302) für ein Kommando (300), wobei das Datenverwaltungsmodul (302) einen Austausch von Datenelementen (340, 341, 342, 343, 344, 345, 346, 347, 348, 349) zwischen den in dem Kommando enthaltenen Funktionsobjekten (320, 322) verwaltet, und wobei der Austausch von Datenelementen mindestens eines der folgenden umfasst: Bereitstellen von mindestens einem Datenelement durch ein Funktionsobjekt, Lesen von mindestens einem Datenelement durch ein Funktionsobjekt.
  5. Verfahren nach Anspruch 4, wobei das Bereitstellen eines Datenelements das Verknüpfen des Datenelements mit einer aus den definierten eindeutigen Referenzen des Basis-Laufzeitsystems umfasst.
  6. Verfahren nach Anspruch 4 oder 5, wobei das Lesen eines Datenelements das Aufrufen des Datenelements unter Bezug auf eine der definierten eindeutigen Referenzen des Basis-Laufzeitsystems umfasst.
  7. Verfahren nach einem der Ansprüche 4 bis 6, wobei das Lesen eines Datenelements das Aufrufen des Datenelements mit einer Zielreferenz aus den definierten eindeutigen Referenzen des Basis-Laufzeitsystems umfasst, und wobei das gelesene Datenelement einem zuletzt vor der Zielreferenz bereitgestellten Datenelement entspricht.
  8. Verfahren nach einem der Ansprüche 3 bis 7, weiter umfassend: Erfassen von mindestens einem Kommandoparameter (350) für ein Kommando (300), wobei der mindestens eine Kommandoparameter von Methoden der in dem Kommando enthaltenen Funktionsobjekte (320, 322) aufgerufen werden kann.
  9. Verfahren nach einem der Ansprüche 3 bis 8, weiter umfassend: Bilden einer Kommandooption aus einem oder mehreren der Funktionsobjekte; Aktivieren einer Kommandooption; und Hinzufügen des einen oder mehreren der Funktionsobjekte der Kommandooption zu einem nachfolgenden Kommando.
  10. Verfahren nach Anspruch 9, wobei die Kommandooption für eine vorgegebene Anzahl von folgenden Kommandos aktiviert ist, oder wobei die Kommandooption für alle folgenden Kommandos aktiviert ist, bis eine Deaktivierung der Kommandooption aufgerufen wird.
  11. Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Hinzufügen einer Erweiterung (312) zu dem Basissystem (310), wobei die Erweiterung mindestens eines der folgenden umfasst: ein oder mehrere Funktionsobjekte (322), ein oder mehrere Kommandos, ein oder mehrere Kommandooptionen.
  12. Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Bereitstellen einer graphischen Benutzerschnittstelle, Anzeigen der bereitgestellten Funktionsobjekte; Erfassen einer Eingabe, welche eine Auswahl von Funktionsobjekten wiedergibt; und Bilden eines ausführbaren Kommandos gemäß der erfassten Eingabe.
  13. Recheneinheit, die dazu eingerichtet ist, ein Verfahren nach einem der vorstehenden Ansprüche durchzuführen.
  14. Computerprogramm, das eine Recheneinheit veranlasst, ein Verfahren nach einem der Ansprüche 1 bis 13 durchzuführen, wenn es auf der Recheneinheit ausgeführt wird.
  15. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 14.
DE102019217520.1A 2019-11-13 2019-11-13 Verfahren zur modularen Anpassung einer programmierbaren Steuerung Pending DE102019217520A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102019217520.1A DE102019217520A1 (de) 2019-11-13 2019-11-13 Verfahren zur modularen Anpassung einer programmierbaren Steuerung
US17/091,464 US11782418B2 (en) 2019-11-13 2020-11-06 Method for the modular adjustment of a programmable controller
CN202011259522.5A CN112799351A (zh) 2019-11-13 2020-11-12 用于模块化适配可编程控制器的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102019217520.1A DE102019217520A1 (de) 2019-11-13 2019-11-13 Verfahren zur modularen Anpassung einer programmierbaren Steuerung

Publications (1)

Publication Number Publication Date
DE102019217520A1 true DE102019217520A1 (de) 2021-05-20

Family

ID=75683641

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019217520.1A Pending DE102019217520A1 (de) 2019-11-13 2019-11-13 Verfahren zur modularen Anpassung einer programmierbaren Steuerung

Country Status (3)

Country Link
US (1) US11782418B2 (de)
CN (1) CN112799351A (de)
DE (1) DE102019217520A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113485252B (zh) * 2021-07-17 2022-08-30 中山迈雷特数控技术有限公司 多通道数控***中多通道plc控制方法与多通道数控***

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5769527A (en) * 1986-07-17 1998-06-23 Vari-Lite, Inc. Computer controlled lighting system with distributed control resources
US10361802B1 (en) * 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US5603043A (en) * 1992-11-05 1997-02-11 Giga Operations Corporation System for compiling algorithmic language source code for implementation in programmable hardware
US5784577A (en) * 1996-08-05 1998-07-21 Xilinx Inc Automated control system for programming PLDs
US5768287A (en) * 1996-10-24 1998-06-16 Micron Quantum Devices, Inc. Apparatus and method for programming multistate memory device
US6073160A (en) * 1996-12-18 2000-06-06 Xerox Corporation Document communications controller
US6154684A (en) * 1997-06-14 2000-11-28 Rockwell Technologies, Llc Template language for industrial controller programming
US6402031B1 (en) * 1997-12-16 2002-06-11 Donald R Hall Modular architecture sensing and computing platform
US6157955A (en) * 1998-06-15 2000-12-05 Intel Corporation Packet processing system including a policy engine having a classification unit
US7111290B1 (en) * 1999-01-28 2006-09-19 Ati International Srl Profiling program execution to identify frequently-executed portions and to assist binary translation
US6438738B1 (en) * 2000-09-19 2002-08-20 Xilinx, Inc. System and method for configuring a programmable logic device
US7290030B2 (en) * 2001-07-13 2007-10-30 Rockwell Automation Technologies, Inc. Internet object based interface for industrial controller
US7542867B2 (en) * 2001-08-14 2009-06-02 National Instruments Corporation Measurement system with modular measurement modules that convey interface information
KR100442439B1 (ko) * 2002-10-07 2004-07-30 엘지전자 주식회사 제어국의 멀티링크에서 링크별 큐 할당 장치 및 방법
US7721273B1 (en) * 2003-11-17 2010-05-18 Rockwell Automation Technologies, Inc. Controller equipment model systems and methods
WO2007139560A1 (en) * 2006-06-01 2007-12-06 Google, Inc. Modular computing environments
DE102009043090A1 (de) * 2009-09-25 2011-03-31 Wincor Nixdorf International Gmbh Vorrichtung zur Handhabung von Wertscheinen
US8504530B2 (en) * 2010-06-26 2013-08-06 Asibo Inc. Global information management system and method
TWI481979B (zh) * 2011-11-08 2015-04-21 Inst Information Industry Programmable logic controller drive system, method and recording media
US8939056B1 (en) * 2012-04-20 2015-01-27 Barron Associates, Inc. Systems, devices, and/or methods for managing targeted payload descent
US9531204B2 (en) * 2013-01-29 2016-12-27 Eco-H Technologies Inc. Portable modular power system
US9274572B2 (en) * 2013-11-08 2016-03-01 Dell Products, Lp High capacity power distribution panel for a modular data center
US11622468B1 (en) * 2018-06-01 2023-04-04 Worldwide Environmental Services, LLC Modular data center

Also Published As

Publication number Publication date
US11782418B2 (en) 2023-10-10
US20210141364A1 (en) 2021-05-13
CN112799351A (zh) 2021-05-14

Similar Documents

Publication Publication Date Title
DE10012258B4 (de) Selbst-Abstimmung in einer verteilten Prozeß-Regelumgebung
DE102008012104A1 (de) Gerätebeschreibungsdatei, System und Verfahren zum Einrichten von Steuer- und/oder Regeleinrichtungen
WO2002065223A2 (de) Steuerungs- und überwachungsanlage von maschinen und/oder anlagen mit aktionskomponenten unterschiedlicher aktionsgruppen
DE10231675B4 (de) Simulationssystem für die Maschinensimulation und Datenausgabe von Steuerdaten für ein Automatisierungssystem
WO2006029994A2 (de) Verfahren zur anpassung von parametern einer steuerungs- oder regelungseinrichtung
DE102017120016A1 (de) Verfahren zur Konfiguration eines zum Testen eines elektronischen Steuergeräts eingerichteten Testgeräts sowie Konfigurationssystem
DE102008018962B4 (de) Verfahren zur Steuerung eines Roboters
DE112015006682T5 (de) Vorrichtung und verfahren zur erzeugung von programmen
DE112013005628B4 (de) Numerische Steuervorrichtung
DE102019217520A1 (de) Verfahren zur modularen Anpassung einer programmierbaren Steuerung
DE112021005055T5 (de) Numerisches Steuersystem und Verfahren zum Steuern von Industriemaschinen
DE102005001430A1 (de) Verfahren zur Beschreibung von Speicherinhalten und zur Beschreibung des Transfers von Speicherinhalten
EP1548527A1 (de) Steuerungs- oder Regelungseinrichtung einer Werkzeug- oder Produktionsmaschine
EP3015995A1 (de) Verfahren zum konfigurieren einer schnittstelleneinheit eines computersystems
WO2010028760A1 (de) Automatisierungssystem mit frameworkbasierter steuerung
EP3629108B1 (de) Projektierung eines automatisierungssystems
DE102019131814A1 (de) Verfahren zum Verknüpfen von Objekten eines Steuerprogramms einer Steuereinheit eines Automatisierungssystems und Entwicklungsumgebung
EP3812885A1 (de) Integrierte simulationscode- und produktionscodegenerierung
DE102017215044B4 (de) Verfahren zum Wechseln auf eine Firmware-Version auf einem elektrischen Steuergerät für ein Antriebssystem, elektrisches Steuergerät und Antriebssystem
DE102016205971B4 (de) Hydrauliksystem, Verfahren zum Parametrieren einer Steuerungselektronik einer Hydraulikkomponente und Recheneinheit zum Kompilieren eines Programmcodes für den Betrieb einer Hydraulikanlage
EP2367084A1 (de) Verfahren für die Konfigurierung einer Steuerungseinrichtung einer industriellen Automatisierungsanordnung und Komponente für eine industrielle Automatisierungsanordnung
DE102008023873A1 (de) Verfahren zum Betrieb eines Antriebssystems
DE102020119853B3 (de) Verfahren zum Steuern eines Automatisierungssystems mit Visualisierung von Programmobjekten eines Steuerprogramms des Automatisierungssystems und Automatisierungssystem
DE102015100736A1 (de) Computerimplementiertes Verfahren zur automatischen Generierung wenigstens eines eine Treiberfunktion repräsentierenden Blocks für eine blockbasierte Modellierungsumgebung
EP3809213B1 (de) Verfahren zur programmierung von steuerungseinrichtungen von maschinen und maschine mit einer steuerungseinrichtung

Legal Events

Date Code Title Description
R012 Request for examination validly filed