[ TwinCAT ] POEs im laufenden Betrieb austauschen

[caret]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gib es in TwinCAT eigentlich eine Möglichkeit "Projektteile" wie Funktionsbausteine oder andere POE oder gar ganze Programme zur Laufzeit auszutauschen?

Hintergrund dieser Frage ist, dass ich ja nicht immer gleich die ganze Anlage abschalten kann/darf sobald ich auch nur eine einzige Änderung im Coding mache. Was ich eigentlich brauche sind ganz viele kleine Soft-SPSen die ich zur Laufzeit bliebig und ggf. mit geändertem Coding rauf- und runterfahren kann.

Wenn ich das richtig sehe, kann ich natürlich im System-Manager zusätzlichen Task definieren und die Soft-SPSen in einer Hochsprache lösen (z.B. jede SoftSPS in eigenen Task oder Prozess). Allerdings bin ich anforderungsmässig an die IEC Sprachen und TwinCAT-PLC gebunden.

Weitere Frage: Gibt es eine Möglichkeit irgendwelche POEs dynamsich zu Laufzeit zu erzeugen?

Hintergrund: Die Definition der Soft-SPSen (Typ, IO, Parameter, usw.) ist ein Parameter meiner Anwendung, d.h. ich weiss zur Compilezeit noch gar nicht genau welche und wie viele das überhaupt sind.

Eine Lösung wäre ein Array von Funktionsbausteinen vom Typ SoftSPS anzulegen und Typ, IO und Parameter zur Laufzeit zu setzen. Problem dabei ist nur, dass mich die nachher unbenutzten FB reichlich Resourcen (Speicher, CPU, usw.) kosten.

 

[Fx64]

Hallo,

Du kannst ein sogenannten OnlineChange mit dem PlcControl durchführen, aber das Tool benötigst Du immer dazu - von Deiner Applikation bzw. Dein Programm kann dies nicht.

Viele Grüße

 

[caret]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe eine Möglichkeit gefunden Funktionsbausteine zur Laufzeit (in einem vorher reserviertem Speicherbereich) zu erzeugen und wollte die hier mal vorstellen bzw. zur Diskussion stellen:

VAR

fbMyFb:FB_MY_FB;
arrFakeFb:ARRAY[0..1023] OF BYTE;
ptrFakeFbOINTER TO FB_MY_FB;
​

END_VAR


iF ( bMakeCopy=TRUE ) THEN

ptrFakeFb:=ADR(arrFakeFb)
MEMCPY( ptrFakeFb, ADR(fbMyFb), sizeof(fbMyFb) );
​

END_IF

fbMyFb();
ptrFakeFb^();
​

Aufpassen muss ich dabei nur, dass mein arrFakeFb Array mindestens die Größe sizeof(FB_MY_FB) hat (notfalls leg ich es entsprechend großzügig aus) und das der MEMCPY nur einmal aufgerufen wird.
Das ganze lässt sich natürlich auf mehr Instanzen ausweiten. Da es allerdings kein malloc wie in C gibt muss ich natürlich zur Compilezeit sowiel Speicherplatz reservieren wie ich nachher max. Funktionsbausteine erzeugen möchte. Entsprechend auch ein Array von Pointern, die in diesen Speicher zeigen.

Das ganze ich zwar irgendwie eine Pointer-Schweinerei, aber es funktioniert. Was ich mich allerdings frage ist, ob ich solchen Code auch problemlos auch auf andere Steuerungen direkt portieren kann.

 

[Ralle]

Was ich mich frage, wenn du eh den Speicherplatz schon vorher reservieren mußt, kannst du doch auch gleich die Funktionen zur anlegen und erzeugen. Was bringt das Ganze, außer, daß kam jemand anderes hinterher mit dem Code klarkommt.

 

[caret]

Was ich mich frage, wenn du eh den Speicherplatz schon vorher reservieren mußt, kannst du doch auch gleich die Funktionen zur anlegen und erzeugen. Was bringt das Ganze, außer, daß kam jemand anderes hinterher mit dem Code klarkommt.

Das mit der fehlenden Übersichtlichkeit des Codes ist ein Punkt den ich in Kauf nehmen muss. Die Vorteile wiegen es einfach auf. Für meine Anwendung benötige ich eine sehr große Anzahl von IOs die von sehr vielen relativ kleinen Soft-SPSen angesteuern werden. Bei den Soft-SPSen unterscheide ich noch etliche Typen, d.h. die laufen mit unterschiedlichem Coding. Die Idee ist nun jede SoftSPS durch einen FB zu realisieren. Knackpunk der dynamischen FBs ist, dass ich im Betrieb der Anlage volle Kontrolle über die SoftSPSen hab, d.h. ich kann sie zur Laufzeit umparametrieren, ein- und ausschalten, den Typ ändern usw. ohne, dass ich die ganze Anlage anhalten muss. Des Weiteren erfolgt die initiale Definition der Soft-SPSen aus einer Parameterdatei heraus, d.h. ich lade bei hochlaufen der Steuerung eine Datei mir den Definitionen. Insbesondere weiß ich zum Compilezeitpunkt also noch gar nicht welche und wie viele Soft-SPSen ich benötige. Das einzige was ich weiß ist wieviel Speicher und GHz meine Steuerung hat wodurch die max. Anzahl Soft-SPSen begrenzt ist.

EDIT: Wenn ich Speicher dynamisch allokieren könnte wäre das natürlich noch besser. Aber scheinbar gibt es diese Möglichkeit ja nicht, weshalb ich mir eben mit statischem Speicher behelfen muss.

 

[trinitaucher]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also ich persönlich halte deine Idee für Schwachsinn.

Im TwinCAt System Manager musst du die E/As mit dem E/A-Prozessabbild für die "Soft-SPS" (ich nenne es Runtime) vorher definieren und Verknüpfungen herstellen.
Somit ist die E/A-Größe und der Weg in die SPS schonmal fest und im laufenden Betrieb nicht änderbar.

Du kannst bei Twincat bis zu 4 SPS-Runtimes erstellen und sogar einzelne Abschalten. Allerdings nicht beliebig, glaube ich, denn die Runtime mit der höchsten Priorität muss immer laufen... kann mich aber auch irren.
Doch auch hier muss das E/A-Prozessabbild voher feststehen.

Das einzige, was du beeinflussen kannst, ist die Ausführung von PRGs und FBs zur Laufzeit.
Hier könntest du über simple boolsche Befehle einzlene PRGs ausführen oder auch nicht.
Anhand der momentan am Bus vorhandenen E/As (Maschinenteile) würde dann ein Stück Code ausgeführt oder eben nicht.

Das ganze Pointer-Gerickel bringt mehr Risiken als Nutzen, finde ich.

 

[zotos]

Der Sinn dieser Aktion erschließt sich mir so gar nicht. Ich hoffe nur das Du weißt was Du da treibst. Wäre trotz dem nett wenn Du versuchen würdest die Intention Deines Vorhabens zu erläutern. Bei den SoftSPSen aus dem Hause Beckhoff sollte der Speicherplatz wirklich kein Problem sein.

 

[caret]

Ja, ich ich weiss genau was ich tue. Ich weiss nur nicht ob es evtl. eine elegantere Lösung gibt.

Um mal eine Größenordung für unsere Anwendung zu geben:

Für die Steuerung von 1500 IOs und 20 RS422 benötigen wir um die 500 SoftSPSen die bis zu 30 unterschiedliche Typen haben. Alle SoftSPSen kommunizieren über TCP/IP mit der Leitebene. Je nach Anlagengröße benötigen wir bis zu einem Dutzend echter SPSen die die eben genannten Leistungsmerkmale erfüllen. Klingt recht mächtig, ist aber machbar. Wir haben nämlich bereits eine sehr gut funktionierende Lösung in C/C++ unter einem Realtime Linux auf der Basis von Embedded Siemens PCs laufen. Aus "politischen" Gründen möchten wir aber auch eine Lösung unter TwinCAT in einer IEC 61131-3 Sprache anbieten. Klar ist, dass wir leistungsmässig mit der CX nicht in diese Region vorstossen werden können. Der Overhead durch Windows CE/XP und TwinCAT selbst ist einfach zu groß. Wir möchten einfach der bisherigen Lösung so nahe wie möglich kommen.

Meine Idee: Die SoftSPS werden durch Funktionsbausteins modelliert. Dazu wird jeder Instanz eine Priorität zugeordnet anhand derer bestimmt wird in welcher der drei Runtimes (LOW, MID, HIGH) sie aufgerufen wird. Im 4. Thread, d.h. der 4. Runtime, läuft ein Framework welches die Verwaltung (anlegen, löschen, IO zuordnen, usw.) erledig. Alle IOs werden manuell und eben auch "vorher" im Systemmanager auf IOs der Frameworks gemapt. Im Framework werden diese dann aber noch einmal auf die logische IOs der FB gemapt. Die Grundkonfiguration der FB (Anzahl, Typen, IOs) wird beim starten der CX aus einer Konfigurationsdatei (wird aus unserem Anlagenplanungstool exportiert) gelesen und die notwendigen FB Instanzen und die dazu passende Aufrufe mit dem gewünschten IO-Mapping generiert. Die finale Parametrierung der FBs wird im folgenden dann manuel mit Hilfe der in TwinCAT PLC entworfenen HMI vorgenommen.
Implementiert und gestest hab ich das ganze auch schon. Es läuft. Allerdings bisher eben noch mit einer relativ kleinen Anzahl sehr einfacher FBs. Was mir noch fehlt ist ein richtiger Leistungstest und die TCP/IP Kommunikation. Letztere wird mir Leistungsmässig wahrscheinlich komplett die Knochen brechen, da ich noch ein recht komplexes Kommunikatiosprotokoll fahren muss.

P.S.: Pointer scheinen ja hier im Forum ein rotes Tuch zu sein. Ich bin auch nicht sehr glücklich mit Ihnen. Bisher ist das obige Ansatz aber die einzige Lösung die ich kenne. Wenn jemand eine bessere Idee hat wie man dynamisch irgendwelche POEs erzeugen kann der rennt bei mir garantiert in offene Arme.