Projekte - Plasmabrenntisch - Teil 1

Die Idee für viele meiner Projekte entsteht beim "Garagenbier" mit meinen Freunden und Bekannten. Irgendwann kam das Thema auf den computergesteuerten Zuschnitt von Stahlblechen mittels mittlerweile im Handel "bezahlbarer" Plasmabrenner - und mir eine Idee.....   Diese Dokumentation behandelt ein komplexes Thema und ist daher umfangreich.....hier der Teil zur Software....

Hier geht es zu Teil 2....

Hier geht es zu Teil 3....

Übersicht

Worum geht's....

Einleitung

Wer kennt noch die alten Flachbett-Stift-Plotter ?!... Bis in die 80er Jahre des letzten Jahrhunderts ( wie das klingt.....) wurden technische Zeichnungen - in kleineren Ingenieurbüros - überwiegend von Hand am Zeichenbrett erstellt - auch ich durfte mich daran noch betätigen.

Mit den ersten CAD-Programmen (ComputerAidedDesign) entstanden dann auch die ersten Ausgabegeräte für die erstellten Zeichnungen - sogenannte Plotter. Die ersten Versionen waren "flache Geräte", auf denen das Papier aufgelegt wurde und über dem Papier führte eine Mechanik einen Stift. Für unterschiedliche Stiftstärken gab es verschiedene Stifte, die sich das Gerät aus einer zentralen Mechanik je nach Bedarf holte.

Als ich in meinen heutigen Beruf startete, gab es zwar bereits die ersten Tintenstrahl-Plotter ( damals zu beeindruckenden Preisen ), aber die alten Flachbettplotter habe ich auch noch kennengelernt.

Heute wird diese Technik noch bei Schneideplotteren (sogenannten Cuttern) z.B. für Stoffe etc. eingesetzt - "googelt" einfach mal....

Ist mir zu kompliziert..... =>.... zurück zur Startseite

Datenbasis

Heutige CAD-Programme arbeiten in der Regel mit einer hinterliegenden Datenbank, in welcher die konstruierten Elemente gespeichert werden. Mittlerweile ist ja auch die 3D-Modellierung die Regel.

Um aber eine Konstruktion dann auf eine 2D-Zeichnung (z.B. für die Baustelle) zu übertragen, werden diese Modelle dann in eine Datei exportiert, welche im Prinzip einzelne "Striche" definiert. Jedes CAD-Programm hat da seine eigenen Formate, oft wird auch das "dxf"-Format genutzt.

Ich habe mich bei meinen Überlegungen für das "historische"  Datenformat HPGL1 entschieden, welches ursprünglich für die o.g. Stiftplatter entwickelt wurde und neben den Daten zu den "Strichen" auch gleich die Arbeitsanweisungen für den Stiftplotter enthält....Und die Datendatei ist "Klartext", sie lässt sich z.B. mit dem Texteditor öffnen.

Viele ältere professionelle CAD-Programme oder Freeware-CAD-Programme können diese Dateien noch erzeugen, es gibt aber auch Umwandlungstools..... 

Wir benötigen eine reine Text-Datei mit Endung  .hpgl oder .hpg   oder   .plt , diese Dateiendungen werden allerdings oft auch für andere Sprach-/Formatversionen genutzt, z.B. HPGL2.  Sie sind dann aber i.d. Regel "gepackt" und lassen sich mit dem Texteditor nicht öffnen bzw. er zeigt dann nur "Blödsinn" an...

Hier mal ein Teilauszug aus einer solchen - brauchbaren - Datei...

...........

SP 1;
PU 200,200;
PD 11680,200;
PD 11680,7800;
PD 200,7800;
PD 200,200;
PU 5940,8400;
PD 5940,7800;
PU 6701,6047;
PD 7629,6047;
PU 6701,2847;
PD 6701,6047;
PU 7630,2847;
PD 6701,2847;

..........

Diese Informationen kommen irgendwann nach einem "Einleitungs-Datensatz" mit den speziellen Definitionen zu Stiften,Papiergrösse etc. Wir sehen die x-y-Koordinaten und die Anweisungen PU (PenUp = Stift hochheben) und PD (PenDown = Stift absenken). SP (SelectPen - Stift auswählen) ist für uns aber z.B. unrelevant...

In unsererem Steuerungsprogramm wird dann später entsprechend der Brennkopf an- oder ausgeschaltet werden, diese Arbeit der Umsetzung unserer Zeichnung in Steuerbefehle macht also der Exportfilter zur HPGL1-Datei bereits für uns.

Allerdings sind für eine Nutzung dieser Daten noch einige vorbereitende Arbeitsschritte notwendig, bei mir erfolgt dies in mehreren Teilprogrammen ( die nach und nach entstanden sind ). Ich habe sie (aus Faulheit) nie in einem Gesamtprogramm vereinigt..... Und sobald sie - für meine damaligen Ansprüche in der Entwicklungsphase des Projektes - erst mal halbwegs funktionierten - auch nicht abschliessend zur "Serienreife" weiterentwickelt.....

Ist mir zu kompliziert..... =>.... zurück zur Startseite

Datenaufbereitung Teil 1

Zuerst benötigen wir unsere Daten im oben dargestellten Format - manche Programme lassen beim Export aber z.B. den Zeilenumbruch weg, dann müssen wir die Datei erst mal umformatieren...

Dies könnt Ihr z.B. durch ein anderes geeignetes CAD-Programm machen lassen, eventuell auch die Datei z.B. in einer Tabellenkalkulation importieren und formatiert exportieren.... Bei kleineren Dateien hilft auch der Texteditor....

Ich hatte mir damals ein kleines Lazarus-Hilfsprogramm geschrieben, welches die Arbeit für mich erledigte.  ( das ist dann aber immer von Eurem Dateiformat abhängig - Ihr müsst also die "Textbearbeitungs-Routinen" an Euer Format anpassen - als "Grundgerüst" ist die Programmierung aber ggf. brauchbar)

hier die Larzarus-Datei zum Download...

Die beigefügte zip-Datei mit der Lazarus-Programmierung ist aktuell im Windows-Dateiformat und wurde auf MS WIN programmiert...

ACHTUNG: Die Programmierung ist ein Arbeitsstand, sie funktioniert grundlegend ist aber nicht gegen Fehlbedienung etc. abgesichert. Aber Ihr könnt ein "hängendes Programm" in der Lazarus-Oberfläche jederzeit mit "Halt" abbrechen...

ACHTUNG: In der Programmierung ist auch eine - aktuell deaktivierte - Ansteuerung für die Umwandlung von pdf-Dateien zu hpgl-Dateien mit dem Programm -pstoedit- von Wolfgang Glunz  enthalten. Leider funktioniert dieses Modul bei mir unter MS WIN aktuell nicht  (Probleme mit dem benötigten ghostscript-Modul gswin32c.exe), damit muss ich mich gelegentlich noch mal befassen- z.Zt. nutze ich die Linux-Version. 

Ist mir zu kompliziert..... =>.... zurück zur Startseite

Datenaufbereitung Teil 2

Wenn wir uns die aktuelle Datei mal im Texteditor ansehen, sehen wir das häufig eigentlich optisch zusammenhängende "Strich-Linien" in einzelne Teilbereiche aufgeteilt sind, welche auch nicht unbedingt in aufeinander abfolgender Reihe ausgegeben wurden.

Dies ist dem "Stift-Plotter" halbwegs egal - er setzt dann mehrfach an der gleichen Stelle an und zeichnet zwischendurch halt woanders weiter - für den Plasmabrenner würde es aber jedesmal eine neue "Zündung" des Plasmabogens (und damit auch hohen Verschleiss) bedeuten. Auch sind "Einbrand-Stellen" immer hässliche Stellen am Werkstück.

Wir müssen diese "Teil-Abschnitte" also zu einer möglichst durchgehenden Linienfolge zusammenfassen, damit unser Brennkopf dann nur am Anfang und am Ende angesteuert werden muss. Zusätzlich müssen ggf. auch Teilelemente aus unserer Zeichnung / HPGL-Datei entfernt werden, welche nicht "gebrannt" werden sollen.

Und gelegentlich wurden auch mehrere - ggf. unterschiedlich lange - Teillinien überdeckend ausgegeben, dies muss ebenfalls aufbereitet werden (manchmal geht es aber leider dann nur im CAD-Programm selbst).

Auch hier habe ich mir ein kleines Lazarus-Hilfsprogramm geschrieben...

Es lassen sich einzelne Teilelemente in der Gesamtzeichnung/-datei auswählen und entweder deaktivieren ( z.B. störende Elemente) bzw. separiert exportieren...

und darausfolgend die aufbereitete Teile-Datei....

hier die Larzarus-Datei zum Download...

Die beigefügte zip-Datei mit der Lazarus-Programmierung ist aktuell im Windows-Dateiformat und wurde auf MS WIN programmiert...

ACHTUNG: Die Programmierung ist ein Arbeitsstand, sie funktioniert grundlegend ist aber nicht gegen Fehlbedienung etc. abgesichert. Aber Ihr könnt ein "hängendes Programm" in der Lazarus-Oberfläche jederzeit mit "Halt" abbrechen...

Ist mir zu kompliziert..... =>.... zurück zur Startseite

Datenaufbereitung Teil 3

Nachdem wir nun unser gezeichnetes Werkstück als Datei vorliegen haben, müssen wir eine Steuerdatei für den Brenntisch erzeugen. Momentan würde sich der Brenner genau auf der Werkstück-Kante bewegen, da er aber immer etwas Material "herausbrennt", wären unsere Abmessungen dann falsch.

Also muss die "Fahrlinie" des Brenners immer etwas versetzt zur Werkstück-Kante verlaufen, dabei muss auch noch die Lage der Fahrlinie ( bei Aussenkanten immer ausserhalb der Werkstückfläche/-linienkante, bei Öffnungen entsprechend dann nach innen versetzt) definiert werden. Die Definition des Versatzes zur Bauteilkante ist muss iterativ (am Brenner testen) erfolgen. Der Rest ist dann "Vektorberechnung" - kennen wir doch noch aus der Schule ....ODER ??!!.

Desweiteren kann die Abfolge der  Bearbeitung der einzelnen Brenn-Polygone verändert werden, damit der Brennkopf möglichst nicht über bereits gebrannte Bereiche fahren muss oder um z.B. unnötige Leer-Fahrwege aufgrund einer ungünstigen Abfolge der einzelnen Brenn-Polygone zu vermeiden.

Auch dafür habe ich mir ein kleines Lazarus-Hilfsprogramm geschrieben...

hier die Larzarus-Datei zum Download...

Die beigefügte zip-Datei mit der Lazarus-Programmierung ist aktuell im Windows-Dateiformat und wurde auf MS WIN programmiert...

ACHTUNG: Die Programmierung ist ein Arbeitsstand, sie funktioniert grundlegend ist aber nicht gegen Fehlbedienung etc. abgesichert. Aber Ihr könnt ein "hängendes Programm" in der Lazarus-Oberfläche jederzeit mit "Halt" abbrechen...

ACHTUNG: Die Funktion "Einsprung festlegen" ist noch nicht durchgängig programmiert, da bin ich noch nicht zu gekommen...

Ist mir zu kompliziert..... =>.... zurück zur Startseite

Das Brenn-Programm

Habt Ihr bisher durchgehalten ? Jetzt kommt die eigentliche Ansteuerung unseres Brenntisches...

Dieses Programm läuft auf unserem RasPi mit Raspian als Betriebssystem. Es verwendet diverse - Linux-spezifische Routinen - und kann also auch NUR AUF DEM RasPi ausgeführt werden !!!

Programm-Oberfläche Startbildschirm....

Auf dem Brennertisch wird das "Blech" in Rot angezeigt ( dessen Abmessungen sind in den Einstellungen definiert), darauf dann unser "Werkstück" und eine automatische Anordnungshilfe für die Positionierung auf dem "Blech" ( z.B. falls mehrere Brennvorgänge gewünscht sind).  Mit den Pfeiltasten kann das Werkstück bewegt werden.

Die Schrittmotoren sind i.d. Regel automatisch mit Strom versorgt (gesperrt) und können z.B. für Justierungen oder die Entnahme des Werkstücks entsperrt werden.

Wenn der Brennvorgang nur simuliert wird, wird zwar der Brennkopf bewegt, aber der Brenner nicht eingeschaltet (für Testzwecke).

Im oberen Teil befinden sich die System-Einstellungen wie die Ansteuerungs-Pin's auf dem RasPi für die Motoren, die vom verwendeten Zahnstangen-Antrieb abhängigen Werte (Anzahl Step's pro 1m ) und weitere Einstellungen.  Diese Werte werden iterativ ermittelt und dann i.d. Regel nicht mehr verändert. (im Programm selbst sind bereits Variablen für einen vierten Motor vordefiniert, dieser soll später den Brennkopf vertikal ansteuern).

Im mittleren Teil sind die Materialdaten (auch diese müssen iterativ ermittelt werden) abgelegt, desweiteren die Abmessungen des aktuell auf dem Brenntisch liegenden "Bleches".

Für diverse Funktionstests der Hardware sind zusätzlich noch einige Optionen vorgesehen..

Da eine Ansteuerung über WLAN und VNC-Viewer aufgrund der elektromagnetischen Störungen während des Brennvorganges zu Problemen führten, wird die Nutzeroberfläche auf einem Touch-Screen angezeigt und ist entsprechend dafür in der Grösse ausgelegt.  Für die Eingabe von Werten (Zahlen/Texte) habe ich mir einige Prozeduren geschrieben, welche von Hand bzw. mit der Maus bedient werden können.

Das Fenster "poppt auf", wenn ein Eingabefeld ausgewählt wird... 

Um dieses Programm nachzuvollziehen, benötigt Ihr einen RasPi mit Linux (Raspian oder eine aktuellere Variante) und installiertem Lazarus, da die beigefügte zip-Datei mit der Lazarus-Programmierung aktuell im Windows-Dateiformat ist, müsst Ihr sie dann mit "WinSCP" oder einem ähnlichem Programm auf den RasPi übertragen.

ACHTUNG: Die Programmierung ist ein Arbeitsstand, sie funktioniert grundlegend ist aber nicht gegen Fehlbedienung etc. abgesichert. Aber Ihr könnt ein "hängendes Programm" in der Lazarus-Oberfläche jederzeit mit "Halt" abbrechen...

hier die Lazarus-Dateien zum Download...

Das Projekt ist inklusive aller Dateien komplett, ich habe die Programmschritte hoffentlich ausreichend kommentiert. Ihr benötigt aber noch das Modul wiringPi.

Im Archiv sind neben den "üblichen" Lazarus-Projektdateien auch eine LINUX-Batch-Datei (*.sh) für das automatische Herunterfahren des RasPi, da bei Betrieb mit dem TouchScreen nach Programmende ja keine Tastatur zur Verfügung steht....

Ich habe das Programm auf automatischen Start beim Einschalten des RasPi eingerichtet, wie das geht müsst Ihr mal im Web suchen (ist nicht kompliziert)...

Ist mir zu kompliziert..... =>.... zurück zur Startseite

technische Hinweise

Unsere Steuerdatei enthält Datensätze je "Teil-Strichelement" mit Koordinatenangaben auf einem virtuellen x-y-Achsensystem  wie z.B.  x1/y1  => x2/y2 (Kreisbahnen setzen sich aus vielen kleinen Teilstrecken zusammen).

Unsere Motoren werden aber in Einzelschritten angesteuert - sprich z.B. 100 Schritte für 1cm Strecke auf dem "Blech". Solange x1 = x2  oder y1 = y2 ist, können wir den betroffenen Motor (bzw. die Motoren für den Antrieb der "Brücke" - ich rede nachfolgend auch hier von einem Motor...je Achse ) auf der jeweiligen Achse direkt ansteuern.

Haben wir aber im Grundriss eine "schiefe Strecke", müssen beide Motoren eigentlich gleichzeitig angesteuert werden, unserer RasPi / unser Programm kann aber immer nur eine Befehlsfolge abarbeiten - steuere Motor1 => steuere Motor2 => steuere Motor1 => etc...

Also müssen wir die "schiefe Strecke"  in abwechselnde Befehlfolgen für die beiden Motoren zerlegen - in Abhängigkeit vom "Anstieg" - hier kommt wieder unsere Vektorberechnung (aus der Schule..) zum Einsatz.

Sprich - wir "rastern" unsere gerade Linie in einen Anteil auf der x-Achse und einen Anteil auf der y-Achse (bei 45 Grad wäre der x-y-Anteil gleich).  Ansonsten müssen wir halt z.B. 3 Schritte auf der x-Achse und 1 Schritt auf der y-Achse machen.

In Verbindung mit einer ausreichend "hohen Auflösung" (sprich Anzahl Schritte pro Entfernung) und der Geschwindigkeit der Abarbeitung der Befehle durch die Bewegung des Brennkopfes erzielen wir dann eine optisch "gerade" Linie auf dem Blech, obwohl es real immer kleine Sprünge auf der x- / auf der y-Achse sind.

Dieser Berechnungsaufwand kann aber für unseren RasPi  ( wir nutzen ja einen 3b+ und keinen Gross-Rechner) dann zeitlich ein Problem werden. Möglicherweise (sehr wahrscheinlich) würde er es ggf. nicht schaffen, immer die aktuelle Anzahl an x- /y-Befehlen auszurechnen und dann auch noch die Motoren - in einer vernünftigen Geschwindigkeit während des Brennvorganges - anzusteuern.

Daher erfolgt diese Berechnung vorab und wir erzeugen eine temporäre Steuerdatei "Brenner.dat" welche nur die direkten Befehle enthält.....hier mal ein Auszug....

...........
M23_Step  1         
M1_Step   1         
M23_Step  1         
M23_Step  1         
M1_Step   1         
M23_Step  1         
M23_Step  1         
M23_Step  1         
M1_Step   1         
M23_Step  1         
...........

(M1 ist der Motor auf der "Brücke" und M23 sind die beiden Motoren, welche die Brücke bewegen....)

Diese Datei arbeitet unser RasPi dann einfach Schritt für Schritt ab und muss nicht während des eigentlichen Brennvorganges aufwändig rechnen...

Ist mir zu kompliziert..... =>.... zurück zur Startseite