Moin,
hier geht einiges durcheinander - manches stimmt, manches stimmt teilweise und der rest ist schlicht falsch.
sswjs hat geschrieben: ↑04.05.2025, 09:29
...das ist doch egal, welchen Anschuß zu welchen Anschluß die Umsetzen, es ist immer ein Umsetzer. Controller kommen ohne PC aus.
Diese Aussage ist schonmal falsch, weil sie unterstellt, die als "Controller" bezeichneten Teile würden irgendwie einen Parallelport "auslagern". D.h.: (so vorgestellt) man "bildet" im Steuerprogramm einen virtuellen Parallelport ab und schleust den dann per USB oder LAN an einen Umsetzer (dann wäre die Bezeichnung auch korrekt) und der macht dann wieder einen physikalischen Parallelport draus. Genau das passiert aber nicht.
Was ist dieser Parallelport überhaupt? Anfänglich war das ein reiner Druckerport für die Ausgabe von 8 Bit parallel und ein paar Steuersignalen. Später wurde er dann bidirektional, konnte also auch Daten empfangen und das wurde bspw. für billige Scanner benutzt. Dann kamen findige Leute drauf, dass man das Ding auf Hardwareebene auch "manipulieren" kann und so einzelne Leitungen/Pins für die Datenein- und -ausgabe - z.B. für Steuerungszwecke nutzen kann. Von da war es dann nicht mehr weit für eine in Software implementierte "Pulsing-Engine" (wird in Mach3 so bezeichnet), die komplexe zeitkritische Datenausgaben auf Einzelleitungen ermöglichen. Das wurde in 16 Bit programmiert um direkten Zugriff auf die Hardware zu haben (weil zeitkritisch).
Zuerst unter DOS, dann unter Windows 95 und 98. Die 16 Bit merken wir uns mal.
Wesentlich ist, dass das DIng schon hier kein Parallelport mehr ist, sondern mit dem ursprünglichen Druckerport nur noch den physikalischen Anschluss gemein hat. Der Unterschied zw. "Controller" und "Umsetzer" wird mMn. darüber definiert, wer die Schritte erzeugt. Das ist bei "Parallelport"-Steuerungen die Software und bei "Controllern" die Hardware. D.h.: Der "Controller" bekommt keine Impulse, sondern Vektoren und erzeugt dann selbst die Schritte.
Man sollte das mal historisch betrachten. Die CNC-Fräsen der Industrie hatten zu Anfang tatsächlich PC als Steuerung. Darin eingbaut waren spezielle Karten, die die Steuersignale für die Motoren, Relais und sonstige Ansteuerungen erzeugten und Eingänge für alle möglichen End- und Sicherheitsschalter bereitstellten. Auch heute noch gibt es solche Karten, bekannt als Mesa-Karten.
Die Industrie-Steuerungen sind im Grunde auch heute noch "PCs" - nur eben keine "Standard-PCs". Steckkarten waren Standard, aber es gab bspw. auch serielle Anbindungen (RS232), wo auch schon die Schritterzeugung in Hardware vom ext. "Controller" stattfand.
Was heute über USB oder LAN passiert, ist im Grunde eine Weiterentwicklung der RS232-Anbindungen und nicht des Parallelports.
Für die Käsefräsenbastler waren die aber viel zu teuer, so daß der Druckerport, also Parallelport, dafür mißbraucht wurde. Nun hat aber Microsoft entschieden, den Parallelport, ab Win7 64Bit, nicht mehr zu unterstützen.
Nö! Wie oben schon geschruben, ist das 16 Bit code. Die ersten Parallelportsteuerungen liefen unter DOS und diesen code schleppen wir nun schon seit über 3 Jahrzehnten mit. Alle 32 Bit Windows-Versionen haben eine 16 Bit-WOW (Windows on Windows) - das Ding heißt NTVM. 64 Bit WIndows-Versionen haben die NICHT mehr, sondern zur Abwärtskompatibilität nur noch eine 32 Bit-WOW.
64 Bit Windows gibt es seit Windows 2000, was aber m.W. nie offiziell auf dem Markt kam. Das hat also mit Windows 7 rein gar nix zu tun, denn schon XP gab es offiziell als 64 Bit-Version, dann Vista, dann W7, dann W10 (64 und 32) und erst mit Windows 11 gibt es keine 32-Bit-Version mehr. D.h.: Unter 64 Bit hat das noch nie funktioniert und 32 Bit geht auch mit W10 noch. Wie "gut", sei mal dahingestellt....
Deshalb haben alle Fräsprogrammhersteller, die den Parallelport genutz haben, hektisch Umsetzer auf den Markt gebracht. Zuerst war das USB auf LPT (Line Print Terminal)....
So was hat es zwar mal gegeben, um per USB einen Parallelport-Drucker anschließen zu können, aber eine Fräse konnte man darüber nie steuern. Drucken ist ein ganz anderes Thema - der muss nämlich nur "stumpf" ASCII-Code ausgeben. Wesentlich ist die Impulserzeugung und die kann bei solchen Adaptern eben nicht mehr im PC stattfinden, sondern muss auf den "Controller" ausgelagert werden.
Mit fortschreitender Entwicklung ist jetzt das (Gigabit-) Ethernet wieder schneller und wurde immer interessanter für die Umsetzer, so das eben die Umsetzer jetzt für's Netzwerk auftauchten.
Die LAN-Controller haben auch mit 100 Mbit Ethernet schon gut funktioniert - wahrscheinlich würde es auch mit 10 MBit gehen.
Mit USB 1.1 liefen die Controller ja auch schon und das schafft (theoretisch) 12 Mbit.
Aber so was, wie den HAL, werden wir bei Käsefräsenprogrammherstellern niemals finden, wegen...
Der HAL ist eine Betriebssystemfunktion - kommt also vom Linux und nicht vom Käsefräsenprogrammhersteller.
Windows (in allen Versionen) hat übrigens auch einen HAL - nur mit dem Unterschied, dass der nicht verläßlich Echtzeitfähig ist und man den ganzen 16-Bit-code komplett neu schreiben müsste. Vermutlich würde es aber trotzdem nicht sauber funktionieren, weil einfach zu viele Schichten Software dazwischen sind und man eben nicht mehr direkt auf die Hardware zugreifen kann.
Gruss
Karl
