Guten Abend, ich habe eine Frage an alles Experten aus dem Bereich Schrittmotoren und Parallel Port. Ich habe mir eine Portal Fräse aufgebaut. Die mechanische Hardware habe ich mir gekauft und die Elektronik selbst zusammengebaut. Ich nutze 4 Endstufen für 3 Achsen (X-Achse hat zwei Motoren) Zusätzlich nutze ich ein Breakoutboard für 5 Achsen und diverse Endschalter etc. Breakoutboard: http://www.ebay.de/itm/5-Axis-CNC-Breakout-Board-Interface-Adapter-forStepper-Motor-Driver-DB25-Cable-/150894632553?pt=LH_DefaultDomain_0&hash=item2322055e69 Die Motoren funktionieren einwandfrei ohne Probleme. Leider habe ich ein gang anderes Problem. Ich habe festegestellt dass sich sporadisch ein Fehler einschleicht. Wenn ich den Rechner (XP SP3) runterfahre und der Rechner ausgeschaltet ist fangen plötzlich die Endstufen wild an zu reagieren und die Motoren zappeln etc. Sogar bei ziehen den PC-Netzsteckers ist das Schauspiel noch zu betrachten. Schalte ich den Rechner ein funktioniert alles wider einwandfrei. Leider habe ich festgestellt, dass manche Pins auch im Betriebszustand der Maschine kurze Störungen der Pegel aufweisen? Ich habe alles im Schaltschrank mit PE verbunden so wie es sich gehört. Ich hoffe Ihr habt Ideen und Ursachen für mein Problen ich vermute eine Schleifenbildung über den Parallelport, vielleicht helfen Widerstände ? Nur warum tritt der Fehler nur sporadisch auf? Hoffe ihr könnt mir helfen :-(
Angehängte Dateien:
-
Portalfraese.jpg
2,7 MB
Das PC-Bios macht beim Hochfahren einen Test des Parallelports und aktiviert dafür z.B. /Init und manchmal auch /Select. Beim Herunterfahren ist das alles nicht so definiert und irgendwann sind alle Pins auf 0 Volt. Diesen Fall musst du in deiner Steuerung abfangen. Oder du schaltest konsequent die Motorsteuerung aus, bevor du den Rechner runterfährst. Störungen auf den Leitungen des Parallelports gehören zu den ewigen Ärgernissen. Spitzen auf der /Strobe Leitung sind eigentlich schon normal und werden normalerweise mit einem kleinen RC-Glied abgefangen - z.B. 470R und 1n. Ein Schmitt-Trigger Empfänger kann bei schwierigen oder extrem schwächlichen LPT Ports auch helfen. Das wichtigste ist aber ein gutes Kabel - nicht diese dünnen Chinaprodukte sondern ein dickes, gut geschirmtes Qualitätskabel hilft am besten.
Vielen Dank für die Antwort. Gibt es nicht für die Störsicherheit ein Parallel Port Adapter oder so was ähnliches ? Wenn diese Probleme schon bekannt sind und auch häufig auftreten muss es doch schon eine einfache Lösung geben. ein RC Filter für alle Eingänge kann natürlich auch von mir selbst gebastellt werden jedoch suche ich nach einer fertigen Lösung ohne einen Parallel Port Adapter zu entwickeln :-) Das Mainboard ist sehr alt was aber nicht heißt das die Elektronik schlecht ist oder nicht funktioniert. Ich möchte ganz einfach eine Störsicherheit für meine Fräse schaffen ohne viel Zeit und Aufwand zu investieren da ich schon viele Stunden mit dem Bau der Maschine + Renovierung des Raumes + + + :-) Hoffe es gibt eine schnelle Lösung, ich scheue auch keine Kosten :-)
Weiß nicht, ob es weiterhilft: Habe ein ähnliches Projekt programmiert, es handelt sich um einen sehr großen Stiftplotter, der auch fräsen ond bohren kann. Das ganze habe ich komplett selber gebaut und programmiert. Die Treiber-Bausteine sitzen direkt an den Schrittmotoren. Für die Verbindungen vom Parallelport zu den Treibern benutze ich mehradrige Schaltlitze, die mehrfach um einen dicken Ringkern gewunden sind. Die Steuerung für den Parallelport ist in Quickbasic geschrieben (Bresenham steuert Schrittmotor-Pins). Das ganze läuft nur unter DOS einwandfrei, habe extra einen älteren Schleppi dafür besorgt und zum DOS-Rechner gemacht. Wenn man das ganze unter Win98, 2000 oder XP betreibt, gibt es Timingprobleme am Port, die sich (zumindest mit meinen Mitteln) trotz etlicher Versuche nicht beheben ließen. Das ganze hat aber auch einen Vorteil: Quickbasic ist unter DOS extrem schnell :O) Vielleicht hilft dir das irgendwie weiter. Viele Grüße, Daniel
Je nach Alter des Mainboards kannst Du eine zusätzliche ISA- oder PCI-Karte für einen weiteren Parallelport einbauen. Damit dürften die Initialisierungen durch das BIOS beseitigt werden. Man beachte, dass die Plug&Play-Verfahren von MS Windows auch an den Daten- und Steuerleitungen von seriellen und parallelen Schnittstellen wackeln, um dadurch nachträglich angeschlossene Geräte zu erkennen. Vielleicht hilft es auch, im BIOS die Einstellungen für die Betriebsarten EPP und/oder ECP des Parallelports zu verändern. Sofern der PC noch ISA-Steckplätze hat, lohnt es sich, Ausschau nach einer Parallelportkarte zu halten, die diskret aufgebaut ist, d.h. neben dem Adressdecoder noch ein paar 74xx373/374 o.ä. hat. Dann ist es ein Leichtes, diese Bausteine mit einem externen Freigabesignal zu versehen.
Ich sorg mal wieder für die Statistik. Ein 2.7 MB großes JPEG-Bild für den Aufbau ist ja sehr sinnvoll....vielleicht kommt ein Mod und erbarmt sich dazu das Bild zu verkleinern...
Johannes schrieb: > Gibt es nicht für die Störsicherheit ein Parallel Port Adapter oder so > was ähnliches ? Wenn diese Probleme schon bekannt sind und auch häufig > auftreten muss es doch schon eine einfache Lösung geben. Die Probleme mit Druckern am Parallelport sind so alt wie die Ports selber, deswegen haben alle mir bekannten Drucker recht umfangreiche Eingangsfilter. Früher(tm) waren die LPT Ports tatsächlich noch mit kräftigen TTLs der Reihe 74(LS)373 und '374 bestückt, da waren die Probleme nicht so gross, wie sie heute mit billigen dünnen Kabeln und den 'All-in-One' Chipsätzen sind. Eine andere Druckerkarte zu benutzen, kann also durchaus was bringen. Johannes schrieb: > Hoffe es gibt eine schnelle Lösung, ich scheue auch keine Kosten :-) Dann besorg dir neben einer neuen Druckerkarte ein schönes Qualitätskabel mit reichlich Masseleitungen, um das Übersprechen zwischen den Leitungen gering zu halten.Sorge auch für einen anständigen Abschluss in der Fräselektronik mit Pulldowns oder Pullups. Bedenke dabei, das Längen über 3m niemals im Standard vorgesehen waren, als IBM aus der Centronics Schnittstelle den LPT Port gemurkst hat.
Johannes schrieb: > für die Störsicherheit ein Parallel Port Adapter Gibt es. Breakoutboards, die einen softwaregenerierten Pilotton auf dem LPT-Port benutzen. Nur wenn deine Steuersoftware diesen Pilotton generiert, werden die Endstufen angesteuert. Ansonsten sind sie regungslos, da zappelt gar nichts. Das Bord von Benezan z.B. hat das, benutze ich auch.
Johannes schrieb: > Wenn diese Probleme schon bekannt sind und auch häufig > auftreten muss es doch schon eine einfache Lösung geben. Die Lösung ist, den Parallelport auf die Rote Liste zu setzen. Und wie einigen anderen Arten wird er ohne große Lobby über kurz oder lang ganz verschwinden. Und wie es aussieht, mangelt es an einer größeren Lobby.
Michael schrieb: > Die Lösung ist, den Parallelport auf die Rote Liste zu setzen. Und wie > einigen anderen Arten wird er ohne große Lobby über kurz oder lang ganz > verschwinden. Und wie es aussieht, mangelt es an einer größeren Lobby. Wobei ein Parallelport eigentlich eine coole Sache ist, wenn er das macht, was er soll. @Johannes: Hast du mal geschaut, was im BIOS zum Parallelport eingestellt ist? Dort kann man normalerweise verschiedene Betriebsarten wählen, z.B.: -ECP -SPP -EPP Hast du die schon durchprobiert? Hier mehr zum Thema: http://de.wikipedia.org/wiki/Standard_Parallel_Port http://de.wikipedia.org/wiki/Enhanced_Parallel_Port http://de.wikipedia.org/wiki/Extended_Capabilities_Port
Daniel C. schrieb: > Wobei ein Parallelport eigentlich eine coole Sache ist, wenn er das > macht, was er soll. Wenn man damit direkt die Schrittmotorspulen steuert und dabei saubere Rampen fahren möchte, ist schon deutliche Echtzeitfähigkeit des OS gefordert und der gemeine Win-PC stößt da bald an seine Grenzen.
Michael schrieb: > Wenn man damit direkt die Schrittmotorspulen steuert und dabei saubere > Rampen fahren möchte, ist schon deutliche Echtzeitfähigkeit des OS > gefordert und der gemeine Win-PC stößt da bald an seine Grenzen. So siehts in der Realität aus! Deshalb betreibe ich Stepper knallhart nur noch unter DOS. :O)
Daniel C. schrieb: > Michael schrieb: >> Wenn man damit direkt die Schrittmotorspulen steuert und dabei saubere >> Rampen fahren möchte, ist schon deutliche Echtzeitfähigkeit des OS >> gefordert und der gemeine Win-PC stößt da bald an seine Grenzen. > > So siehts in der Realität aus! Deshalb betreibe ich Stepper knallhart > nur noch unter DOS. Son Unsinn. Für Linux gibt es problemlos Realtime Kernel. Kein Grund für ein Urzeitliches OS.
Simon K. schrieb: > Son Unsinn. Für Linux gibt es problemlos Realtime Kernel. Kein Grund für > ein Urzeitliches OS. Das könnte man mal überlegen, wenn man es öfter braucht. Läuft auf der genannten Oberfläche auch Quickbasic?
Erstaunlicherweise gibt es auch Windows Software, z.B. Mach3, die auch ohne wirkliche Echtzeitfähigkeit ganz gut funktioniert. Sich also stets auf die Software rauszureden gilt nicht ;)
Vincent Hamp schrieb: > Erstaunlicherweise gibt es auch Windows Software, z.B. Mach3, die auch > ohne wirkliche Echtzeitfähigkeit ganz gut funktioniert. Sich also stets > auf die Software rauszureden gilt nicht ;) Klar, funktionieren tuts. Die Sache ist nur, dass sich Timingprobleme (Jitter und Delay-Spikes) sich natürlich auf die Qualität der Bewegung der Fräse niederschlägt. Und das hat man beispielsweise mit Linux-CNC besser im Griff.
Daniel C. schrieb: > Simon K. schrieb: >> Son Unsinn. Für Linux gibt es problemlos Realtime Kernel. Kein Grund für >> ein Urzeitliches OS. > > Das könnte man mal überlegen, wenn man es öfter braucht. Läuft auf der > genannten Oberfläche auch Quickbasic? Quickbasic, das ist doch aus dem letzten Jahrtausend. Schau dir Linux-CNC an. Das gilt als sehr ausgereift und stabil und kann auch in kommerziellen Umfeld benutzt werden. Das frisst quasi G-Code, den du mit einem CAM Programm aus deinen proprietären Daten erzeugen kannst.
Nur um G-Code in zeitstabile Schrittmotorsignale umzusetzen, ist ein kompletter dedizierter DOS-PC vielleicht etwas übertrieben.
Michael schrieb: > Nur um G-Code in zeitstabile Schrittmotorsignale umzusetzen, ist ein > kompletter dedizierter DOS-PC vielleicht etwas übertrieben. Aber kostengünstig, simpel und leicht verfügbar. Zumindest jetzt im Falle von Linux-CNC
Johannes schrieb: > Ich habe festegestellt dass sich sporadisch ein Fehler einschleicht. > Wenn ich den Rechner (XP SP3) runterfahre und der Rechner ausgeschaltet > ist fangen plötzlich die Endstufen wild an zu reagieren und die Motoren > zappeln etc. Sogar bei ziehen den PC-Netzsteckers ist das Schauspiel > noch zu betrachten. Schalte ich den Rechner ein funktioniert alles wider > einwandfrei. > > Leider habe ich festgestellt, dass manche Pins auch im Betriebszustand > der Maschine kurze Störungen der Pegel aufweisen? Aber auf dem Bild ist Ubuntu/Linux als OS. Was für ein CNC-Programm wird für die Maschine denn verwendet?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.