CODESYS Control for PFC200 SL

A

annD

Level-1
Beiträge
24
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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é
 
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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
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?
 
Hallo HausSPSler,

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

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Hallo CarpeDiem,

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

Anhänge

  • KBusKlemmen.jpg
    KBusKlemmen.jpg
    108,4 KB · Aufrufe: 84
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 :D

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
 
Zuletzt bearbeitet:
Hallo zusammen, Herr Schwellinger,

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

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:CS Task-Ueberwachung.jpg

"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
 
Zuletzt bearbeitet:

Similar threads

M
Wago PFC200 e!COCKPIT zu Codesys 3.5
Antworten
7
Aufrufe
2K
mf2000
M
M
Migration von e!COCKPIT-Projekten zu CODESYS V3.5
Antworten
2
Aufrufe
1K
Meip
M
N
PFC200 als Modbus TCP Slave in Codesys 3.5
Antworten
2
Aufrufe
951
Nilzon
N
L
CODESYS Control for PFC200 SL - Installationsproblem Runtime
Antworten
2
Aufrufe
4K
LTR88
L
T
Logo8 >>> Modbus TCP >>> Codesys (Control for Raspberry SL)
Antworten
9
Aufrufe
5K
Toru
T
Zurück
Oben