Virtuelle Inbetriebnahme - Software in the loop Ansatz - Programme

elCapitan

Level-1
Beiträge
18
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich beschäftige mich derzeit recht intensiv mit dem Thema virtuelle Inbetriebnahme. Ich betrachte derzeit den Software in the Loop Ansatz, d.h. VIBN mit simulierter SPS oder Motion Controller (ähnlich wie in der Robotik mit KUKA Office Lite oder ABB Robotstudio).
Ich nutze im Moment zum Testen Siemens MCD und Simit, das soll aber erst einmal nebensächlich sein.

Für den Software in the loop Ansatz brauche ich ja eine Simulationsumgebung um die SPS zu simulieren. Bei Siemens hat man ja PLC Sim Advanced im Programm, welches über einen Softbus an Simit angekoppelt wird.
Ich komme aus der Siemens Ecke und möchte aber trotzdem auch andere Hersteller betrachten. Hierzu fehlt mir aber etwas Expertenwissen.

Meine Frage deshalb an euch:
Wisst ihr ob es von den anderen großen Herstellern, wie Rockwell, Beckhoff, Schneider, B&R, usw. vergleichbare Software zu PLC Sim Advanced gibt? Falls ja wie heißen diese. Wie funktioniert die Schnittstelle zu SIMIT (OPC UA, Shared Memory, irgendwas proprietäres?), Gibt es irgendwelche Einschränkungen bei den unterstützen Controllern?

Würde mich über ein paar Anregungen zur weiteren Recherche freuen.

P.S. ich weiß, dass es auch die Möglichkeit gibt, Hardware anzukoppeln. Dies ist bei manchen Steuerungen wahrscheinlich auch die Einzige Möglichkeit. Trotzdem möchte ich mich ersteinmal mit einer Software Lösung befassen.

Vielen Dank vorab
 
Hier im Forum wurde mal ein interessanter Ansatz vorgestellt mit dem ich jetzt auch mal "gespielt" habe:
Simulation gleich ins SPS-Programm integriert.
Beispiel:
Viele verwenden Bausteine zur Steuerung von Aktoren.
Hier werden dann z.B. Freigaben und Rückmeldungen gebildet, Laufzeiten überwacht, Sensorsignale geprüft, ...
In diesen Baustein kann man eben auch einfach einen Simulationsmodus integrieren.
Etwas komplexer, aber genauso möglich, ist es bei NC-Antrieben oder Reglern.
Anstelle irgendwelche Events oder physikalische Modelle mit externen Programmen zu simulieren, erfolgt dies alles in der SPS.
Zur Ausgabe dient dann gleich die Visu.

Natürlich funktioniert damit keine Kollisionserkennung, aber viele Programmfehler im Ablauf findet man damit auf jeden Fall.

Gruß
Blockmove
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich Handhabe es wie Blockmove. Ich habe allerdings bis jetzt noch keine Achse simuliert. Aber Ein-/Ausgänge funktionieren und hab schon paar Fehler gefunden die mich bei IBN wahrscheinlich einiges an Zeit gekostet hätten.
 
@Blockmove

Hast einen Link zu dem erwähnten Beitrag?
Würde mich auch interessieren!

Danke
Tommy

Nein, damit kann ich nicht dienen.
Hab's nur gelesen und mir gedacht, dass ich das mal probieren will.

Eigentlich ist es (bei mir) ganz simpel.
Ich nutze zum Ansteuern von Aktoren immer einen FB.
Dort sind Eingänge, Ausgänge, Freigaben und Überwachungen verschaltet.
Im Rest des Programmes wird dann nicht mehr mit den Ein- und Ausgängen direkt gearbeitet.
Simulation ist dann ganz einfach:
Es gibt ein neues Parameter "Simulation" und damit wird einfach über einen Timer beim Schalten des Ausgangs die Rückmeldung aktiviert.
Andere einfache Möglichkeit:
Du hängst dir am OB1 einfach einen Baustein mit Ausgang -> Timer -> Eingang

Bei Achsen wird in jedem Zyklus einfach beim Verfahren ein bestimmter Wert auf den Sollwert addiert.
Solange bis Ist = Soll.

Einfach simpel und spart Zeit
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du hängst dir am OB1 einfach einen Baustein mit Ausgang -> Timer -> Eingang

So mache ich es mittlerweile fast ausschließlich. Zu Beginn des OB1 wird ein Simulations-FB aufgerufen der das Prozessabbild der Eingänge überschreibt. Bei Analogwerten oder Busteilnehmern muss der Adressbereich der Baugruppen dann im Prozessabbild liegen, d.h. es darf dann keine Zugriffe wie PEW geben. Der Vorteil gegenüber einer reinen Simulation z.B. im Antriebsbaustein besteht darin, dass damit auch schon ein Teil der Verwendung von EAs im Programm geprüft wird. Wird z.B. ein Einschaltbefehl für ein Antrieb nicht gegeben weil am Antriebs-FB der Ausgang vergessen wurde, dann fällt das mit dieser Simulation direkt auf.

Praktikabel ist das aber m.M.n. nur für prozesstechnische Anlagen. Um bei Fördertechnik verschiedene Zustände wie Stauverhalten durchzutesten, bedarf es schon einer mehr oder weniger realen physikalischen Simulation der Anlage.
 
Ich nutze zum Ansteuern von Aktoren immer einen FB.
Dort sind Eingänge, Ausgänge, Freigaben und Überwachungen verschaltet.
Im Rest des Programmes wird dann nicht mehr mit den Ein- und Ausgängen direkt gearbeitet.
Das kommt mir bekannt vor. Hatte mir mal einen FB für 2 Aktoren, sprich für 4 Ventile gemacht. Hintergedanke war, für jede Bewegung die ÜberwachungsZeiten individuell anpassen (parametrieren) zu können und BetriebsMeldungen erst nach Überschreiten der Zeiten zu generieren in dem Sinne "Aktion x wartet auf Sensor y=0" oder "Aktion x wartet auf Sensor y=1".
Warum ausgerechnet für 2 Aktoren und 4 Ventile? Spontan fällt mir dazu leider nur ein AnwendungsFall ein, wo eine Achse hydraulisch auf eine von 4 Positionen geschwenkt werden konnte.
Ich hatte aber diverse Anwendungen dafür und ... der Baustein liess sich natürlich auch für z.B. 1 Aktor mit 2 Ventilen verwenden. Dazu musste der Baustein nur mit weniger Parametern bzw. mit DummyParametern versorgt werden. Darum entstand aus Bequemlichkeit noch eine "abgespeckte" Version des Bausteins für 1 Aktor und 2 Ventile.
Was hat das mit Simulation zu tun? Rein gar nichts. Die beiden Bausteine waren "ausgetestet" und funktionierten super und so gesehen war keine Simulation mehr nötig, um die logische Funktion zu prüfen. Eventuelle ParametrierFehler (falschen Ein- bzw. Ausgang parametriert) waren dank den BetriebsMeldungen schnell zu lokalisieren. Die Inbetriebnahme war angenehm und auch die MaschinenBediener haben sich schnell an diese Art der BetriebsMeldungen gewöhnt und waren in punkto "ein Bisschen Mitdenken" nicht überfordert. Viele der früheren DiagnoseMeldungen "prüfe dies und prüfe das und tue dann jenes" waren nicht mehr nötig. Solche DiagnoseMeldungen hatten ohnehin den Nachteil, dass sie selten alle erdenklichen Ursachen von Störungen abdecken konnten und/oder recht schnell in einen unübersichtlichen/unverständlichen Wust von Alternativen ausarteten.
Für TestZwecke war die "ZeitBasis" (für alle ZeitÜberwachungen gemeinsam) variabel gehalten, so dass man ZeitÜberschreitungen provozieren und ggfs entsprechend den gewonnenen Erkenntnissen die Parametrierung individuell anpassen konnte.
 
Praktikabel ist das aber m.M.n. nur für prozesstechnische Anlagen. Um bei Fördertechnik verschiedene Zustände wie Stauverhalten durchzutesten, bedarf es schon einer mehr oder weniger realen physikalischen Simulation der Anlage.

Funktioniert auch bei Maschinen sehr gut.
Fördertechnik ist klar, da funktioniert es nicht ohne weiteres.
Aber da macht auch Simulation - meines Erachtens und bei uns - wenig Sinn.
Da kannst du Simulieren was du willst, in der Praxis ist es immer anders :ROFLMAO:

Das Thema Simulation und virtuelle Inbetriebnahme ist spannend und wird in Zukunft viele Vorteile bringen.
Stand aktuell ist halt, dass der Mehraufwand bei uns in keinem Verhältnis zum Nutzen steht.
Unsere mech. Konstrukteure arbeiten mit NX. Die Basis ist vorhanden.
Aber du musst halt alle Objekte mit ihren physikalischen Eigenschaften ausstatten.
Zusätzlich dann noch Sensoren und Aktoren und SPS-Adressen.
Da muss och einiges in die Entwicklung von NX, TIA, EPlan und PLM fliessen.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die beiden Bausteine waren "ausgetestet" und funktionierten super und so gesehen war keine Simulation mehr nötig, um die logische Funktion zu prüfen.

Heinrich das ist etwas zu kurz gedacht.
Mit der Art von einfacher Simulation wie sie Thomas und ich beschreiben, kannst du deine Schrittketten, Verriegelungen, Handbetrieb, Visualisierung, ... testen bevor überhaupt deine Maschine steht.
Ohne riesige Tabellen in PLCSim.
Diagnosemeldungen für Laufzeiten, Rückmeldungen, Paarüberwachung sind bei uns seit über 25 Jahren Standard.
Hier haben wir vor einiger Zeit auf Programalarm und später auf ProDiag umgestellt.

Gruß
Blockmove
 
So mache ich es mittlerweile fast ausschließlich. Zu Beginn des OB1 wird ein Simulations-FB aufgerufen der das Prozessabbild der Eingänge überschreibt.

So mache ich das mittlerweile immer.

Früher hab ich viel Simit verwendet... Aber der Aufwand mit der Simulation direkt in der SPS ist m.M. geringer.

Generell ist die Frage, was will ich warum simulieren, was bezwecke ich überhaupt mit der Aktion?

M.M. geht es darum, die SPS Software grob im Büro zu testen. Vor allem für Schrittketten sinnvoll.

Nen wirklich dem Prozess entsprechendes Modell, wo auch die Zeitkonstanten passen, um z.B. Regler vorher einzustellen, ist schwierig. Da übersteigt der Aufwand den Nutzen... (Sicherlich gibts Ausnahmen)

Zur Frage PLCSIM oder reale SPS würd ich mich immer für die reale SPS entscheiden, da PLCSIM sich im Detail doch anders verhält...

Gruß.
 
Früher hab ich viel Simit verwendet... Aber der Aufwand mit der Simulation direkt in der SPS ist m.M. geringer.

Letztlich kannst du den gleichen Aufwand auch in die Simulation in der SPS stecken und so auch ähnliche Ergebnisse wie mit Simit erzielen.
Deshalb möchte ich die Simulation eigentlich auch gleich in die Bausteine integrieren. Wenn man den Simulationsteil bei Nichtgebrauch einfach überspringt, dann kostet es auch keine Zykluszeit.
Vielleicht kann man es auch mit Bibliotheken irgendwie clever lösen ... Muss ich mir mal genauer anschauen.
Bei großen Anlagen ist der Simulationsbaustein im OB1 auch ne Menge Arbeit.


Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die beiden Bausteine waren "ausgetestet" und funktionierten super und so gesehen war keine Simulation mehr nötig, um die logische Funktion zu prüfen.
Heinrich das ist etwas zu kurz gedacht.
Ach Dieter, irgendwie habe ich es wieder geschafft, mich missverständlich auszudrücken. ;)
Ich meinte nicht, dass jegliche Simulation unnötig/sinnlos ist, sondern, dass man sich einen LöwenAnteil ersparen kann, wenn man nicht das Rad immer wieder neu erfindet, indem man nicht jedes Detail immer wieder neu codiert, sondern auf halbwegs "universelle", aber zweckmässige/bewährte BlackBoxes zurückgreifen kann.
Simulationen der [noch] nicht vorhandenen Hardware (Maschine/Anlage) z.B. nach "Deiner" Ausgang -> Timer -> Eingang - Methode machen durchaus oft Sinn und habe ich auch häufig angewendet - allerdings noch nie für eine komplette Maschine, sondern für überarbeitete oder komplett neue TeilAufgaben.
Und ja, Thomas hat Recht, die o.g. Methode geht natürlich nur für das ProzessAbbild der Eingänge und wenn man dieses am Anfang (statt am Ende) eines OB1 überschreibt.
Eine Realisierung ohne ProzessAbbilder würde sinnvollerweise in den Bausteinen geschehen, wo die Ausgänge geschrieben und die Eingänge gelesen werden und man den Zustand der Ausgänge vom Zyklus zuvor noch parat haben muss - letzteres ist der eigentliche MehrAufwand.

Gruss, Heinileini
 
Zuletzt bearbeitet:
Wisst ihr ob es von den anderen großen Herstellern, wie Rockwell, Beckhoff, Schneider, B&R, usw. vergleichbare Software zu PLC Sim Advanced gibt? Falls ja wie heißen diese. Wie funktioniert die Schnittstelle zu SIMIT (OPC UA, Shared Memory, irgendwas proprietäres?), Gibt es irgendwelche Einschränkungen bei den unterstützen Controllern?

Würde mich über ein paar Anregungen zur weiteren Recherche freuen.

P.S. ich weiß, dass es auch die Möglichkeit gibt, Hardware anzukoppeln. Dies ist bei manchen Steuerungen wahrscheinlich auch die Einzige Möglichkeit. Trotzdem möchte ich mich ersteinmal mit einer Software Lösung befassen.

Bei Beckhoff kannst du dein Programm in der Runtime auf deinem Entwicklungssystem testen, allerdings weiß ich nicht in wie weit du bei der Hardwarekonfiguration Anpassungen vornehmen musst. Auf die SPS-Daten zugreifen kannst du dann z.B. über das Beckhoff-eigene ADS-Protokoll, oder auch OPC. Wobei es von deiner Simulation abhängt ob OPC dafür überhaupt schnell genug ist, aber da soll ja mit TSN noch etwas kommen.

Simit ist vermutlich über die Plcsim-Api an Plcsim-Advanced gekoppelt. Beim Plcsim für die S7-300/400 war diese Schnittstelle in Form des S7ProSim-COM-Objekts immer verfügbar. Bei TIA-Plcsim benötigst du dazu leider die Advanced Version.
Ich kann jetzt nur für S7ProSim sprechen weil ich damit schon viel gearbeitet habe. Dabei war der Vorteil, dass sich damit direkt die Peripherie simulieren ließ. Also auch Zugriffe im SPS-Programm über PEW/PAW abgefragt und simuliert werden können. Leider wurde nur Profibus und keine Profinet-Hardware unterstützt.

Was bei der ganzen Simulation auch unter den Tisch fällt, ist die Diagnosefunktionalität von Baugruppen, das lässt sich wirklich nur mit der echten Hardware testen.
 
Was bei der ganzen Simulation auch unter den Tisch fällt, ist die Diagnosefunktionalität von Baugruppen, das lässt sich wirklich nur mit der echten Hardware testen.

Baugruppen haben doch bei der virtuellen Inbetriebnahme keine Fehler.
Peripherie, Antriebe, Safety und Profinet laufen ja auch bei der virtuellen Inbetriebnahme sofort und haben keine Fehler.
Einen Tag Fehlersuche weil eine GSDML nicht passt, wird es auch nicht geben.
Die Inbetriebnahme und Simulation entwickelt sich vom Textadventure (PLCSIM) zum Egoshooter (NX).
Hoffen wir mal, dass die Werkzeugkiste gut gefüllt ist und die Anzahl der Leben unbegranzt ist :ROFLMAO:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

grundsätzlich einmal danke für die Antworten. Leider sind diese bis auf eine m.M.n. tatal an der Frage vorbei. Wollte hier keine Grundsätzliche Diskussion sarten, ob die Simulation in Simit oder in der SPS stattfindet.

Die Frage war ja ob es Lösungen wie PLC Sim Advanced von anderen Herstellern gibt. Wenn man das nicht weiß, lieber nichts dazu schreiben, so wird das Thema nur aufbläht und es bringt nichts. Wer gerne über Simulation in der SPS diskutiert, kann ja gerne einen eigenen Beitrag machen.

: Das könnte schon ein Vorteil von TwinCat oder Beckhoff sein, dass man ja quasi das reale Programm einfach auf einem "normalen" PC laufen lassen kann. Ich habe jetzt nicht so viel Erfahrungen mit TwinCat (nur mal ein bisschen rumgespielt). Wie könnten die Daten mit Simit ausgetauscht werden. Ich denke OPC UA ist eine Möglichkeit die aber eigentlich wegen dem Echtzeitverhalten rausfällt denke ich. Vielleicht gibt es Möglichkeiten mit Shared Memory zu arbeiten? Bei ABB funktioniert das z.B. mit Robotstudio und Simit sehr gut.
 
Ich kenne Simit selber nicht. Die Simulation wird doch vermutlich auch in festen Zeitabständen aufgerufen, und nicht synchron mit dem SPS-Zyklus. Wichtig ist, dass die Kommunikation entsprechend schnell zu den Zeitkonstanten die in deiner Simulation vorkommen ausgeführt wird. Es kann also sein, dass OPC UA für deinen Anwendungsfall durchaus ausreichend schnell ist, ich denke mal auf Echtzeit kann man bei einer Simulation hier verzichten. Man sollte aber darauf achten dass die angestrebte Geschwindigkeit auch erreicht wird.

Ich habe selber schon einmal so eine Simulationsumgebung mit verschiedenen Gameengines aufgesetzt, in Form einer 3D-Umgebung mit simulierten physikalischen Objekten. Dort läuft der Zyklus der Simulation üblicherweise bei einer Framerate von 50 oder 60 Hz entsprechend 20 ms Zyklus, dementsprechend sollten min. alle 20 ms die Daten aus der Simulation in der SPS landen und Ausgänge für den nächsten Zyklus zurückgelesen werden (möglichst schneller weil nicht synchronisiert). Was übrigens über S7ProSim zu Plcsim nicht zu erreichen ist wenn viele Variablen einzeln gelesen werden, weil die S7ProSim-Schnittstelle sehr langsam ist. Mit ADS über Netzwerk zu einer Beckhoff PC-Runtime konnte ich die Geschwindigkeit problemlos erreichen.
 
Ich kenne Simit selber nicht. Die Simulation wird doch vermutlich auch in festen Zeitabständen aufgerufen, und nicht synchron mit dem SPS-Zyklus. Wichtig ist, dass die Kommunikation entsprechend schnell zu den Zeitkonstanten die in deiner Simulation vorkommen ausgeführt wird. Es kann also sein, dass OPC UA für deinen Anwendungsfall durchaus ausreichend schnell ist, ich denke mal auf Echtzeit kann man bei einer Simulation hier verzichten. Man sollte aber darauf achten dass die angestrebte Geschwindigkeit auch erreicht wird.

Ich habe selber schon einmal so eine Simulationsumgebung mit verschiedenen Gameengines aufgesetzt, in Form einer 3D-Umgebung mit simulierten physikalischen Objekten. Dort läuft der Zyklus der Simulation üblicherweise bei einer Framerate von 50 oder 60 Hz entsprechend 20 ms Zyklus, dementsprechend sollten min. alle 20 ms die Daten aus der Simulation in der SPS landen und Ausgänge für den nächsten Zyklus zurückgelesen werden (möglichst schneller weil nicht synchronisiert). Was übrigens über S7ProSim zu Plcsim nicht zu erreichen ist wenn viele Variablen einzeln gelesen werden, weil die S7ProSim-Schnittstelle sehr langsam ist. Mit ADS über Netzwerk zu einer Beckhoff PC-Runtime konnte ich die Geschwindigkeit problemlos erreichen.

Doch Simit und PLCSim Advanced werden synchronisert. Der SPS Zyklus wird automatisch pausiert, wenn z.B. Simit länger braucht. 5ms sind dann zwar keine 5ms aber die beiden Umgebungen bleiben synchron.

Bei OPC UA habe ich bei Siemens gelernt, dass die Taktzeiten >100ms sein können, das macht es, zumindest für meine Anwendungen, uninteressant.

Ich denke ADS von Beckhoff müsste die Anforderungen erfüllen. Die Software virtuos von isg nutzt meines Wissens diese Schnittstelle und dort spricht man von Zykluszeiten von 1ms, was eigentlich ausreichend sein müsste für die meisten Anwendungen. Leider hat Simit keine ADS Schnittstelle, oder doch?

Mich interessiert vor allem auch Rockwell.
Leider findet man über diese Themen recht wenig im Netz.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Doch Simit und PLCSim Advanced werden synchronisert. Der SPS Zyklus wird automatisch pausiert, wenn z.B. Simit länger braucht. 5ms sind dann zwar keine 5ms aber die beiden Umgebungen bleiben synchron.
Ah ok, das bietet das Plcsim für die S7-300/400 auch an, ich habe das aber nie weiter verwendet.

Ich denke ADS von Beckhoff müsste die Anforderungen erfüllen. Die Software virtuos von isg nutzt meines Wissens diese Schnittstelle und dort spricht man von Zykluszeiten von 1ms, was eigentlich ausreichend sein müsste für die meisten Anwendungen. Leider hat Simit keine ADS Schnittstelle, oder doch?

Ich habe bei ADS auch nur maximal schnell gepollt, mit dem Ergebnis dass es von Beckhoff für den Fall ausreichend schnell implementiert wurde. Belastbare Dokumente gibt es von Beckhoff auch nicht, wie das mit vielen Variablen skalierbar ist.

Wenn ich in das Handbuch von Simit schaue, dann gibt es dort die Shared-Memory Kopplung als einzige universale Schnittstelle. Du könntest also einen eigenen Server schreiben der diese Shared-Memory-Schnittstelle bedient, und nach extern dann die Anbindung an deine eigentliche Steuerung (Beckhoff-ADS, Rockwell, etc.) realisiert. D.h. den shared Memory mit Daten aus der SPS befüllt und in die andere Richtung an die SPS schickt. Im einfachsten Fall ein großer Speicherbereich mit einer Anzahl Bytes für die Eingänge und für die Ausgänge.
 
Das Beispiel mit direkt in der SPS Simulieren lässt sich ja u.U. auf alle anderen Steuerungen übertragen... Und dann ließe sich auch ohne Hardware das ganze Simulieren, falls es von dem Hersteller eine Soft-SPS gibt. Von Siemens musst Du ja auch nicht PLCSIM nehmen sondern könntest auch die Soft-SPS kaufen...

Gruß.
 
Moin elCapitan

ich nutze für so etwas Emulate3D. die wurden vor 2 Jahren von Rockwell gekauft. Mit der Software kannst du Kinematicen direkt in deinem CAD tool (Solidworks Inventor oder CREO) hinterlegen und die dann im Emulate3D direct mit jeglicher Steuerung verbinden. Egal ob Siemens. Rockwell B&R oder OPC UA... Also jeder. Auch ist es mglich jegliches grafisches file format einzulesen und zu "animieren".
Da du ja aus der Siemens ecke kommst, sollte ich erwähnen, dass Sim Advanced auf voll unterstützt wird.
Bin bis jetzt ganz zufrieden. Natürlich muss man ab und an mal seinen Code für die Simulation etwas optimieren.

Gruß
 
Zurück
Oben