Workflow & SPS, Konzept
Hallo,
wie bekommt man heutzutage SPS und .NET unter einen Hut?
SPS meldet Sensoränderung, Flanke, Eingänge etc.
Wer steuert....
UI nur mit .NET, oder steuert jetzt die Workflow?
Das Konzept ist mir nicht ganz klar.
Vielleicht kann jemand ein paar Tipps geben, wie das alles vorgesehen ist.
Im Link wird auch eine SPS + Workflow verwendet.
Workflow Foundation: Externe Events in einen Workflow integrieren
Grüße Oliver
wie bekommt man heutzutage SPS und .NET unter einen Hut?
Sicher, dass das überhaupt funktioniert? Denn .NET ist ja nicht echtzeitfähig und mit WF drüber noch weniger. Und eine SPS ohne echtzeitfähige Steuerung - na viel Spaß.
Wir haben mal in einer Testumgebung eine SPS mit .NET bedient (Windows CE). Da musste man schon höllisch aufpassen, dass man den Code so schreibt, dass nie der GarbageCollector losläuft (sonst stand alles).
Hallo,
ob es funktioniert weiß ich nicht. Deshalb frage ich 😉
Wie macht man es? Die Automatisierungsmaschinen, die an SAP, MES angebunden sind?
UserInterface mit .NET -- dann DLL oder OPC? --- SPS
Beckhoff?
Ich weiß es nicht. Gerne darf man mitr Tipps geben.
Für was ist dann die Workflow gut?
Mehr andere Anwendungen ohne Hardware?
Grüße Oliver
Hallo Kollegen,
wo liegt das Problem?
Wenn man nur mit SPS reden will, braucht man ja nicht Echtzeitfähig sein. Wenn du zum Beispiel Meldungen hast, bei denen eine Verarbeitungszeit ~ 100 bis 200ms reicht, dann hast du definitiv keine Probleme. Draußen gibts auch Lösungen, bei denen SAP- oder andere ERP-Systeme direkt mit der SPS reden.
Du musst auch mit bedenken, dass ne SPS selber eine Zykluszeit hat, nach dem was ich gehört habe auch zum Teil zwischen 30 und 40ms. Da kann der GC schon ein paar mal laufen, bis man die Zeit erreich..
Zum Kommunikationsweg: Frag am besten die SPS'ler, was für beide Seiten am einfachsten ist. TCP/IP Native können die meisten, OPC wär ich vorsichtig, da brauchst du eigene Bibliotheken dafür und die Entwicklung kann am Anfang etwas schwierig sein. Das C# Programm würde ich aber nicht auf einem Windows CE, sondern dann eher auf Embedded aufwärts laufen lassen mit entsprechend guter PC-Hardware.
Wegen Workflow: Das musst du dir gut überlegen, ob du die verwenden willst. Ich persönlich finde (zumindest die WF4) zwar cool, hängt aber vom Anwendungsfall ab. Schau dir am besten ein paar Tutorials durch, damit du es selbst abschätzen kannst. Speziell für diesen Fall vorgesehen sind sie übrigens gar nicht, sie sind zur Steuerung von langläufigen Geschäftsprozessen da. Aber wenn, dann auf jeden Fall WF 4 verwenden und nicht WF3 (schon alleiene wegen der Performance)
Gruß
Roland
wo liegt das Problem? [...] Wenn du zum Beispiel Meldungen hast, bei denen eine Verarbeitungszeit ~ 100 bis 200ms reicht, dann hast du definitiv keine Probleme.
Oliver Stippe redete von Sensoränderungen, Flanken usw., also habe ich ihm mal unterstellt, dass er dann entsprechend Aktuatoren ansprechen möchte. Und da kommt man um Echtzeitfähigkeit nicht herum.
Du musst auch mit bedenken, dass ne SPS selber eine Zykluszeit hat, nach dem was ich gehört habe auch zum Teil zwischen 30 und 40ms. Da kann der GC schon ein paar mal laufen, bis man die Zeit erreicht.
Die Beckhoff-SPS, die wir benutzt haben, war (soweit ich mich erinnere) mit 10ms getaktet. Und sobald sich das Steuerungsprogramm in einem Zyklus nicht zurückmeldet, weil der GC gerade mal aufräumt, bleiben alle Ausgänge auf aus. Sieht lustig aus, wenn so eine Fertigungsstraße zittert (okok, die war aus Fischertechnik gebaut).
Also @Oliver Stippe: Über welches Level reden wir hier? Ist eine Sensormeldung für dich eher ein "Endlagenschalter erreicht" oder ein "Produkt fertiggestellt"?
Gruß,
dN!3L
Hallo Zusammen,
Ich möchte ein Sensor, Erfassungssensor mitbekommen.
Positive negative Flanke. Statische Signale >50ms und <100ms
Wie macht man es heute....niemand kann da eine Auskunft geben.
SCADA, SAP, MES ------ XML /.NET --- UserInterface --- SoftSPS(Beckhoff, Siemens?) --- Sensorik
Das Userinterface soll muss ja das visualisieren.
Der Bediener setzt einen Ausgang, die Ampel geht an.
Wie sind da die Wege....., Zustände, Statemachine?
StateMachine, deshalb Workflow dachte ich....
Danke für Tipps, Beispiele im Voraus.
Grüße Oliver
Hallo Oliver Stippe,
ich bin nun wahrlich kein Workflow-Experte und kenne auch WF4 kaum. Trotzdem scheint mir der springende Punkt zu sein, welche Vorstellung man davon hat, wer in der Anwendung "das Sagen hat" hat, der Workflow oder die klassische Steuerungsinstanz - also bei Consolen-Anwendungen die Main-Methode, bei Windows-Forms-Anwendungen das Application.Run zusammen mit den EventHandlern für Benutzereingaben, bei Diensten die Schleife für die eingehenden Requests usw.
Nach meiner Einschätzung behält die klassischen Steuerungsinstanz die Steuerung und stößt immer nur den jeweils passenden Workflow an. Die (einzelnen) Workflows sind also nach meiner Ansicht nur Mittel zu Zweck und haben nicht die Hoheit über die Gesamtsteuerung. Siehe auch Hosten von Workflows: Verwenden von WorkflowInvoker und WorkflowApplication.
herbivore
Hallo herbivore,
ok Danke.
Aber wo kann man nachschauen, Infos einholen wie das zweckmäßig heute gemacht wird.
Wer hat das Sagen, ja wer ist der Chef, wer steuert.
Wie wird im Maschinenbau heute primär entwickelt.
Abser sonst sicher mal beantwortet. Ist eine schwierige Frage.
Grüße Oliver
Also wir haben mit Hilfe der ComDrvS7 von IBH ein Projekt umgesetzt um mit einer SPS zu kommunizieren. Da ging es jedoch nicht um die Steuerung einer SPS, sondern im wesentlichen nur um die Abrage von Statuszuständen.
Einfache Befehle, um z.B. die Ware von einer Anlage auszupushen, geht natürlich auch.
Also wir haben mit Hilfe der ComDrvS7 von IBH ein Projekt umgesetzt um mit einer SPS zu kommunizieren. Da ging es jedoch nicht um die Steuerung einer SPS, sondern im wesentlichen nur um die Abrage von Statuszuständen......
Hallo,
kannst Du das verdeutlichen?
Ausgänge setzen
Eingänge statisch abfragen
Zustände über Flanken, pos./neg. als Event in das C# Programm.
Wer steuert dann...?
Was brauche ich?
Grüße Oliver
Ich meinte natürlich die Firma MHJ und nicht IBH, sorry. Die Links sind beide richtig (dasselbe Produkt).
Zum Glück bin ich kein SPS-Programmierer, von daher kann ich nicht ins Detail einsteigen. Der Treiber bietet im wesentlichen Methoden an, um Ein- und Ausgänge (oder auch Zähler und Codeunits; ich glaube, die nennt man so) abzufragen oder zu setzen. Das Ganze muss aktiv von der Applikation aus gehen, ist also nicht Event gesteuert seitens der SPS.
Was das Steuern und Regeln angeht, so muss das wohl meiner Ansicht nach das SPS-Programm machen. Dafür ist es ja schließlich da.
Was das Steuern und Regeln angeht, so muss das wohl meiner Ansicht nach das SPS-Programm machen. Dafür ist es ja schließlich da.
Hallo,
ok.
Zustandsänderung, Sensor Ein/Aus
Das Steuern die SPS.
Das Visualiseren .NET/C#, der Bediener will ja sehen. Eingang 4 ist an oder aus.
Was mir dann immer noch nicht klar, muss ich dann was abpollen?
Gibt es irgendwo Konzeptbeschreibungen?
Ich bin auch kein SPS Programmierer muss/darf mal die Scada,MES Gegestelle programmieren.
Das logische Modell, Konzept muss aber stehen, klar sein.
Wie macht man es in 2012 richtig?
Was ist zielführend?
Grüße Oliver