# CODESYS Control for PFC200 SL



## annD (22 Dezember 2015)

Hallo zusammen,

hat schon jemand diese SoftSPS für den Wago PFC200 eingesetzt? Es klingt insofern interessant, weil es mit dem neuen kostenlosen Codesys V3 programmiert wird und die Lizenz für die Laufzeitumgebung relativ günstig ist. In diesem Fall erspart man sich die teuren Lizenzen für das Wago e!COCKPIT. Der Download ist im Codesys-Store verfügbar.

Kann jemand einen praktisch relevanten Nachteil durch den Einsatz dieser SoftSPS gegenüber der originalen Wago-Laufzeit für e!COCKPIT erkennen?

Schöne Grüße,
annD


----------



## _andre_ (23 Dezember 2015)

Hört sich sehr verlockend an. Wie bekommt man da wieder die Orignal-Firmware/Runtime auf den Controller? Wenn das wieder problemlos klappt wäre es einen Versuch wert.


Gruß
André


----------



## HausSPSler (23 Dezember 2015)

Hallo Andre,
klar mit dem Firmware Reset, also Taste nach unten + Resetknopf und dann das Gerät einschalten, dann bist du wieder in der original Umgebung.
Grüße


----------



## annD (8 Januar 2016)

Hallo,

ich habe inzwischen alle digitalen Ein- und Ausgänge für Licht,  Raffstoren usw. an meinem PFC200 mit dem derzeit aktuellen Codesys V3.5 SP8 und der SoftSPS V3 erfolgreich in Betrieb nehmen können.

Nur bei den speziellen Funktionen inkl. verwendeter Bibliotheken blicke ich noch nicht durch. z.B. möchte ich gerne über Ethernet/UDP Art-Net-Daten (DMX) senden oder über Modbus TCP Daten einlesen.

Schöne Grüße,
annD


----------



## Vittel01 (8 Januar 2016)

Was kostet denn die soft sps Lizenz?
Funktionieren da auch die libs von wago? Oder ist man da ganz auf die Oscad oder Standart lib angewiesen?  
Schau mal auf YouTube. Da gibt es Video tut's 
Die frage ist nur in dein dmx Controller modbus kann?



Gesendet von iPhone mit Tapatalk


----------



## annD (8 Januar 2016)

Die Lizenz kostet derzeit 70€ + MWSt. Als kostenlose Demo kann man es für jeweils 2 Stunden testen. Das mit den libs hab ich noch nicht durchschaut. Es gibt alle Standard-Bibliotheken von 3S (Standard, Util, usw.) und die Oscat-Bibliotheken.

Meine DMX-Controller sind per DMX-Leitung mit einem Art-Net/DMX-Node verbunden. Dieser kann per Ethernet mit Standard-Art-Net-Befehlen angesteuert werden. Per Notebook und Apps für Tablet/Handy über WLAN funktioniert es bereits einwandfrei. Art-Net sind in Prinzip einfache UDP-Befehle.

Gruß annD


----------



## Vittel01 (8 Januar 2016)

Im vergleich zu 600 ja ein Schnäppchen wenn mann sie nur einmal verbaut..  
Kannst du mal eine Wago lib testen?

Suche mal in google auf wago art net
Da gibt es einige Beiträge  der von oscat sieht  gut aus


Gesendet von iPhone mit Tapatalk


----------



## CarpeDiem (11 Januar 2016)

Soweit ich sehe, ist diese Runtime für die PFC200 aber nur für das Basissystem,  Visualisierung kostet extra? Oder verstehe ich das als Anfänger falsch?


----------



## HausSPSler (11 Januar 2016)

nein Webvisu ist dabei...!


----------



## annD (12 Januar 2016)

Hallo HausSPSler,

gibt es eine Möglichkeit die originalen Wago-Bibliotheken (z.B. WagoAppCom 1.5.0.0) auch zu verwenden?

Gruß


----------



## HausSPSler (13 Januar 2016)

Hallo,
momentan noch nicht... müsste man Wago fragen ob das möglich gemacht wird.

Grüße


----------



## CarpeDiem (14 Januar 2016)

Hallo zusammen, Herr Schwellinger, 

vom Gefühl her wird das eher  nicht passieren. Oder hätte ein erfahrener Kollege mehr Hoffnung? Will  nicht Wago seine Kunden auf einen ganz anderen Pfad führen?

...  ich habe die Doc jetzt nochmals wirklich gelesen, und gewinne den  Eindruck, dass recht viel geboten ist. Visu ist dabei und von den  Standardklemmen werden sehr viele unterstützt.



Leider  nicht alle, wie auch, geht ja nicht mit vernünftigen Aufwand.  Erwähnenswert wäre aber die 750-541, "8-Kanal-Analogeingangsklemme; RTD  frei konfigurierbar", die das beste Verhältnis Anzahl Eingänge pro  Breite/Preis/Stromverbrauch/... bietet.

Ähnlich verhält es sich mit der 750-440, "4-Kanal-Digitaleingangsklemme; AC 120 (230) V; positivschaltend; 1-Leiter-Anschluss"

Gibt es einen Plan, diese Standard-IO-Klemmen nach und nach ebenfalls zu unterstützen?
Komplett  fehlen Kommunikations- und Sonderklemmen, es wird bis auf weiteres  keinen Funk, kein DALI, kein Proportialventil und keinen Zählereingang  geben?


Gruß,
CarpeDiem


----------



## HausSPSler (14 Januar 2016)

Hallo CarpeDiem,

Teil 1: deiner Frage siehe Screenshot
Teil 2: noch keinen Plan und keinen PlanB ;-)
Grüße


----------



## CarpeDiem (6 März 2016)

Liebe Community, Hallo Herr Schwellinger,

ich habe (nun) ein System "Codesys Development 3.5 SP8" mit "Codesys WagoPFC200 Runtime" am Laufen, und auch alle IO-Module incl. der neueren 16-Kanal DIO werden out-of-the-box unterstützt 

Mit der 750-451 (8AI RTD) habe ich aber noch die Schwierigkeit, dass sie sich nicht konfigurieren läßt. Ein Doppelklick öffnet die Einstellungen mit den Mappings und das alles (wie im Bild oben), nicht aber die Möglichkeit z.B. den Sensortyp einzustellen.

a) Die Hilfe zur visuellen Konfig verweist auf einen FDT Framework und/oder auf Treiberfiles (DTMs?), die der Hersteller der Module zur Verfügung stellen würde und dies dann zulassen würden. Bei Wago ist aber nirgends etwas zu finden, viele Docs, Pdfs und Zertifikate, aber kein einziges .xml oder .dtm oder was auch immer. Wo müsste ich da suchen?

b) Eine "zu Fuss" Konfiguration wäre auch über die Status- und Control-Bytes der Klemme möglich. Allerdings vermisse ich diese in ihrem V3.5-Prozessabbild. Muss ich, um diese zu sehen, eine Art Expertenmodus einschalten?


Ziemlich ratlos,
CarpeDiem


----------



## HausSPSler (7 März 2016)

Hallo CarpeDiem,
du musst *WAGO-I/O-CHECK *verwenden um die Klemmen zu konfigurieren.
Dann sollte das gehen.
Grüße


----------



## CarpeDiem (7 April 2016)

-- zweimal gepostet, sorry --


----------



## CarpeDiem (7 April 2016)

Hallo zusammen, Herr Schwellinger,

das ganze läuft jetzt seit geraumer Zeit, Visu nicht ganz stabil (derzeit Prio 2), aber der Rest ist prima 

Prio1 ist derzeit eine penetrante, hochfrequente Fehlermeldung im Log, zu finden u.a. unter Diagnostics im Webingterface:Thu Apr 07 2016 12:09:01.253745 codesys: Event reset:High CPU usage detected ERR% 
Thu Apr 07 2016 12:09:01.253745 codesys: Event reset:High CPU usage detected ERR% 
Thu Apr 07 2016 12:09:01.271192 codesys: Event reset:High CPU usage detected ERR% 
Thu Apr 07 2016 12:09:01.271192 codesys: Event reset:High CPU usage detected ERR% 
Thu Apr 07 2016 12:09:01.289161 codesys: Event reset:High CPU usage detected ERR% 
Thu Apr 07 2016 12:09:01.289161 codesys: Event reset:High CPU usage detected ERR%​
Das sollte aber nicht sein, die Applikation ist leer (Template "Standardprojekt") außer einem manual ergänztem RETURN in PLC_PRG: Aufgerufen zyklisch alle 20ms mit Prio 1. Der 600MHz ARM Prozessor der PFC200 sollte das schon hinbekommen...

Die Überwachung zeigt:
	

		
			
		

		
	




"top" unter Linux teilt mit (worst case):top - 12:23:26 up  3:54,  1 user,  load average: 2.07, 1.92, 1.88
Tasks:  79 total,   1 running,  78 sleeping,   0 stopped,   0 zombie
Cpu(s): 57.1%us, 42.9%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    252280k total,    68532k used,   183748k free,        0k buffers
Swap:        0k total,        0k used,        0k free,    19688k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15402 root      20   0  2388 1108  880 R 31.2  0.4   0:02.25 top
 1748 root      20   0 54916  26m 2844 S 25.0 10.9  82:30.03 codesyscontrol.
 1513 root      20   0  8360 2452 1772 S 12.5  1.0  26:22.25 ledserverd
 1364 root      20   0  4424 2032 1500 S  6.2  0.8  14:31.67 syslog-ng
 1462 messageb -50   0  2376  896  684 S  6.2  0.4  13:05.70 dbus-daemon
 1510 root      20   0  6892 1556 1332 S  6.2  0.6  12:29.24 logforward
​
Normalerweise braucht top aber keine 31% und "idle" ist eher bei 50% (fast immer):Tasks:  79 total,   1 running,  78 sleeping,   0 stopped,   0 zombie
Cpu(s): 29.7%us, 25.3%sy,  0.0%ni, 44.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:    252280k total,    50952k used,   201328k free,        0k buffers
Swap:        0k total,        0k used,        0k free,    18764k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1751 root      20   0 38080  11m 2776 S 25.2  4.5  16:42.56 codesyscontrol.
 1516 root      20   0  8360 2452 1772 S 11.5  1.0   7:40.03 ledserverd
 1367 root      20   0  4240 1908 1500 S  6.2  0.8   4:03.88 syslog-ng
 1472 messageb -50   0  2376  892  684 S  5.9  0.4   3:55.92 dbus-daemon
 1513 root      20   0  6892 1556 1332 S  5.3  0.6   3:30.09 logforward

​
- Die Fehlermeldungen/Logeinträge kommen auch, ohne dass man eingeloggt ist und top Rechenzeit schluckt.

- Der LED-Server braucht 1 / 8 der Rechenzeit: Komisch, aber wohl wahr. Das Kernproblem mit der Überflutung des Log-Files wird davon vermutlich aber nicht berührt?

Im Ergebnis stellt es sich das Problem so dar:



Das Logging nimmt unterm Strich ca. 6% der Rechenzeit (ev. verschmerzbar) 
Es schreibt ungefähr 300kB pro Minute ins Flash: 400 MByte pro Tag, das macht das wear-out leveling bestimmt nicht 20 Jahre mit und die schöne SPS *ist für die Tonne*. 


Zur Ergänzung:

SPS firmware revision: 02.03.23(04) 
​

Entwicklungsumgebung: "CODESYS V3.5 SP8 +" 
​

Rohdaten in /var/log/wago/wagolog.log sehen so aus: 
Thu Apr 07 2016 12:24:04.368562 0x000D0002 codesys: R
Thu Apr 07 2016 12:24:04.388686 0x000D0002 codesys: R
Thu Apr 07 2016 12:24:04.408717 0x000D0002 codesys: R
Thu Apr 07 2016 12:24:04.431795 0x000D0002 codesys: R
Thu Apr 07 2016 12:24:04.450657 0x000D0002 codesys: R
Thu Apr 07 2016 12:24:04.469919 0x000D0002 codesys: R
​

Dank und Gruß,
CarpeDiem


----------



## HausSPSler (7 April 2016)

Hallo CarpeDiem,
danke für den Hinweis, das werden wir beheben!
Grüße


----------

