HPGL in Chip Freundliches Hallo miteinander … Frage, hat von euch einer mal ein Hpgl-Interpreter in einem Chip implementiert oder traut sich das jemand zu? Was ich meine, „vorne“ HPGL rein, „hinten“ Schrittmotorsteuerung“ raus. Wenn ja, würde ich mich mit demjenigen gerne näher unterhalten. Grüße, Lucky_Wolf
Ich nicht, aber Simen Svale Skogsrud hat ein C-Project realisiert, in dem er mit einem ATmega168 / ATmega 328 (16MHz) die drei Vektoren einer CNC-Fräse steuert(Arduino). Es interpretiert ein paar Grundbefehle der G-Code Steuersprache, so wie sie z.B. auch von Eagle oder SPrint(Isolationsfräsen) exportiert werden können. Das Video ist hier zu finden: http://dank.bengler.no/-/page/show/5470_grbl?ref=mst Es ist ein Open Source Projekt, der Sourcecode ist hier zu finden: https://github.com/simen/grbl Hieraus kann man viel über das Ansteuern von Schrittmotoren lernen - Timer, Rampen etc. Habe das mal nachgebaut mit dem pollin Evaluation Board und Stepper(end)stufen mit dem L297 und L298 - mehr braucht man nicht.
Hallo Rudi, erst einmal vielen Dank für die Antwort. Ja, ich kenne die L297 / 8 ... tolle Teile! Sind für mein vorhaben die "Kanonen" für die "Spatzen" :-) Denke da eher an die Ansteuerung von Schrittmotoren, wie man sie in alten Foppy oder CD-Laufwerken findet. In was für einen Chip das ganze realisiert wird, ist mir ziemlich egal. Hauptsache, es funktioniert :-)
Dieter Schmidt schrieb: > Denke da eher an die Ansteuerung von Schrittmotoren, wie man sie in > alten Foppy oder CD-Laufwerken findet. Da in dem o.a. Projekt die Steuersprache "G-Code" verwendet wird, ist es doch ein Einfaches, diesem Interpreter die gewünschten Befehle beizubringen.
Es liegt nicht einzig daran, die Signale zu dekodieren. Du musst auch noch dafür sorgen, dass die Motoren eine Geschwindigkeitskurve fahren, dh langsam anfahren, langsam abbremsen. Dann solltest du Sensoren haben, die messen, wo deine Motoren grade stehen. Das auslesen von hpgl ist ein leichtes, zumal ich soweit ich das kapiere, nur der linienbefehl heutzutage verwendet wird. Der Kreisbefehl zB, CI R, wird zumindest von inkscape, mit dem ich schon hpgls erzeugt habe, garnie verwendet. Auch adobe illustrator scheint alles über diese Befehle ausschliesslich zu machen PU, PD pen up, pen down AP absolute position POLYON .... und P1, p2 usw für die stifteauswahl nichteinmal das kompremierte vektorformat (binärdaten) wird angewand, sondern alle befehle sind im Klartext soweit ich weiss wer weiss...
Hi Rudi,hi nolo und all die Anderen, alles richtig! Da gehören die Start/Stop-Rampen und weiß ich was dazu. Alles das gehört in den Chip! Die Sprache ist mir wurscht ... ich habe davon keine Ahnung! Die zu bewegenden Massen werden wahrscheinlich unter 200 Gramm liegen und die benötigten Kräfte sind gering. Nochmals, was ich gerne hätte, ist ein Chip,den ich mit Hpgl "fütter" und der im Anschluß die Motoren bewegt. Sprache: egal Chip: egal Komme da eher von "der anderen Seite" und kenne mich in der Progamierung nicht aus. Deshalb meine Frage, wer hat einen Hpgl-Interpreter schon mal in einen Chip programiert oder traut sich das zu?
lucky_wolf schrieb: > Nochmals, was ich gerne hätte, ist ein Chip,den ich mit Hpgl "fütter" > und der im Anschluß die Motoren bewegt. In einem HPGL-Flachbettplotter ist das alles fix und fertig drin. Gruss Reinhard
Ja, an einem HPGL-Flachbettplotter habe ich auch schon gedacht. Ist mir nur zu groß ( und zu teuer). Aber wahrscheinlich werde ich mich mit dem Gedanken anfreunden müssen. Hatte gehofft, hier eine Alternative zu finden. Dessen ungeachtet, erst einmal vielen Dank an Alle für die Tipps & Hinweise. Grüße Dieter
Angehängte Dateien:
-
Fraese_Mainboard.jpg
110 KB
moin moin, einen G-Code-Interpreter, so als erweitertes HPGL, habe ich schon im Chip...siehe Bild. Rechts in die Buchsenleiste kommt noch ein 4x20Char-LCD drauf, nur sieht man dann nichts mehr von der Schaltung. MfG Pieter
Hallo Pieter, sieht interessant aus, klingt interessant ... Würde mich über Email gerne weiter mit dir unterhalten. Lucky_wolf@gmx.de Grüße, Dieter
Ich glaub ich seh nicht richtig (oder mein Leben is viel zu kompliziert) http://dank.bengler.no/-/page/show/5470_grbl?ref=mst Was is das für ein cam Programm ? Ich brauche zurzeit mit Solid Edge oder Corel draw eine halbe Ewigkeit um ein bild in Gcode umzusetzen
moin moin, das Foto zeigt die gesamte Fräsensteuerung, an den Motoren sitzen die Treiber. Kann mich Dienstag erst melden, eMail nur in der Firma. Montag ist Feiertag == FräsenTag. MfG Pieter
Ich finde die Implementierung von HPGL in den Controller zummindestens für eine 3-Achsen Maschine nicht so optimal, weil es in HPGL nur PU (Werkzeug hoch) und PD (Werkzeug runter) gibt, aber keine Möglichkeit zu definieren, wie weit. mfG ingo
Ingo Wendler schrieb: > aber keine Möglichkeit zu definieren, wie weit. Das wurde allein durch die Mechanik im Plotter gelöst. Es war halt nur ein Elektromagnet, welcher einen oberen Anschlag hat. Im abgesenkten Zustand lag die Spitze des Stiftes durch dessen Schwerkraft auf dem Papier auf. Mehr steckt nicht dahinter.
Sorry ... Der freundliche Gruß kam gerade nicht mit ... sei aber hiermit nachgereicht :-=) Grüße, Dieter
>Im abgesenkten Zustand lag die Spitze des Stiftes durch dessen Schwerkraft >auf
dem Papier auf. Mehr steckt nicht dahinter.
Beim guten alten Robotron K6411 Flachbettplotter wird mit einer
Kombination von Lichtschranke/Graukeil die Stiftsenkbewegung überwacht.
Man kann sogar die Stiftauflagekraft für alle Stifte individuell
einstellen.
Steckt doch manchmal allerhand dahinter...
ulf.
Hi, Dieter Schmidt schrieb: > HPGL in Chip > > Freundliches Hallo miteinander … > Frage, hat von euch einer mal ein Hpgl-Interpreter in einem Chip > implementiert oder traut sich das jemand zu? > Was ich meine, „vorne“ HPGL rein, „hinten“ Schrittmotorsteuerung“ raus. > Wenn ja, würde ich mich mit demjenigen gerne näher unterhalten. > > Grüße, > Lucky_Wolf Ja, habe ich schon gemacht... War eine kommerzielle Auftragsentwicklung Auf Basis 8Bit PIC. Wobei der PIC sowohl die Datenübertragung (basis HP-IB / GP-IB) als Controller übernommen hat - als auch die Auswertung der Daten im HPGL Format (rein Ascii) und die Steuerung der Motoren. Wobei an der HPGL Realisierung nun wirklich nichts "weltbewegendes" dran ist. Das ist eher Fleissarbeit als alles andere. Der Großteil der Arbeit damals war die Realisierung als Normkonformes IEE488 mit Einhaltung ALLER Vorgaben (auch den oft ignorierten max20ns Reaktionszeit auf ATN) Was willst du den wissen, bzw. welche Schnittstelle soll der Controller denn haben? GRuß Carsten
Hi Carsten, vielen Dank für die Meldung. Die Frage nach der Schnittstelle ist sicherlich berechtigt. Wenn ich es mir "aussuchen kann", ist eine USB-Schnittstelle sicher "zeitgemäß"... :-) Also, HPGL / PLT (z.B. vom EAGLE) über USB-STick rein, raus, wie schon geschrieben, die Motorsteuerung für x- / y-Achse. Z-Achse reicht "Ein / Aus" Ein paar Eingänge für Sensoren (Endschalter) wären sinnvoll. Ich suche hier Menschen, die Zeit & Lust haben mit mir eine Idee zu realisieren, die ich für mich alleine nicht stemmen kann, weil ich von der Progemmierung zu wenig "drauf habe". Daher meine Bitte, so Interesse besteht, sich mit mir über Mail in Verbindung zu setzen. Hier noch einmal meine Mail-Anschrift: Lucky_wolf@gmx.de Herzlichen Dank!
Hallo Dieter, was soll es denn bei Dir genau werden? Eine autonome Leiterplattenfräse? Da passen aber Deine angepeilten 200g nicht. Hmm... also sprich, was soll es genau werden? :-) Einen Einwand hätte ich bezüglich USB-Stick. Könntest Du Dich mit einem USB-TTL-Wandler anfreunden? Hintergrund: Wenn ein USB-Stick als Datenquelle zum Einsatz kommen soll, dann benötigt der Chip schon relativ viel Hirn um überhaupt mit dem Stick reden zu können. Dazu kommt dann noch die Datei-Hantiererei. Um die entsprechende Datei auswählen zu können brauchst Du ja aber wieder einige Tasten und ein Display. Also ein recht hoher Aufwand bevor auch nur eine HPGL-Zeile den Weg durch den Chip gefunden hat. Vorschlag: Die HPGL-Datei wird per Terminal-Proggi (mit Hardware-Handshake) von einem PC/Schlepptop per USB-TTL-Wandler (FTDI232 o.ä.) dem Chip übergeben. Dies macht die Sache erheblich einfacher. Den Hardware-Handshake würde ich nahelegen, weil der Chip dann nicht das komplette HPGL-File in seinen RAM laden muss (ein 8Bit-µC kommt da je nach Typ sehr schnell an seine Grenzen). Ein paar Tasten sind aber selbst dann noch nötig, um per Hand zu fahren. Wie sieht es mit der Auflösung und der Wiederholgenauhigkeit aus? Falls es im 1/10mm Bereich schwanken darf, dann würde das pure Zählen der bereits zurückgelegten Schritte zur Positionsbestimmung ja reichen. (Ein Schrittmotor kann sich bei zu hohen Geschwindigkeiten oder zu steilen Rampen schnell mal um einige Schritte verhaspeln) Gruss...IG
Nein, keine autonome Leiterplattenfräse.... ein autonomer Laserbelichter für Leiterplatten. OK, nun ist die Katze aus dem Sack ... Grüße an Alle
Hi, jetzt hätte ich den Thread fast vergessen... auch wenn das Projekt interessant klingt, zeitlich sieht es bei mir leider sehr mau aus. Im Moment muss ich schon gut bezahlte (=regulärer Stundensatz) Projekte ablehnen, da ist fürs Hobby keine Zeit. (deshalb wird meine Fräse ja auch seit 4 JAhren nicht fertig ;-) ) Aber mit dem ein oder anderen Tipp helfe ich gerne weiter. Aber BTT: lucky_Wolf schrieb: > Die Frage nach der Schnittstelle ist sicherlich berechtigt. > Wenn ich es mir "aussuchen kann", ist eine USB-Schnittstelle sicher > "zeitgemäß"... :-) > Also, HPGL / PLT (z.B. vom EAGLE) über USB-STick rein, raus, wie schon > geschrieben, die Motorsteuerung für x- / y-Achse. Z-Achse reicht "Ein / > Aus" USB Stick ist wie schon geschrieben schon eine Hausnummer. Eine Verbindung über das USB Kabel mit dem PC ist wesentlich einfacher. Es ist natürlich machbar, gute µC Hersteller haben für Ihre µC da die fertigen LIBs und USB Stacks zur freien VErwendung. Jemand mit ein wenig Programmiererfahrung wird das Dateihandling mit USB Stick sicher auch in akzeptabler Zeit zum laufen bekommen. Der µC wird dann im Ergebniss aber sicher mehr mit dem USB HAndling beschäftigt sein als mit dem Steuern der Motoren. Zudem braucht man wie von IG ja schon geschrieben schon etwsa leistungsfähigere µC. Da ist das Umschauen in der 32Bit Welt schon fast Pflicht. Am ende sind 2/3 der Arbeit dann nur für das User Interface und den USB Host Teil draufgegangen. Zumindest für den Anfang würde ich mich daher auch mit einem reinen USB device starten. Das packt auch ein 8Bitter noch ganz gut. ICh würde das so realisieren das ich den µC als CDC Device ausführe welches sich als COM Schnittstelle am PC anmeldet. Im Anwendungsprogramm kann ich die Daten dann einfach über die (virtuelle) COM Schnittstelle ausgeben, muss mir halt einfach einen Druckertreiber suchen der nichts anderes macht als die Daten 1-1 durchzureichen. Da gibt es aber einige. Wenn ich nicht über einen "herausgesuchten" Druckertreiber die daten ausgeben will, dann kann ich natürlich wie von I.G. vorgeschlagen entweder ein Terminal Programm nehmen oder -vor allem bei einem CDC Device- ich schreibe mir selbst eine kleine Applikation. Falls man keine besonderen Ansprüche hat und die Nutzung von .NET akzeptabel ist, dann braucht selbst ein (C++ .NET geübter) Mittelstufenschüler dafür sicher weniger als einen NAchmittag. Ohne Framework ist das natürlich einige Hausnummer anspruchsvoller... Im µC muss dann nur noch ein simpler Textvergleich und etwas "navigation" ablaufen. Das ist alles keine Hexerei. > Ein paar Eingänge für Sensoren (Endschalter) wären sinnvoll. Das ist absolut kein Problem. Da kann man wählen ob Sobald das Signal des jeweiligen Eingangs abfällt (Ich würde schalter nehmen die bei Berührung AUSSCHALTEN, wg. Kabeldefekte oder schlechte Steckverbindungen) sofort alles halten soll oder aber der Motor nicht weiter in diese Richtung drehen soll. Ingolf Geißler schrieb: > Vorschlag: > Die HPGL-Datei wird per Terminal-Proggi (mit Hardware-Handshake) von > einem PC/Schlepptop per USB-TTL-Wandler (FTDI232 o.ä.) dem Chip > übergeben. > Dies macht die Sache erheblich einfacher. Den Hardware-Handshake würde > ich nahelegen, weil der Chip dann nicht das komplette HPGL-File in > seinen RAM laden muss (ein 8Bit-µC kommt da je nach Typ sehr schnell an > seine Grenzen). Also mit FTDI würde ich mich bei solchen µC Sachen nicht mehr abmühen. Direkt einen passenden USB µC nehmen ist viel komfortabler UND billiger. ICh würde das wohl mit einem PIC realisieren, den gesamten USB Teil bekomme ich ja fertig geliefert und mache das DatenI/O nur noch über wenige Funktionen. (Ichmeine es gibt sechs oder acht für das GESAMTE Handling, von denen man aber meist nur zwei nutzt) Da läuft das mit dem HAndshake schon automatisch. Neue Daten kommen erst wenn ich die alten abgeholt habe. Evtl. währe es ja eine IDEE für so eine Anwendung mit einem etwas vielpinnigeren 8Bit USB µC zu starten, z.B. PIC 18F4550 (gibt es sowohl im DIP40 als auch in kleinen TQFP u.ä.) und die beiden UART Leitungen dieses PICs schon auf einen externen Steckverbinder zu führen und im Programm die möglichkeit vorzusehen das sowohl vom UART als auch von USB die daten kommen können. Wenn das eine dann zuverlässig läuft, dann kann man mit einem 32Bitter und USB Buchse auf einem Aufsteckmodul die Geschichte jederzeit um die Möglichkeit "USB Stick" erweitern. Wobei der eine PIC dann wirklich nur die USB Host geschichte und Dateimanagement macht, während der andere in Ruhe weiter seiner HAuptaufgabe der Steuerung nachgehen kann. Gruß Carsten
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.