Entscheidung Beckhoff | Wago | Phoenix

Torpedo_Tommy

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

ich wollte hier mal eine kleine Diskussion anfachen zur Entscheidungsfindung.
Ich selbst komme aus der SPS- Programmierung im Maschinenbau.
Erfahrungen mit B&R und Siemens auf der SPS- Ebene. Visualisierungen habe ich bis dato entweder über das TIA- Portal erstellt oder völlig losgelöst in Delphi oder C#.

Um Gebäude zu automatisieren bin ich jetzt auf der Grundsatzsuche.
Ich will ein System wählen, das eine einzelne Büroeinheit bis zu einem kompletten Bürogebäude steuern kann. Mir ist klar, dass es von jedem Hersteller unterschiedliche Controller mit unterschiedlicher Leistung gibt.
Mir geht es um den Grundsatz welches System für die Gebäudeautomation am geeignetsten ist?!
Man will ja die Entwicklung effizienz und kostenorientiert gestalten. Jeder genannte Hersteller kann die Situation lösen.

Ich habe mir die drei Systeme mit der Programmierumgebung angeschaut und jeweils die ersten Tests gefahren.
Der Testaufbau am Arbeitsplatz ist ja etwas anderes als in der Realität draußen.
- Emalytics Workbench
- TwinCat 3
- E!Cockpit und Codesys V2.3


Die gewünschten Funktionen wie Abdecken von den unterschiedlichsten Feldbussystemen, API Anbindungen, Remote Zugriffe etc. sind von allen Herstellern gegeben.
Bei der Automation geht es um die Standards.
- Beleuchtung (Konventionell, Dali, RGBW- Leds)
- Verschattung (Rollläden, Jalousien, Behang)
- Heizung/ Klima (inkl. z.B. 2 Punkt Regelung, PID- Regelung)
- Web- Visualisierung

Wer hat mit den Systemen gute und schlechte Erfahrungen gemacht?!
Gibt es größere Stolpersteine beim Einsatz der jeweiligen Steuerungen?
 
Also wenn es um Gebäudetechnik geht, dann ist eine Kombination KNX und Wago sehr gut.
Basic-Funktionen mit KNX, der Rest mit Wago.
Vorteil von Wago ist, dass sie fast alle Schnittstellen in der Gebäudetechnik haben.
Bei anderen Herstellern braucht man oft irgendwelche Gateways, die es dann komplex machen.
 
Vielen Dank für die Beiträge.
An sich gebe ich euch bei der Konstellation soweit recht. Der Hintergedanke dabei war, dass wir die Programmierung nur auf einer Ebene haben.
Dabei könnten die KNX Tastsensoren etc. auch nur mit Gruppenadressen versorgt werden und die Logik erfolgt dann auf der Wago....
Wago ist wohl lizenztechnisch die einfachste Lösung der drei aufgeslisteten Anbieter....
 
Wenn du Wago verwendest, schau das du gleich mit Codesys V3 unterwegs bist.
Codesys V2.3 ist halt schon älter Funktioniert aber super und E!Cockpit ...naja ist halt ein bisschen langsam.
Also wenn ich das ganze richtig verstanden habe:
Codesys V3 -> E!Cockpit -> Aktuelle Programmierumgebung für aktuelle Steuerungen

Codesys V2.3 -> I/O Pro -> Ältere Steuerungen plus vereinzelte aktuelle Steuerungen (z.B. KNX Router)

Keine guten Erfahrungen mit dem E!Cockpit gemacht?
 
Ok wer googelt wird selber schlau....
Sorry hab das vorhin nicht ganz gecheckt mit CodeSys V3 zu E!Cockpit
CodeSys V3 funktioniert parallel zum E!Cockpit... Und dann verstehe ich auch die Empfehlung, dass gleich CodeSys verwendet werden sollte...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
E!Cockpit ist eine erweiterte Codesys IDE. Sehr langsam und mittlerweile bereits end-of-life.
Mit nativem Codesys bist du am breitesten aufgestellt. Viele Steuerungen können damit direkt mit der kostenlosen CS3 IDE genutzt werden. Für einzelne Steuerungen so z.B. auch für den Raspi Pi gibt es SL (single licence) packages aus dem Codesys Store. Für 50 Euro machst du so den Raspi zu einer performanten SPS. Vorausgesetzt dass du nicht auf Industriequalität angewiesen bist.

Ich verstehe dich so, dass du die Verknüpfungen in der SPS machen willst und nicht in der Feldebene. Dann ist KNX nicht die erste Wahl. Als IO-System genutzt, vervielfachen sich die Telegramme und damit die Reaktionszeit. Wo sonst ein Tasterereignis direkt bei zahlreichen Aktoren eine Aktion auslösen würde, muss zuerst ein Telegramm zur SPS und von da aus diverse Telegramme zu jedem betroffenen Aktor.
Google mal nach 'kopplernetz'! Das basiert auf Modbus. Nebst der viel besseren Reaktionszeit ist auch die Konfiguration viel einfacher. Adresse am DIP-Schalter des Sensor/Aktor-Moduls einstellen, dann dieselbe Adresse am FB einstellen und fertig ist's.
Ich bediene auf diese Weise in meinem Haus 50-60 Module an einem einzelnen Bus und bediene Taster und sämtliche Schaltausgänge alle 50ms.
 
Mit WAGO und "KNX nur als IO-Ebene" und die Logik in der SPS, könnte das auch noch relevant sein:

das WAGO KNX Modul 753-646 kann maximal 254 Gruppenadressen/Verknüpfungen. Gemäss Empfehlung von WAGO sollten max. zwei solcher Klemmen an einem Controller gesetzt werden.
Wenn man die Daten für Visualisierung vom KNX auch noch alle so über die SPS schlaufen muss/will, reicht dieser Flaschenhals evt. schnell mal nicht mehr. -> der WAGO Controller ist über KNX-TP eigentlich auf Aktor-/Sensor Ebene angebunden und nicht übergeordnet...
zudem gibt diese Lösung relative viel Arbeit, da im Controller jedes KNX Objekt/Gruppenadresse mit einem FB programmiert werden muss und dann auch noch alles im ETS zu verknüpfen ist. Die KNX SPS Objekte werden im eCockpit als Symboldatei ausgegeben welche im ETS importiert werden kann.
Zudem besitzen die KNX Sensoren/Aktoren heute so viele Funktionen und Objekte, was man in der SPS dann erst auch wieder nach- oder drumherum-bauen muss.

Besser also definitiv: Raumfunktionen usw. standardmässig in KNX lösen, Zentral- und Sonderfunktionen kann die SPS machen.
Für Tips und Ideen wie man hier die Visualisierung / Leitsystem einbindet wäre ich selber noch dankbar. Das müsste optimal wohl etwas sein was auch direkt KNX kann?


tja, älteres Thema, aber die Info schadet hier sicher nicht ;-)
 
Zurück
Oben