# Twincat 4024 Erfahrungen



## testor (31 Juli 2019)

Hallo,
gestern wurde die neue Twincat 3 Hauptversion 4024 veröffentlicht. Ich bin aus Erfahrung etwas vorsichtig mit der Installation. Hat von euch schon wer Erfahrung mit der 4024 gemacht? 
Läuft das ganze stabil? Wie sind die neuen Features?
Fg
Testor


----------



## DeltaMikeAir (31 Juli 2019)

> Hat von euch schon wer Erfahrung mit der 4024 gemacht?


Na wenn es gestern erst freigegeben wurde dürften die Erfahrungen noch spärlich sein



> Wie sind die neuen Features?


https://www.beckhoff.com/english.asp?twincat/new_features_twincat_3_1.htm?id=1905053020927774


----------



## testor (31 Juli 2019)

DeltaMikeAir schrieb:


> Na wenn es gestern erst freigegeben wurde dürften die Erfahrungen noch spärlich sein
> 
> 
> https://www.beckhoff.com/english.asp?twincat/new_features_twincat_3_1.htm?id=1905053020927774




Nur weil die Version gestern veröffentlicht wurde ist es denke ich trotzdem eine gerechtfertigte Frage um die Erfahrungen in einem Thread zu sammeln. Oder was spricht dagegen? Es handelt sich dabei ja um eine Hauptversion und die Erfahrung zeigt, das dieser Hauptversion noch einige Bugfix Versionen folgen werden. Da ist es denke ich ganz gut gesammelt Informationen hierzu zu sammeln. 
Dein Link beschreibt was es für neue Features gibt, beantwortet aber auch nicht meine Frage.


----------



## DeltaMikeAir (31 Juli 2019)

> Oder was spricht dagegen?


Habe ich was dagegen gesagt??



> Dein Link beschreibt was es für neue Features gibt



Entschuldige das ich 





> Wie sind die neuen Features?


 diesen Satz missverstanden habe.


----------



## wollvieh (31 Juli 2019)

Ohne die neuen Features zu kennen, ich hab's heute auf 2 Notebooks installiert, (32 Bit sowie 64Bit) , und auf nem  CX2020 mit W7, 32Bit die Runtime dazu installiert, läuft klaglos.
P.S.: auch Codesys3 hat ne neue Hauptversionsnummer, welch ein Zufall! ;-)


----------



## Guga (1 August 2019)

Wie die neuen Features sind: Eventuell gibt das Webinar heute Auskunft.


https://www.beckhoff.de/default.asp?support/webinars.htm

Do. 01.08.2019, 15:00 UhrTwinCAT 3.1 | Neue Eigenschaften in Build 4024


----------



## MasterOhh (1 August 2019)

Guga schrieb:


> Wie die neuen Features sind: Eventuell gibt das Webinar heute Auskunft.
> 
> 
> https://www.beckhoff.de/default.asp?support/webinars.htm
> ...


Dank für die Info! 


Multi-User und Varianten Management klingt auf jeden Fall sehr interessant!


----------



## wollvieh (1 August 2019)

Varianten Management... Vielleicht nur ein Workaround,  weil so Varianten die Runtime zum abschmieren gebracht haben?! Grübel... :-(


----------



## testor (1 August 2019)

wollvieh schrieb:


> Varianten Management... Vielleicht nur ein Workaround,  weil so Varianten die Runtime zum abschmieren gebracht haben?! Grübel... :-(



Ich denke um da genaueres Sagen zu können, muss man auf das spezifische Webinar zu dem Thema warten. Die Beispiele die im Webinar zu bedingten Kompilierungen gezeigt wurden waren jetzt noch nicht so aussagekräftig und man muss hoffen, dass diese dann auch für grafische Sprachen nutzbar sind. Es wurde ja auch gesagt, dass da ein Gesamtkonzept für alle Teile vorliegt. Ich bin gespannt.

Was ich leider vergessen habe zu fragen, auf welcher Codesys Hauptversion basiert das ganze jetzt? Die 4022 hatte sich ja schon etwas von der aktuellen Codesys Version unterschieden.


----------



## KGU (2 August 2019)

integriert in der 4024 ist 3.5 SP13. Wobei Multiuser und VariantenManagement nix ist, was von Codesys kommt.

zu der anderen Frage: Bedingte Compilierung ist komplett nur in ST verfügbar. Im Deklarationsteil aber auch in den grafischen Sprachen.


----------



## KGU (2 August 2019)

wollvieh schrieb:


> Varianten Management... Vielleicht nur ein Workaround,  weil so Varianten die Runtime zum abschmieren gebracht haben?! Grübel... :-(



Es gibt halt Kunden, die mehrere Varianten einer Maschine in einem Projekt haben wollen. Die einzelnen Varianten unterscheiden sich dann zum Beispiel in den Ausbaustufen der einzelnen Maschinenmodule oder in den Zusatzfunktionen etc. Jetzt möchte man aber für einen Maschinentyp ja nicht unbedingt für jede mögliche Variante ein eigenes Projekt aufziehen. Genau dafür ist Varianten-Management. Man hat die Möglichkeit Varianten zu definieren. Dann kann man für jedes Element im Baum einstellen, in welcher Variante es da ist bzw. welche Parameter in der jeweiligen Variante aktiv sind. In die SPS-Projekte kann man dann die Varianten als Compiler-Defines durchreichen, so dass man auch im SPS-Projekt das Kompilat für die jeweilige Variante spezifisch generieren kann.


----------



## testor (3 August 2019)

KGU schrieb:


> integriert in der 4024 ist 3.5 SP13. Wobei Multiuser und VariantenManagement nix ist, was von Codesys kommt.
> 
> zu der anderen Frage: Bedingte Compilierung ist komplett nur in ST verfügbar. Im Deklarationsteil aber auch in den grafischen Sprachen.



Erstmal Danke für die Antworten. Ich gehe mal davon aus, das du bei Beckhoff beschäftigt bist. Daher erlaube ich mir mal ein paar Nachfragen zu stellen.
Bzgl. der Codesys Version: Werden neue SP nur in neuen Hauptversionen veröffentlicht, also kann man mit einer neueren Codesys Version frühestens in 2 Jahren zu 4026 rechnen?

Ist es den angedacht bedingte Compilierung in Zukunft in die grafischen Sprachen zu integrieren? Hier würde ich den absoluten Mehrwert sehen. In ST ist es natürlich auch von Vorteil, allerdings hat man dort auch das IF-Else Konstrukt.
Bei grafischen Sprachen hat man nur die Möglichkeit mit Selects oder Sprüngen zu arbeiten. Hier würde eine bedingte Compilierung noch höheren Mehrwert bringen.


----------



## KGU (5 August 2019)

Ja, neue Codesys-Versionen kommen nur in der Hauptversionen rein.

Was die bedingte Compilierung angeht, so hat man in ST zwar das IF-Else-Konstrukt, das kann aber nicht das selbe: https://infosys.beckhoff.com/content/1031/tc3_plc_intro/36028799548759947.html?id=194355958058019771


----------



## drfunfrock (8 August 2019)

Ich habe alles neu installiert und kann nicht mehr eben mal die git-tools via NuGet installierenm weil NuGet fehlt. Ich versuchte dann die Package-Manage-Console. Die Packete wurden zwar gelistet, aber Git Tools waren nicht dabei. Seufz

Ja Git is eingebaut, aber die Git Tools sind besser. Ich habe die dann auf Festplatte heruntergeladen, aber die wurden nicht installiert beim Doppelklick


----------



## SPSSchlumpf (19 November 2019)

Hi,

ich habe mal wieder diverse Probleme mit Beckhoff. So kann ich z.B. kein Safety Projekt bearbeiten, wenn ich die Version auf 4022.30 zurückschalte und mit der integrierten VS2017 Version arbeite. mit 4024 geht es, das kann ich aber nicht verwenden weil die Runtime auf dem eingesetzten CP6606 nur in 4022 vorliegt. 
Integriere ich die 4024 in eine alte Installation die noch mit VS2013 Shell läuft, funktioniert es (alles in Vms). Durch das rumprobieren mit den Versionen, bedingter Compilierung usw. habe ich mir dann auch diverse Dateien im Projekt zerschossen, die dann wegen fehlende Objektreferenzen nicht mehr in TC geöffnet werden konnten. Die XML-Dateien an sich waren aber mit nem Editor normal ansehbar.
Strange waren auch einige Effekte in AS, wo Variablen laut Querverweisliste in Schritten angeblich geschrieben wurden, was aber unsinn war. Die Variablen wurden dort nicht verwendet. Schritt löschen und neuen Schritt einfügen behob dann das Problem.

Insgesamt (mal wieder) ca. 3 Tage mit Beckhoff selbst gekämpft, bei einem Projekt was eigentlich nur eine Woche dauern sollte.


----------



## testor (19 November 2019)

SPSSchlumpf schrieb:


> Hi,
> 
> ich habe mal wieder diverse Probleme mit Beckhoff. So kann ich z.B. kein Safety Projekt bearbeiten, wenn ich die Version auf 4022.30 zurÃ¼ckschalte und mit der integrierten VS2017 Version arbeite. mit 4024 geht es, das kann ich aber nicht verwenden weil die Runtime auf dem eingesetzten CP6606 nur in 4022 vorliegt.
> Integriere ich die 4024 in eine alte Installation die noch mit VS2013 Shell lÃ¤uft, funktioniert es (alles in Vms). Durch das rumprobieren mit den Versionen, bedingter Compilierung usw. habe ich mir dann auch diverse Dateien im Projekt zerschossen, die dann wegen fehlende Objektreferenzen nicht mehr in TC geÃ¶ffnet werden konnten. Die XML-Dateien an sich waren aber mit nem Editor normal ansehbar.
> ...



Mir sind auch einige (unfassbare) Sachen aufgefallen, zu viel um es alles aufzulisten. Mit der Querverweisliste habe ich aber auch Probleme. Bei mir ist die Querverweisliste nicht vollständig bzw. Zeigt zwischendurch nicht mehr alle Variablen an. Ich wäre glaube ich besser bei der 4022.30 geblieben.


----------



## DeltaMikeAir (19 November 2019)

> Mir sind auch einige (unfassbare) Sachen aufgefallen, zu viel um es alles aufzulisten.



Kannst du mal die Top 10 auflisten?


----------



## testor (19 November 2019)

Ein paar Beispiel:​

Fortschreitender    Verlust der Querverweisliste.
Arbeiten    mit dem FUP-Editor kaum möglich, da nach einiger Zeit kein Einfügen    mehr möglich ist und Variablennamen beschnitten werden.
Fehlende/Vergessene    Refactoring Optionen in der neuen TC-Custom XAE-Shell
Fehlerhafte    Parameterübergabe ans Codesys Modul mit entsprechenden Abstürzen
Darstellungsfehler    bei gesetzten Breakpoints in Vererbungsstufen, inklusive falsch dargestellten Sprünge
Verlust    von Verknüpfungen nach erneutem Compilieren.
Darstellung    alter Code-Versionen im Onlinemodus bei Nutzung des Multiviews.
Formatfehler    innerhalb des Projekts, welche zu andauernden Warnungsmeldungen    führen.



Das sind einige der Punkte, die ich mit der neuen Version verbinde. Die Version habe ich dabei noch gar nicht so lange in Benutzung. Alte Probleme,Einfrieren, Abstürze etc. waren schon vorher da. Teilweise treten Fehler auf, die in Zwischenversionen gefixt waren/zumindest nicht mehr aufgetreten sind,  nun wieder auf.​


----------



## MasterOhh (20 November 2019)

Mir sind noch keine großen Probleme mit der TC3 4024 aufgefallen, aber ich habe da auch noch nicht so sehr drauf geachtet. Ich benutze VS2015 Professionell anstatt der Shell, vielleicht macht da schon einen Unterschied. 

Hast du die Bugs bei Beckhoff gemeldet?


----------



## SPSSchlumpf (20 November 2019)

Nun schmiert bei mir immer das Visual Studio ab, wenn ich in einem AS (SFC) Baustein eine Tansition anklicke. D.h. ich kann den Baustein nicht mehr ändern, ohne dass das Programm abstürzt. Bei der Visualisierung hatte ich gerade den Fall, dass sich keine Werte mehr in die Eingabefelder eingeben liessen.
Beckhoff macht mich echt fertig. Letztes Projekt mit dem Schrott, wenn es sich irgendwie vermeiden lässt. Ich habs echt satt.


----------



## Chräshe (20 November 2019)

testor schrieb:


> Fortschreitender    Verlust der Querverweisliste.
> Arbeiten    mit dem FUP-Editor kaum möglich, da nach einiger Zeit kein Einfügen    mehr möglich ist und Variablennamen beschnitten werden.
> Fehlende/Vergessene    Refactoring Optionen in der neuen TC-Custom XAE-Shell
> Fehlerhafte    Parameterübergabe ans Codesys Modul mit entsprechenden Abstürzen
> ...





SPSSchlumpf schrieb:


> Nun schmiert bei mir immer das Visual Studio  ab, wenn ich in einem AS (SFC) Baustein eine Tansition anklicke. D.h.  ich kann den Baustein nicht mehr ändern, ohne dass das Programm  abstürzt. Bei der Visualisierung hatte ich gerade den Fall, dass sich  keine Werte mehr in die Eingabefelder eingeben liessen.
> Beckhoff macht mich echt fertig. Letztes Projekt mit dem Schrott, wenn  es sich irgendwie vermeiden lässt. Ich habs echt satt.



 Ihr habt sowohl auf der Steuerung als auch auf dem Programmiergerät die Version TC3 4024?
  Probleme kenne ich, wenn eine „alte“ Steuerung nachträglich mit neuem TwinCat erweitert wird. 

Aber bei TC3 bin ich nicht mehr auf dem neusten Stand. 
Sofern hier niemand einen guten Tipp hat, solltet ihr euch an den Beckhoff-Support wenden…


----------



## testor (20 November 2019)

SPSSchlumpf schrieb:


> Nun schmiert bei mir immer das Visual Studio ab, wenn ich in einem AS (SFC) Baustein eine Tansition anklicke. D.h. ich kann den Baustein nicht mehr ändern, ohne dass das Programm abstürzt. Bei der Visualisierung hatte ich gerade den Fall, dass sich keine Werte mehr in die Eingabefelder eingeben liessen.
> Beckhoff macht mich echt fertig. Letztes Projekt mit dem Schrott, wenn es sich irgendwie vermeiden lässt. Ich habs echt satt.




Das Problem tritt bei mir so nicht auf. In welcher Sprache ist die Transition den geschrieben? Die könntest mal versuchen das Projekt als PLCopenXML zu exportieren und dann wieder einzufügen. Das hat bei mir bei Problemen mit den Graphischen Spracgen ab und an für Besserung gesorgt. Ich denke mal das bei neuen TC Versionen die internen Datenformate geändert werden und die Konvertierung evtl. nicht immer ganz klappt. Durch den Export/Import über das neutrale Plcopenxml Format wird beim Import meiner Theorie nach die richtige Formatierung erzwungen. Ist nur eine Theorie, aber vielleicht hilft es.


----------



## SPSSchlumpf (20 November 2019)

Hallo testor,

ja, das hat geholfen. Ich hatte auch vermutet, dass da irgendwas mit den Ids durcheinander war. Beim Export wird das alles weggelassen und beim Import neu erstellt.

@Chräshe: Ich habe auf dem CP die 4022.29. Eine andere Version habe ich nicht bekommen. Aus einem älteren Projekt hatte ich noch ein 4020 Image, dass aber auch nicht funktionierte. Vermutlich hat sich seit dem die Hardware geändert?. Es ist auf jeden immer ein elendes Gebastel. 
Das mit der Visu kam vermutlich auch durch das "Versionsdurcheinander".

Ich habe erst mit der Version 4020.22 gearbeitet, weil die im alten Projekt einigermassen lief. Dann habe ich die 4024 runtergeladen und die Versionsumschaltung auf 4022. Da ich damit aber Probleme hatte, habe ich dann über die 4020.22 Version die 4022.30 drüberinstalliert. Damit funktionierte immerhin Twinsafe, was aber nun auch egal ist, da wir dort wieder normale Not-Aus Relais einbauen.


----------



## StructuredTrash (23 November 2019)

Ich gehöre auch zu denen, die den Umstieg bereuen. Dabei hadere ich vor allem mit der PLC HMI. Beim offline arbeiten an Visuseiten mit vielen Objekten wird das VS immer langsamer, um irgendwann abzustürzen. Wenn ich Texte in Objekten ändere und dabei mit Maus und Tastatur etwas schneller unterwegs bin als das VS, neigt es auch zum Absturz. Wenn ich einen Fehler in einem Visu-Objekt behoben habe, muss ich es manchmal speichern und auch das Fenster schliessen, um den Fehler beim nächsten Übersetzen weg zu kriegen. Alles Dinge, die ich aus früheren Builds kenne, die aber mit 4020/22 überwunden schienen.
Und dazu noch einige neue Features. Wenn ich mit dem Fangraster arbeite und ein Objekt mit der rechten/unteren Kante grösser ziehe, wird die rechte untere Ecke nun genau auf einen Rasterpunkt gezogen. Wenn ich z. B. ein Objekt auf eine Grösse von 100 x 100 Pixel ziehen will, wird es 101 x 101 gross. Wer denkt sich so einen Blödsinn aus?
Ausserdem wurde die Online-Anzeigegeschwindigkeit der Visu in der Entwicklungsumgebung an die Offline-Geschwindigkeit angepasst. Ist jetzt auch quälend langsam. Und wenn ich online eine Visu-Seite offen habe und dann ein beliebiges Fenster auf meinen zweiten Bildschirm ziehen will, friert das VS ein.
Wenn neue Funktionen noch nicht richtig rund laufen würden, könnte ich das noch verstehen. Aber was Beckhoff hier abgeliefert hat, ist einfach nur enttäuschend.


----------



## mkd (27 November 2019)

Unserer Erfahrung nach hat Beckhoff überhaupt kein Interesse Fehler zu beheben.
Insbesondere bei Codesys Komponenten (KOP/FUP/PLC HMI) ignoriert man Anfragen.
Wir haben das Thema seit Jahren und sind etliche verschiedene Wege der Kontaktaufnahme gegangen.
U.a. über den Support vom Stammhaus, den regionalen Support, den Vertrieb, den Produktverantwortlichen aus dem Stammhaus...
Wenn es richtig knallt und ein Arbeiten überhaupt nicht möglich ist, haben wir über den Vertrieb eine Lösung erhalten.

Beim Support heißt es oft, das wir die einzigen mit diesen Fehlern sind.
Auch bei Installation von weiteren Visual Studio Plugins gibt es (immer nur bei Beckhoff Produkten) andauernd Probleme wie Abstürze etc.

Was uns am meisten stört:
- Die seit Jahren stiefmütterliche KOP/FUP/PLC HMI Integration mit Fehlern die von Version zu Version auftauchen, wieder beseitigt werden und Fehler/Abstürze die unberücksichtigt bleiben
- Mangelnde Transparenz bei neuen Versionen (Change Log etc.).

Letzterer Punkt stößt, auch bei direkt Verantwortlichen, auf Granit. Es ist unserer Meinung nach nicht gewollt das der Kunde weiß welche Fehler behoben wurden.

Eigentlich schade...zumal schon mehr als 10 Jahre Beckhoff Kontakt


----------



## mkd (27 November 2019)

StructuredTrash schrieb:


> ...Dabei hadere ich vor allem mit der PLC HMI...



Hier können wir Versionsübergreifend alte Projekte teilweise gar nicht mehr öffnen/bearbeiten und haben ganze Visualisierungen neu erstellen müssen.
Selbst Beckhoff Download Beispiele sind nicht lauffähig.

Wenn man nicht auf eine neue Version updatet hat man ein Support Problem, da man bei Problemen gebeten wird erstmal die neue Version zu nutzen.

Zudem ist es funktional teilweise unerlässlich, da mit der aktuellen Version die Safety endlich sinnvoll zu nutzen ist (Stichwort Mehrfachverwendung Eingänge sowie globale Variablen).

:sw3::sw13:

:sm11:


----------



## SPSSchlumpf (27 November 2019)

mkd schrieb:


> Unserer Erfahrung nach hat Beckhoff überhaupt kein Interesse Fehler zu beheben.



Was vermutlich daran liegt, dass man die Ware noch von Vertriebler zu Vertriebler verkauft bekommt, und der der mit den fehlerhaften Sachen dann arbeiten muss als zu doof hingestellt wird. Die müssen sich ja nicht damit rumschlagen
Bei meinem Projekt habe ich das Glück mit dem Kunden schon unzählige Projekte mit anderen Steuerungen umgesetzt zu haben. Sonst hätte ich ein echtes Problem die Fehler und die sich dadurch verlängernde Projektzeit zu erklären. Und der Kunde weiss, dass ich ihm da keinen Unsinn erzähle.


----------



## oliver.tonn (27 November 2019)

mkd schrieb:


> Unserer Erfahrung nach hat Beckhoff überhaupt kein Interesse Fehler zu beheben.
> Insbesondere bei Codesys Komponenten (KOP/FUP/PLC HMI) ignoriert man Anfragen.


Die Frage ist, ob Beckhoff da überhaupt etwas machen kann. Nicht alles was von 3S kommt ist anpassbar und nur dann kann Beckhoff selber aktiv werden.
Ich habe mehrere Jahre für ABB, die auch Codesys einsetzen, in der SPS-Entwicklung gearbeitet und dabei so manchen Fehler im 3S Teil gefunden und an 3S gemeldet. Da im Bugtracker von ABB meine eigene Mailadresse stand und das nicht änderbar war erhielt ich auch nachdem ich bei ABB aufgehört hatte noch Nachrichten, wenn sich etwas an den von mir gemeldeten Fehlern getan hat.
Ich erhielt solche Nachrichten noch viele Monate nach meinem Weggang.


----------



## mkd (27 November 2019)

Das mag sein, allerdings kann man dann auch offener damit umgehen.
Man erfährt in der Richtung nichts. Weder ob ein Fehler bekannt ist, noch ob er abgestellt wurde.
Mir ist auch klar, das vieles an 3S liegen wird.

Wir Anwender müssen leider täglich damit leben und es passiert einfach nichts.
 Über Siemens haben so viele geschimpft, m.M.n. hat es der Verein aber mittlerweile geschafft sich positiv abzugrenzen.
Gerade was Usability und Stabilität angeht überrennt das TIA Portal den 3S / Beckhoff Kram mittlerweile um längen.


----------



## testor (28 November 2019)

mkd schrieb:


> Unserer Erfahrung nach hat Beckhoff überhaupt kein Interesse Fehler zu beheben.
> Insbesondere bei Codesys Komponenten (KOP/FUP/PLC HMI) ignoriert man Anfragen.
> Wir haben das Thema seit Jahren und sind etliche verschiedene Wege der Kontaktaufnahme gegangen.
> U.a. über den Support vom Stammhaus, den regionalen Support, den Vertrieb, den Produktverantwortlichen aus dem Stammhaus...
> ...



Mit dem Beitrag sprichst du mir echt aus der Seele. Das Verhalten bei auftretenden Fehlern ist wirklich fragwürdig. Bevor auf ein Problem geantwortet  wird braucht es am besten erstmal ein 10-seitiges Dossier das den Fehler bis ins letzte Detail beschreibt plus Dump und Programm.
Ich finde es,  auch wenn es traurig ist, gut das hier nun auch ein paar negative Erfahrungen hochkommen.  Den auch uns erzählt man das wir die einzigen sind die Probleme haben oder verweist auf eine bekanntes Forum und Berichte über andere Hersteller.
Die Ausrede mit dem Codesys ist auch immer ein Highlight, das man so nicht akzeptieren kann.
 Schön wäre es wenn Beckhoff eine Liste von "Known-Problems" rausgeben würde, damit man weiß woran man ist. Ich habe mal gehört das andere Hersteller das durchaus machen.


----------



## oliver.tonn (28 November 2019)

Hallo Testor,
zunächst eins vorweg, außer das ich Programme für TwinCAT erstelle und ein paar Beckhoff Produkte besitze besteht keine engere Verbindung von mir zu Beckhoff und ich habe keine Vorteile durch diesen Post.


testor schrieb:


> Die Ausrede mit dem Codesys ist auch immer ein Highlight, das man so nicht akzeptieren kann.


Hast Du schon mal in der SPS-Entwicklung eines Herstellers von Codesys basierten Systemen gearbeitet und kennst die Zusammenhänge oder kennst einen, der Dir darüber berichtet hat? Falls Du beides mit nein beantworten musst solltest Du Dich mit solchen Kommentaren zurückhalten. Ich habe in diesem Bereich schon bei der ABB über mehrere Jahre gearbeitet und weiß, dass man, zumindest bei V2,  bei vielen Fehlern selber nichts machen kann und eine Behebung durch 3S dauern kann (s. #28 ). Die meisten Fehler die ich bei meinen Tests (War Softwaretester bei ABB) gefunden hatte waren Fehler in Codesys.


testor schrieb:


> Ich finde es,  auch wenn es traurig ist, gut das hier nun auch ein paar negative Erfahrungen hochkommen.


Wieso traurig, jedes System hat seine Macken und reine Lobhudelei hilft keinem weiter, auch TwinCAT hat diverse Unschönheiten, TIA aber auch.


testor schrieb:


> Den auch uns erzählt man das wir die einzigen sind die Probleme haben oder verweist auf eine bekanntes Forum und Berichte über andere Hersteller.


Das ist nicht in Ordnung, allerdings geht es auch anders. Bei einem Kunden stürzte regelmäßig die Steuerung mit Bluescreen ab. Ursache war ein Fehler in einer (Beckhoff) DLL so das es unter bestimmten Bedingungen zu Abstürzen kam (s. hier). Zugegeben, auch wir waren der erste mit dem Problem, aber nach Einsendung eines Beispielprojektes und einiger Dumps wurde uns gut geholfen.


testor schrieb:


> Bevor auf ein Problem geantwortet  wird braucht es am besten erstmal ein 10-seitiges Dossier das den Fehler bis ins letzte Detail beschreibt plus Dump und Programm.


Das ist aber bei anderen Herstellern auch so und wenn ich Fehler an 3S gemeldet hatte musste ich auch ein Beispielprojekt und eine möglichst ausführliche Beschreibung (OK, eine Seite hat meist gereicht) mit schicken.


testor schrieb:


> Schön wäre es wenn Beckhoff eine Liste von "Known-Problems" rausgeben würde, damit man weiß woran man ist. Ich habe mal gehört das andere Hersteller das durchaus machen.


Da stimme ich Dir zu, aber das machen wohl die wenigsten Hersteller wirklich. Ich habe mal eben bei Tante Google so die üblichen Verdächtigen abgeklappert und nichts gefunden.


----------



## testor (28 November 2019)

oliver.tonn schrieb:


> Hallo Testor,
> zunächst eins vorweg, außer das ich Programme für TwinCAT erstelle und ein paar Beckhoff Produkte besitze besteht keine engere Verbindung von mir zu Beckhoff und ich habe keine Vorteile durch diesen Post.
> 
> Hast Du schon mal in der SPS-Entwicklung eines Herstellers von Codesys basierten Systemen gearbeitet und kennst die Zusammenhänge oder kennst einen, der Dir darüber berichtet hat? Falls Du beides mit nein beantworten musst solltest Du Dich mit solchen Kommentaren zurückhalten. Ich habe in diesem Bereich schon bei der ABB über mehrere Jahre gearbeitet und weiß, dass man, zumindest bei V2,  bei vielen Fehlern selber nichts machen kann und eine Behebung durch 3S dauern kann (s. #28 ). Die meisten Fehler die ich bei meinen Tests (War Softwaretester bei ABB) gefunden hatte waren Fehler in Codesys.


Hallo Oliver,
Bzgl. der Codesys-Problematik. Ich habe ebend nicht mit Codesys gearbeitet, wie du es getan hast und deswegen haben wir da ein unterschiedliches Verständnis. Mir ist es nämlich egal welche Probleme im Hintergrund dazuführen, dass es Probleme gibt. Mein Ansprechpartner ist ja nicht 3s. Mir ist es auch egal ob Beckhoff nun 3s, logi.cals oder eine eigene Programmierumgebung nutzt. Wenn das Argument für Probleme die Software von 3s ist, dann hat man das Problem ja identifiziert und kann es wie auch immer abstellen. Da kommt dann auch die Bemerkung von mir zu tragen, dass man das Gefühl bekommen kann Beckhoff ist gar nicht wirklich gewillt zu helfen. Meist kommt nach einem mehr oder weniger praxisnahen Workaround nichts mehr.
Nun ist es ja so, dass die Codesys Version in TC3 nicht der aktuellen Version von 3s entspricht. Das kann halt auch dazu führen, dass bugs die lange behoben sind noch immer im Twincat auftreten.
Ich finde es gut, dass dir als Softwaretester noch viele Probleme aufgefallen sind, aber du warst dafür zuständig, wir Anwender nicht. Es ist halt sehr ungünstig, dass die Sachen bei uns ankommen und in neueren Versionen anscheinend auch schlimmer werden. 
Warum ich die Antwort nicht akzeptieren kann ist, weil das Argument eig immer vorgeschoben wird, am Ende aber nicht immer zutreffend ist. Ich kann deine Sichtweise natürlich verstehen.


oliver.tonn schrieb:


> Wieso traurig, jedes System hat seine Macken und reine Lobhudelei hilft keinem weiter, auch TwinCAT hat diverse Unschönheiten, TIA aber auch.


Traurig, weil wir jetzt damit leben müssen



oliver.tonn schrieb:


> Das ist aber bei anderen Herstellern auch so und wenn ich Fehler an 3S gemeldet hatte musste ich auch ein Beispielprojekt und eine möglichst ausführliche Beschreibung (OK, eine Seite hat meist gereicht) mit schicken.


Ja, aber das ganze als Bedingung zu machen, sich dem Thema anzunehmen finde ich nicht ok. Insbesondere wenn dann heraus kommt, dass es sich um ein bekanntes Problem handelt.
Wobei wir mit der Argumentation, das ist bei anderen Herstellern auch so nicht weiterkommen. Wo ist da der Drang nach Verbesserung? 



oliver.tonn schrieb:


> Da stimme ich Dir zu, aber das machen wohl die wenigsten Hersteller wirklich. Ich habe mal eben bei Tante Google so die üblichen Verdächtigen abgeklappert und nichts gefunden


Ich habe eine solche Liste mal über Google gefunden (auf Basis Codesys v2 und von einem Hersteller der mir nichts sagte). Ich würde es natürlich auch nicht öffentlich machen, sondern den Kunden inkl. Change-Logs zur Verfügung stellen.


----------



## Kabeläffle (28 November 2019)

testor schrieb:


> Schön wäre es wenn Beckhoff eine Liste von "Known-Problems" rausgeben würde, damit man weiß woran man ist. Ich habe mal gehört das andere Hersteller das durchaus machen.


 Das fände ich auch super. Am besten noch mit einer Umfrage, dass die Kunden über die Priorität abstimmen können… 

  Aber Welche „anderen Hersteller“ haben solch eine öffentliche Liste mit "Known-Problems"?


----------



## testor (28 November 2019)

Kabeläffle schrieb:


> Das fände ich auch super. Am besten noch mit einer Umfrage, dass die Kunden über die Priorität abstimmen können…
> 
> Aber Welche „anderen Hersteller“ haben solch eine öffentliche Liste mit "Known-Problems"?



https://www.com-tom.de/download/firmware/known-bugs/com.tom_CODESYS_known-bugs_v7.11.2.pdf

Wie gesagt, öffentlich muss es nicht sein.


----------



## mkd (28 November 2019)

Laut Beckhoff Mitarbeitern ist ein Change Log nicht gewollt.
Auch direkte Nachfrage beim Produktverantwortlichen Dr. bestätigt dieses Vorgehen.

Abgesehen verstehe ich nicht warum das Thema Usability stiefmütterlich behandelt wird.

Aber in Nürnberg schmücken sich ja jetzt wieder alle mit Ihren tollen Produkten )))


----------



## Swyss (28 November 2019)

mkd schrieb:


> Unserer Erfahrung nach hat Beckhoff überhaupt kein Interesse Fehler zu beheben.
> Insbesondere bei Codesys Komponenten (KOP/FUP/PLC HMI) ignoriert man Anfragen.
> Wir haben das Thema seit Jahren und sind etliche verschiedene Wege der Kontaktaufnahme gegangen.
> U.a. über den Support vom Stammhaus, den regionalen Support, den Vertrieb, den Produktverantwortlichen aus dem Stammhaus...
> ...




Wir hatten grad konkret einen Fehler bei der neuen Twincat Version beim Zugriff mit Passwort aber ohne Zertifikat auf eine OPCUA Datenquelle auf einer Wago SPS aus dem Twinscope. Nach knapp einer Stunde nach der Fehlermeldung hat sich schon der zuständige Supportingenieur gemeldet und sich das per Fernwartung angeschaut. Wenige Stunden später kam aus der Beckhoff Entwicklung bereits eine neue .dll
Da mal ein dickes Lob für diese schnelle Reaktion.


----------



## mkd (29 November 2019)

Da muss ich einwerfen dass die Jungs im Support an sich super und immer bemüht sind.
Das habe ich wohl falsch transportiert.
Es geht eher um die Politik die bei Systemproblemen gefahren wird.


----------



## Swyss (29 November 2019)

mkd schrieb:


> Da muss ich einwerfen dass die Jungs im Support an sich super und immer bemüht sind.
> Das habe ich wohl falsch transportiert.
> Es geht eher um die Politik die bei Systemproblemen gefahren wird.



Nun ja die Politik ist generell ein Übel auf unserem Planeten.
Wobei ich da dem Beckhoff Hansi und seiner hübschen Tochter doch einiges mehr vertraue als den auf reine Renditemaximierung getrimmten CEO Kapitalknechten der meisten Mitbewerber.
Besonders freut mich das er lernfähig ist und meine Anregung von ca. 2012 nun beherzigt hat und eine FreeBSD version der Runtime anbietet.
Und dazu noch meine Anregung eine SPS mit AMD Ryzen Embedded von 2018   ;P 
(Damals hies es in beiden Fällen noch nur Microsoft und Intel)
Da mal ein ganz dickes Lob!

Sonnige Grüsse


----------



## StructuredTrash (1 Dezember 2019)

Sehr schön. Ändert aber nichts daran, dass man sich mit Build 4024 in etwa auf den Zuverlässigkeitsstand von 4016 zurückkatapultiert fühlt. Wenn ich jetzt mal hochrechne, wird man erst mit Build 4030 wieder vernünftig arbeiten können. Dann habe ich schon meine Rente in greifbarer Nähe.


----------



## testor (1 Dezember 2019)

Swyss schrieb:


> Nun ja die Politik ist generell ein Übel auf unserem Planeten.
> Wobei ich da dem Beckhoff Hansi und seiner hübschen Tochter doch einiges mehr vertraue als den auf reine Renditemaximierung getrimmten CEO Kapitalknechten der meisten Mitbewerber.
> Besonders freut mich das er lernfähig ist und meine Anregung von ca. 2012 nun beherzigt hat und eine FreeBSD version der Runtime anbietet.
> Und dazu noch meine Anregung eine SPS mit AMD Ryzen Embedded von 2018   ;P
> ...



Hmm, du scheinst ja einen guten Draht zum "Hansi" zu haben. Vielleicht kannst du ihm ja mal wissen lassen, was es im Moment für grundlegende Probleme an der "Front" gibt. Vielleicht ist das bis zu ihm ja noch gar nicht durchgedrungen 
Ich sehe eigentlich kaum ein Grund warum die Firma Beckhoff gegenüber den Kunden andere Ziele verfolgen sollte als "die getrimmten CEO Kapitalknechte". 
Deine Beispiele hinken etwas. Mir wurde auf der Messe erzählt, dass man das FreeBSD auf den Markt gebracht hat, weil man die Entwicklung von Win10 mit Sorge betrachtet (Update-Politik etc.). Hier wird man jetzt also gezwungener Maßen aktiv.

@StructuredTrash: ich hoffe du ziehst bei deiner Rechnung in Betracht, dass die Hauptversionen voraussichtlich nicht mehr jedes Jahr sondern nur noch alle zwei Jahre veröffentlicht werden.


----------



## StructuredTrash (1 Dezember 2019)

testor schrieb:


> @StructuredTrash: ich hoffe du ziehst bei deiner Rechnung in Betracht, dass die Hauptversionen voraussichtlich nicht mehr jedes Jahr sondern nur noch alle zwei Jahre veröffentlicht werden.


Das habe ich berücksichtigt. Der 2-Jahres-Rythmus ist auch in Ordnung. Allerdings sollte man dem Ergebnis die längere Reifezeit auch anmerken können.


----------



## testor (1 Dezember 2019)

StructuredTrash schrieb:


> Das habe ich berücksichtigt. Der 2-Jahres-Rythmus ist auch in Ordnung. Allerdings sollte man dem Ergebnis die längere Reifezeit auch anmerken können.


Generell sehe ich das auch so. Was mir nur sorge macht ist, dass es möglicherweise dazu führt das die Lücke zwischen TC und den Codesys Hauptversionen entsprechend größer wird. Dann müsste man auf gewisse Bugfixes und "new features" noch länger warten.


----------



## KGU (1 Dezember 2019)

testor schrieb:


> Generell sehe ich das auch so. Was mir nur sorge macht ist, dass es möglicherweise dazu führt das die Lücke zwischen TC und den Codesys Hauptversionen entsprechend größer wird. Dann müsste man auf gewisse Bugfixes und "new features" noch länger warten.



auch 3S vergrößert den Abstand für neue Versionen. Es wird nur noch eine Version pro Jahr geben. Außerdem wurden kritische Bugfixes (wenn es möglich war) auch schon vorgezogen und in die jeweils aktuelle TwinCAT Version gezogen. Nur bei neuen Funktionen geht das nicht.


----------



## seehma (3 Dezember 2019)

Um ein wenig österreichischen Senf dazu geben zu können: Wir haben jetzt ca. 4 Jahre gekämpft um näher an Beckhoff D. zu kommen, mittlerweile stimmt auch die Abnahme an TC3 Lizenzen und jetzt funktionierts einigermaßen. Der Kontakt läuft immer über die ö. Kollegen, direkt ist nicht gewünscht. Hier muss ich sagen das geht auch anders bei anderen Herstellern!
Der Support bei TC3 Fehlern (egal ob Entwicklungsumgebung oder Runtime) war aufgrund des indirekten Supports durch die Entwickler in D recht langwierig und schwierig. Man muss dazusagen, einige Probleme waren bei uns auch hausgemacht, wir kommen eher von der Linux & C-Welt und die Codesys (ST) Umgebung hat hier einfach ein paar Unterschiede die man beachten muss 
(was wir nicht gemacht haben).

Wir sind seit 4009 bei TC3.1 dabei und ich sag euch da gabs einiges was man so nicht versteht, vor allem was hier als Produkt verstanden wurde. 
Mittlerweile haben wir intern einen Workflow der durchlaufen wird, um von einer Version auf die nächste zu wechseln und seit dem funktioniert es ganz gut. Es werden einfach gewisse Standardfälle getestet und auch vorher mindestens ein paar Wochen mit der neuen Version entwickelt bevor gewechselt wird.

Unsere derzeitige Hauptversion ist die 4022.29 die funktioniert bis auf ein paar kleine Macken (wenn man sie kennt nicht ganz schlimm sind) eigentlich ganz gut.

Den Schritt mit BSD verstehe ich überhaupt nicht, zumal ja noch eine dritte Baustelle mit FreeRTOS aufgemacht wurde. Einige andere Hersteller gehen auf Standard Linux mit Preempt-RT Patch. Ich denke das mit BSD hat bei Beckhoff eher mit der Lizenzierung (BSD Lizenz zu GPL) zu tun (ist aber nur eine Vermutung).


----------



## KGU (3 Dezember 2019)

seehma schrieb:


> Den Schritt mit BSD verstehe ich überhaupt nicht, zumal ja noch eine dritte Baustelle mit FreeRTOS aufgemacht wurde. Einige andere Hersteller gehen auf Standard Linux mit Preempt-RT Patch. Ich denke das mit BSD hat bei Beckhoff eher mit der Lizenzierung (BSD Lizenz zu GPL) zu tun (ist aber nur eine Vermutung).



Ich verstehe nicht, das es die anderen Hersteller das nicht tun. Wenn man harte Echtzeit erreichen will, dann braucht man den Kernel-Mode von Linux für den direkten Hardwarezugriff. Und wenn man den nutzt, dann muss man die Source dafür unter GPL veröffentlichen und das schließt die Kundenapplikation mit ein. Eine andere Möglichkeit wäre ein Hypervisor der sauber trennt, aber das ist sehr aufwenidg und es gehen ein paar andere Möglichkeiten verloren. Das Problem mit der GPL-Lizenz wird von den anderen Herstellern einfach auf die Maschinenbauer abgewältzt die die Maschine ausliefern. Ich habe auch schön gehört, das einige Hersteller meinten den Kernel-Mode braucht man nicht, aber diese brauchen dann wahrscheinlich auch keine deterministische Echtzeit. Und ehrlich gesagt finde ich diese Vorgehen unschön. Das ist Augenwischerei dem Kunden gegenüber.

Betreffend diesen Kommentars: "Der Kontakt läuft immer über die ö. Kollegen, direkt ist nicht gewünscht." Wer bei Beckhoff auf die Messen kommt, der sieht das dort nicht nur Produktmanager und Vertriebler stehen, sonder immer auch die Entwickler. Das ist auch so gewollt. Was das Tagesgeschäft angeht, so sollen die Kollgen vor Ort helfen die nah am Kunden sind. Das nützt überhaupt nix, wenn die Mitarbeiter im Stammhaus das Know-How haben, aber die Kollegen die in 2h beim Kunden vor Ort sein können wenn Probleme auftreten, die sind nicht involviert. Bei Beckhoff besteht aus gutem Grund die Vertriebsmanschaft aus Ingenieuren die mit dem Kunden sinnvoll diskutieren sollen und nicht aus Wirtschaftswissenschaftlern die nur das Geld im Auge haben. Beckhoff will kein Einmalgeschäft, sondern eine Partnerschaft bei der beide seiten profetieren. Das Konzept ist gut auch wenn es manchmal noch hackt. Es wurden aber bereits verschiedene Maßnahmen getroffen um das deutlich zu verbessern.


----------



## seehma (3 Dezember 2019)

Danke für den Beitrag. Ist eh eine gute Diskussion, die kann man selbst auf der Messe selten führen, da hier natürlich die geschulten Aussagen kommen (da kann man auch niemanden bös sein).
Laut Jan Altenberg (Linutronix) ist Preempt-RT aber sehr wohl für Echtzeit Verhalten ausgelegt, auch wenns nur im User-Space läuft. Einen hab ich mal gesehen, wo er den "Single Kernel approach" also mit dem Patch vergleicht mit Xenomai und RTAI und da gibt es keinen großen Unterschied mehr zu den "Dual Kernel"-Lösungen (siehe hier). Hier gilt, je besser ich mein System (HW, Treiber, Core-Isolation) kenne, umso besser läuft das ganze dann auch.

Ich hab mich vielleicht durch das lange Lesen dieses Threads etwas zum bashen hinleiten lassen und das wollte ich so eigentlich auch nicht, Sorry for that. Ich muss gleich nochmal sagen, dass in letzter Zeit die Zusammenarbeit besser geworden ist und natürlich die Versionen wesentlich stabiler sind. Am Anfang war TC3 sicher für Beckhoff auch ganz nett ein Rucksack zum Stemmen: Windows7 64Bit, Windows10 64Bit, UEFI, Treiber Signierung, Hyperthreading, hin und her taktende CPUs, Treibereinflüsse von Grafikkarte, Objekt orientiertes Programmieren, C++, Matlab, ...

Windows ändert sich im Allgemeinen halt immer mehr Richtung Consumer und weg für den typischen Einsatzzweck von Steuerungen und ich glaube auch dass dieser Fakt immer mehr ein Problem geworden ist. 

Vielleicht muss man es anders ausdrücken: Ich verstehe den Schritt weg von Windows...

Insgesamt gesehen ist der Release einer neuen Version bei jedem Hersteller spannend und die Richtlinie: "Rühre keine x.0 Version an" gilt fast überall.


----------



## mkd (4 Dezember 2019)

@KGU: Arbeitest du für/bei Beckhoff?
Das Prinzip mit Vertriebsingenieuren zu arbeiten ist gut. Technisch sind alle richtig gut drauf.

Letztendlich steckt da aber „Vertrieb“ drin was heißt das man verkaufen MUSS.
Da ist m.M.n. eine vornehme Zurückhaltung, was die massiven Probleme mit TwinCAT3 im täglichen Umgang angeht, „angebracht“.


----------

