TIA AWL in FUP umschreiben

Zuviel Werbung?
-> Hier kostenlos registrieren
... trotz all der Möglichkeiten im Jahr 2025. :
Eine schlauerwerdende KI scheint mir dafür auch keine PatentLösung zu sein. Wer soll sich darum kümmern, die KI im Zaum zu halten, damit sie nicht übermütig wird?
Doch eine KI ist für sowas eine Lösung. Wenn man ein Modell genau auf diese Aufgabe trainierst, dann musst du sie auch nicht im Zaum halten. An und für sich ist sowas nichts anderes als eine Art Mustererkennung.
 
Doch eine KI ist für sowas eine Lösung. Wenn man ein Modell genau auf diese Aufgabe trainierst, dann musst du sie auch nicht im Zaum halten. An und für sich ist sowas nichts anderes als eine Art Mustererkennung.
Grundsätzlich eine (un-?)eingeschränktes "ja", Dieter. Wenn man es schafft, die KI bereits in der AnlernPhase sinnvoll und durch einen "ZweiBeiner" überwacht zu lenken und zu zähmen. Genauso grundsätzlich habe ich ein wenig Angst davor, dass die Kosten für ein nachträgliches Überarbeiten und Korrigieren der gelernten Eigenschaften davor abschrecken können, sie auch tatsächlich auszuführen.
Interessant an der KI ist aus meiner Sicht, dass man sie so gestalten kann, dass Gelerntes für andere "Geräte" durch einfaches Kopieren übernommen werden könnte. Dies wäre aber nix, was mit "künstlicher" Intelligenz zu tun hat, sondern nur ein angenehmer NebenEffekt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, sicher geht es "nur" um die Darstellung "auf dem PG" oder vom PG aus z.B. auf Papier ausgedruckt. Allerdings finde ich, dass das Wort "nur" nicht wirklich gerechtfertigt ist.
Es steckt schon einiges dahinter, ein QuellProgramm "nur" mal eben maschinell wahlweise in verschiedenen DarstellungsFormen anzuzeigen.
Das muss wohl überlegt sein, wie man das hinkriegt, insbesondere mit so wenig Aufwand und realisierbar mit so wenig Ressourcen wie man insbesondere zu S5-Zeiten noch halbwegs bezahlbar zur Verfügung hatte. Bei FUP und KOP muss ja auch abgespeichert werden, wie bzw. wo die einzelnen Elemente (auch die "Verdrahtungen") auf dem Bildschirm bzw. Papier angeordnet werden.
Für die WirkungsWeise des Programms irrelevante ZusatzInformationen im ProgrammSpeicher abspeichern zu müssen, war ein StörFaktor, den es zu minimieren galt. Klar, dass ein AWL-Programm weniger Informationen enthalten konnte, wenn es nicht wahlweise als FUP oder KOP dargestellt werden musste. Klar, dass die AWL-Variante ohne den AnzeigeLuxus für FUP und KOP kompakter und ein wenig schneller ausführbar sein konnte.

PS:
Wer braucht NOP 0 (alle 16 Bits haben den Wert 0) und NOP 1 (alle 16 Bits haben den Wert 1)? Eigentlich niemand, der diese "funktionslosen" Codes bereitwillig durch ZusammenSchieben der Worte eliminiert (und den neuen Code abspeichert und den alten Code wieder für neue Verwendung freigibt - eine umgekehrte Reihenfolge der Schritte hätte Platz gespart, aber das laufende Programm zum Abstürzen bringen können). Aber den dafür nötigen SpeicherBedarf und die dafür nötige AusführungsZeit wollte damals auch niemand spendieren. Es musste an HardwareKosten gespart werden, koste es, was es wolle.

Hat schon mal jemand beobachtet, dass im Speicher bzw. EPROM die Bits invertiert waren bzw. sein konnten?
Alle Bits eines Wortes = 0 (z.B. frisch gelöschtes oder nicht vorhandenes EPROM) sah dann im Speicher so aus: FFFFh bzw. alle Bits eines Wortes = 1 sah dann im Speicher so aus: 0000h. Klingt verwirrend, aber diese Interna musste niemand wissen.

PPS:
hatte mal mit einer CPU zu tun, bei der der Befehl 0000h einen Sprung zum UnterProgramm auf der Adresse 0000h bedeutete. Also kein NOP. Aber irgendwie auch sinnvoll: es fiel auf und war abfragbar, wenn ein leerer Speicher "ausgeführt" werden sollte. Und man hatte die Adresse des verunglückten SprungBefehls im Akku.
Das "nur" in meinem Satz war nicht als Abwertung gedacht, sondern als Abgrenzung zu den Bildern in WinCC. Mir ist durchaus bewusst, dass es äußerst aufwendig war, mit den damals beschränkten Ressourcen Funktionen möglichst effizient umzusetzen.

Generell finde ich ältere Technik und Legacy Software äußerst interessant. Nur da das alles vor meiner Zeit ist, muss ich das ganze Wissen noch nachholen ;)
Heute ist Low-Code oder No-Code modern. Den erzeugten Code anzeigen können die meisten Tools, ändert man dann was im erzeugten Code, ist es schnell vorbei mit Low-Code.

Von No-Code/Low-Code Lösungen halte ich nicht viel. Ich habe das Gefühl, dass dadurch das Verständnis verloren geht. Das ist wie mit KI. KI als Tool zum Lernen ist äußerst hilfreich. Wenn man KI aber als "Denkersatz" nutzt, entwickelt man auch kein Verständnis der Dinge.
 
Die Umschaltung der Darstellung bzw. Programmiersprachen war schon interessant.
Definitiv! Wo hat man heute noch diesen Luxus, dass man sich entsprechend eigenen Vorlieben die ProgrammierSprache aussuchen kann?
Heute ist Low-Code oder No-Code modern.
Low-Code kenne ich nicht. Es sei denn, es handelt sich dabei um "RISC" (= reduced instruction set code).
Das wäre ein gaaanz simpler Code. Komplexere Funktion-(alität-)en muss man damit quasi selbst programmieren bzw. aus Bibliotheken zusammenstellen.
Oder ist damit genau das Gegenteil gemeint: der Code kennt sehr, sehr viele (auch komplexe) Befehle, die viel können, aber selbst wenig Platz im Speicher belegen.

Unter "No-Code" stelle ich mir etwas vor, was ich vor Jahrenden mal in BASIC auf einem Commodore gemacht habe: Der eigentliche ProgrammCode war quasi Standard, jedoch sehr auf eine bestimmte Anwendung spezialisiert (= beschränkt). Die eigentliche individuelle Programmierung bestand darin, ParameterListen anzulegen bzw. anzupassen. Damit habe ich quasi eine Familie von recht kompakten Editoren (zur Erfassung von diversen ZuordnungsListen) realisiert, die seitens der BedienOberfläche. streng einheitlich gestaltet werden konnten, ganz einfach, weil sie es mussten. Mit sehr wenig SpeicherPlatz auszukommen, war das oberste Ziel der "Übung".

Doch eine KI ist für sowas eine Lösung. Wenn man ein Modell genau auf diese Aufgabe trainierst, dann musst du sie auch nicht im Zaum halten.
Für mein Verständnis ist KI etwas, das überwiegend selbständig Informationen (und Erfahrungen) sammelt, "versteht" und dementsprechend einordnet und verknüpft und schliesslich lernt (= abspeichert.). Es geht aber nicht allein um das vorbehaltlose, fleissige Sammeln. Es beinhaltet auch das selbständige Erkennen und Zusammenfassen/Vereinfachen von gleichbedeutenden oder sehr ähnlichen "Erkenntnissen" oder Strukturen. Ggfs müssen auch bereits gelernte Erkenntnisse, wenn sie als falsch erkannt werden, gelöscht werden. Wie erfährt die KI aber, wenn etwas "unmoralisch" ist oder gegen Gesetze verstösst? Die KI muss auch Bereiche erfassen und berücksichtigen, die nicht unmittelbar erkennbar zum eigentlichen Thema gehören bzw. zum gesetzten Ziel führen.
Ich denke, hier wird schnell etwas aus dem Ruder laufen, wenn die "Erfolge" der KI nicht ständig streng kontrolliert werden.

An und für sich ist sowas nichts anderes als eine Art Mustererkennung.
Ja, aber ist für eine MusterErkennung der Begriff "künstliche Intelligenz" nicht recht überzogen?
Bei der MusterErkennung geht es doch hauptsächlich "nur" darum, eigene Erkenntnisse zu sammeln und vor allem, fremde Erkenntnisse in die eigenen zu integrieren und umgekehrt die eigenen Erkenntnisse anderen KIs zur Verfügung zu stellen.
Die einzelnen KIs sollen nicht nur mühsam eigene Erfahrungen sammeln, sondern auf von anderen KIs mühsam gesammelte Erfahrungen einfach zurückgreifen können. Letzteres spart enorm viel Zeit und sorgt dafür, dass sich die KIs gegenseitig kurzfristig auf annähernd den gleichen Stand bringen können. Das sind m.E. die eigentlichen Vorteile. Man kann sich nicht erlauben, jede einzelne KI beim KenntnisStand 0 den Sprung ins kalte Wasser machen zu lassen und alle Erfahrungen selbst zu sammeln, bis irgendwann ein brauchbarer KenntnisStand erarbeitet wurde. Eine solch schlecht vorbereitete KI muss noch sehr intensiv an sich arbeiten, ehe sie "produktiv" eingesetzt werden darf
Der eigentliche Trick an der Sache ist doch, dass eine KI per "Nürnberger Trichter" (= Kopieren von ParameteListen) in NullKommaNix gefüttert (= angelernt) werden könnte, wenn sie dafür ausgelegt wurde - im Gegensatz zu einer natürlichen Intelligenz, die dafür jahrelang z.B. zur Schule gehen muss.
Die Austauschbarkeit der Erkenntnisse verschiedener KIs ist nicht notwendig eine Eigenschaft, die die KIs von Hause aus mit sich bringen. Insofern ist nicht so sehr die Eigenschaft KI charakteristisch für die Anwendung, sondern es muss eine sein, die eine einfache Austauschbarkeit des Gelernten gewährleistet. Die KIs müssen ausserdem in der Lage sein, die KenntnisStände zweier KIs zügig und sicher zusammenzuführen.
 
Zuletzt bearbeitet:
@Heinileini
Eine typisches Beispiel für LowCode / NoCode aus deinem Umfeld ist z.B. CAD/CAM in den verschiedenen Ausprägungen. Bei einfachen Programmen wählst du Werkzeuge, Konturen, Zyklen und all das und daraus wird dann Gcode erzeugt. Im besten Fall hast du nen "Produziere"-Button am 3D-CAD und musst dich um nichts mehr kümmern.

KI ist ein weiter und wachsweicher Begriff, der heute schon fast überall draufsteht. Welche Eigenschaften sich dahinter verbergen, ist heute wohl eher Sache der Werbe- und Verkaufsabteilung.
Versuch mal ein konkretes etwas komplexeres Problem aus dem Programmierumfeld mit ChatGPT bis ins Detail zu lösen. Also nicht nur Algorithmen suchen oder ein Grundgerüst erstellen sondern eine komplette Lösung. Da merkt man dann recht schnell, wo die aktuellen Grenzen sind. So wohl die eigenen Grenzen beim Beschreiben des Problems als auch die Grenzen der KI beim Verstehen und erstellen der Lösung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
KI vs. Algorithmus
Das Thema driftet mir etwas zu stark in Richtung „KI“. Für einfachen AWL-Code braucht’s keine künstliche Intelligenz, sondern nur einen klaren, deterministischen Algorithmus. Bei normalen Logikverknüpfungen, Vergleichen, Timern oder Set/Reset reicht ein primitives Regelwerk völlig aus.
Natürlich wird’s anspruchsvoller, wenn im AWL Sprünge, indirekte Adressierungen oder ähnliche „Kunststücke“ stecken – aber auch das lässt sich mit einer sauberen Analyse und ein paar klaren Regeln abbilden.
Wenn man bedenkt, mit welchen Mitteln die Mondlandung damals realisiert wurde, kann man nur schmunzeln, wie verschwenderisch wir heute manchmal mit Ressourcen umgehen. Für einfache Logik braucht man keine KI-Rechenfarm.

Altcode 1:1 übernehmen – selten sinnvoll
Einen alten AWL-Baustein 1:1 in FUP zu übertragen, ist meist keine gute Idee.
Wichtiger ist, Ziel und Funktion zu verstehen – dann lieber neu entwickeln, statt Altlasten mitzuschleppen.
FUP ist bei klarer Bool-Logik völlig in Ordnung, aber sobald Rechenoperationen, Datenstrukturen oder dynamische Abläufe ins Spiel kommen, ist SCL meist die bessere Wahl.
Migration sollte also immer funktional motiviert sein, nicht syntaktisch.

Übung für das Verständnis
Wenn man solche Konvertierungen zu Übungszwecken durchführt, sieht die Sache natürlich anders aus.
Dann kann man AWL, FUP und ggf. SCL nebeneinanderstellen, Unterschiede nachvollziehen und damit experimentieren – ein sehr guter Weg, um die interne Logik und Signalverarbeitung besser zu verstehen.
AWL wird uns beim Pflegen älterer Anlagen ohnehin noch eine ganze Weile begleiten – also schadet es nicht, wenn man die Sprache weiterhin „lesen“ kann.
 
@Cassandra
Bei KI vs. Algorithmus widerspreche ich mal etwas.
Textanalyse ist eine der Stärken einer KI. Klar bei einfachen AWL-Code reicht ein einfaches Regelwerk für einen Algorithmus. Wird es komplexer, dann steigt der Aufwand aber extrem an.
Nimm mal ein beliebiges Stück Code aus einer Hochsprache und frage Grok oder ChatGPT was dieser Code macht.
Ich staune da immer wieder. (Teilweise auch über die Unterschiede zwischen Grok und ChatGPT)
 
Zurück
Oben