Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
Hallo,
ich habe von Version 3.5.19.0 auf 3.5.19.40 hochgerüstet, jetzt bekomme ich bei allen FUNs die "to" im Namen haben einen Fehlermeldung. Oft in der OSCAT.LIB verwendet.
Gleiche Meldung wenn ich einen FUN neu anlege. Sobald ich das to weglasse z.b. nur "t" ist der Fehler weg.
Programm ist unverändert.
Fehlermeldung: Typ.... wird nicht unterstützt.
Hat jemand das gleiche Problem? Bzw. wo liegt das Problem? Bzw. nutzt jemand das SP4 und bei ihm kommt der Fehler nicht?
Läuft bei mir auf Rasperry.
Beispiel:
DT_TO_SDT -> Fehlermeldung Typ DT_TO_SDT wird nicht unterstützt.
DT_T_SDT -> Übersetzung Fehlerfrei
@PaRo
erst mal vielen Dank für die Antwort.
Wundert mich das so ein schwerer Bug nicht sofort gefixt wird. Wenn es keine offene Lib wäre, wäre keine Workaround möglich. Auch bei einem bestehende umfangreichem Programm nicht wirklich praktikabel.
Gibt es irgendwo eine Liste mit bekannten Bugs? Gefunden habe ich nichts.
Ich muss wohl wieder auf die alte Version zurück.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich habe von Version 3.5.19.0 auf 3.5.19.40 hochgerüstet, jetzt bekomme ich bei allen FUNs die "to" im Namen haben einen Fehlermeldung. Oft in der OSCAT.LIB verwendet.
Gleiche Meldung wenn ich einen FUN neu anlege. Sobald ich das to weglasse z.b. nur "t" ist der Fehler weg.
Programm ist unverändert.
Fehlermeldung: Typ.... wird nicht unterstützt.
Hat jemand das gleiche Problem? Bzw. wo liegt das Problem? Bzw. nutzt jemand das SP4 und bei ihm kommt der Fehler nicht?
Läuft bei mir auf Rasperry.
Beispiel:
DT_TO_SDT -> Fehlermeldung Typ DT_TO_SDT wird nicht unterstützt.
DT_T_SDT -> Übersetzung Fehlerfrei
Last edit: bernd 2023-11-09
hi, den einen workaround kennst du ja. Ein anderer wäre es ST zu nutzen. Ich glaube der Fehler ist bereits bei CODESYS adressiert.
@PaRo
erst mal vielen Dank für die Antwort.
Wundert mich das so ein schwerer Bug nicht sofort gefixt wird. Wenn es keine offene Lib wäre, wäre keine Workaround möglich. Auch bei einem bestehende umfangreichem Programm nicht wirklich praktikabel.
Gibt es irgendwo eine Liste mit bekannten Bugs? Gefunden habe ich nichts.
Ich muss wohl wieder auf die alte Version zurück.