Nach dem "praktischen" Vorschlag, hier noch etwas sinnvolle Theorie:
Um sowas ganz allgemein zu beschreiben, bietet sich die Orientierung am OSI Sichtenmodel an. Wenn dir das noch nix sagt, da lohnt egal ob vorweg oder hinterher mal ein Blick ins INET.
Grob gesagt, beschreibst du hier folgendes:
Übertragungsschicht: "seriell" via USB
Protokollschicht: du bist der Master und sendest Daten(Komandos) an den Slave(die Maschine), und wenn fertig vom Slave eine Quittung empfangen wird (bzw. nach WorstCase nach Zeit X ein Timeout ist)
Komandoschicht: hier werden in Abhängigkeit vom aktuellem Status synchron die passenden Befehle bei Bedarf einzeln oder aus einer JobQueue via Protokollschicht gesendet/empfangen
Applikationsschicht: hier wird alles Initialisiert, die alle Stati visualisiert und es werden Einzelbefehle oder ganze Befehlsjobs asynchron der Komandoschicht übergeben
Das hier vorgeschlagene Delphikonzept fasst Protokollschicht und Komandoschicht quasi zu einer "EventDriven-Statemaschine" zusammen. Das ist so möglich und spart etwas Overhead im Konzept. Das OSI Modell besteht eh aus noch ein paar mehr Schichten und Zusammenfassung von Funktionalität ist durchaus üblich.
Um Sinn oder Unsinn dieser Standardvariante besser zu beurteilen, überlege dir folgendes:
- du willst wahlweise nicht USBseriell sondern auch per Ethernet TCPIP oder UDP mit deiner oder einer anderen Maschine kommunizieren
- du willst mit deinem Programm was HPGL einliest und den Bearbeitungsverlauf anzeigt, künftig auch weitere Maschinentypen(mit eben anderen Komandos für vergleichbare Funktionalität) bedienen
=> Dann helfen die die "Schichten" stets nur das zu ergänzen oder neu zu schreiben was fehlt, der Großteil deiner Software bleibt möglichst unangetastet gleich.
Es ist durchaus in Ordnung, wenn du sowas erstmal auf Funktion programmierst, nur spiele gedanklich einfach mal was wäre wenn... und über lege wie du wo mögliche Erweiterungen so einbauen könntest, das es keine unendlche "If/Then/Case" Orgie entsteht.
Es klinkt verrückt, aber nicht das einbauen einer zusätzlichen Variante wird (künftig) ein Problem, sondern das möglichst einfache optionale wieder weglassen einer solchen Erweiterung.
Programmierer für Datenbanken, GUIs, WEB, MiddleWare gibt es in zig Sprachen native wie Scripts wie Sand am Meer.
Leute mit technischem Verständnis die von Frontend-Programmierung bis LowLevel in Hardware nochmit einzenlen Bytes umgehen können, sind sehr rar!
=> Für 10.Klasse ist es toll, wenn dir HW nahe praktische Microcontroler&Embedded-Programmierung UND PC-
GUI-Software via Standard-Interfaces und -Protokollen liegt.
Wenn du dazu noch etwas löten und Schaltpläne lesen kannst/lernst, stehen dir künftig sehr viele Türe offen... wünsche weiter viel Erfolg!