G-Code visualisieren vb

  • VB6

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    G-Code visualisieren vb

    Hallo,
    Ich habe mir mit vb eine kleine Anwendung gebastelt.
    Die Anwendung generiert aus eingegbenen Schriftzeichen (TextBox) G-Codes zur Ansteuerung einer Schrittmotorkarte.
    Schrifthöhen, Breiten und Positionierung funktioniert auch alles ganz ordentlich, aber ich bin mit meiner "Visualisierung" nicht zufrieden.
    Ich habe vor einiger Zeit mal mit "DrawLine" und "PictureBox" versucht, habe aber das gefühl, dass es sicher eine bessere Methode geben müsste.
    Vor allem da die Schriftzeichen wie z.B. Arial "Bögen" haben...


    G-Code Beispiel:
    G00 X10 Y20 z.B.: Verfährt in einer Linie von 0;0 nach 10;20
    G01 X20 Y40 z.B.: Verfährt in einer Linie von 10;20 nach 20;40
    Bis hierher kein Problem ausser, dass die Picturbox links oben Ihre Referenz hat (X0;Y0) und meine Mechanik links unten.
    Jetzt kommen die schwierigkeiten:
    G02 X50 Y30 R20 z.B.: Verfährt in einem Bogen von 20;40 nach 50;30 mit einem Radius von 20
    G01 X-50 Y-30 Verfährt in einer Linie in negativen Bereich


    Nachdem ich jetzt Tagelang im Netz gesucht habe möchte hier die Frage stellen: Hat jemand einen Tipp für mich???
    Kann der Referenzpunkt von der PictureBox (0;0) von oben links nach unten links geändert werden???

    Danke!
    Willkommen im Forum. :thumbup:

    HotDot schrieb:

    Kann der Referenzpunkt von der PictureBox (0;0) von oben links nach unten links geändert werden???
    Wenn Dir die Höhe bekannt ist, subtrahiere bei allen y-Werten diesen von der Höhe und feddich:
    yNeu = Höhe - yAlt.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Hallo Rod,

    Danke für deine Antwort!
    Ich habe im Februar erst mit dem Programmieren angefangen.
    Ich habe viele nützliche Infos bei euch gefunden!
    So ungefähr habe ist es heute auch gelöst.
    Ich habe in der Nutzeroberfläche Label's die annähernd die realität simulieren.
    Diese können mittels "Drag&Drop" und "Teach +/-" verschoben werden und die Maschine folgt den Koordinaten um den "Startpunkt" anzuzeigen.
    Da aber sämtliche Parameter veränderbar sind, habe ich mittlerweile angst vor jeder neuen Zeile und frage mich ob Sie sein muss.
    Zusätzlich habe ich noch DataMatrixCodes(ECC200) bei denen ich in der PictureBox die Farbwerte auslese (zumindes den R-Wert) um daraus die verfahrbefehle zu generieren.
    Zusätzlich generiert die Anwendung Tag, Datum, Schichten fortlaufende Seriennummern usw.
    (Vieleicht muss ich nur besser Dokumentieren, aber ich habe manchmal die Befürchtung das es irgendwann nicht mehr läuft).
    Deshalb suche ich nach anderen Lösungen um die möglichen Fehlerquellen zu umgehen. Das Ding ist echt komplex.
    Ich setze mittlerweile jede Änderung in "'==== geändert am " Begrenzungen damit ich falls beim Testen etwas durchflutscht damit ich es überhaupt wiederfinden kann.
    Ich wollte nächste Woche erweitern von 3 auf 6 Zeilen damit würde ich die probleme fast verdoppeln.
    Gibt es eigentlich Empfehlungen wie lang oder wie viele Operationen ein einzelnder Sub oder Functions sein sollten? (Ich meinte maximal haben sollte)?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „HotDot“ ()

    Bzgl. der Kurven läuft es wahrscheinlich mit DrawArc. Allerdings glaub ich, dass Du da n bisken rumrechnen musst, um aus Deinen Start-Ziel-Koordinaten den passenden Kreis für DrawArc rausrechnen zu können.

    HotDot schrieb:

    Gibt es eigentlich Empfehlungen wie lang oder wie viele Operationen ein einzelnder Sub oder Functions sein sollten?

    joa: Soviel, wie eine Methode braucht, um den einen Zweck zu erfüllen, für den sie geschaffen wurde. Am besten (Achtung, on the way to idealism) unter Einhaltung von SLA und SRP => Die Methode sollte nur eine einzige Aufgabe haben, die sie erfüllt, welche nicht mehr in sinnvolle (!) Einzelprobleme aufgeteilt werden kann => Sie sollte weder eine "Ich mach alles"-Aufgabe haben noch eine der "Ich geb nur nen Wert zurück, damit ich ja nicht zuviele Zeilen hab." Letzteres passiert aber eigentlich nur, wenn man es mit den beiden genannten Prinzipien übertreibt. Und das geschieht in der ersten Programmierzeit so gut wie nie.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Hallo, da hatte ich schon "Rumgewurschtelt" und mir ein schönes "Spaghettimonster" gebastelt.
    Ich glaube ich trinke noch ne kühle Gerstenschorle... Vieleicht wäre es doch besser die Konturen "Vektor Basiert" zu machen.
    Leider sieht man die Übergänge, wenn die Mechanik schnell genug sein soll. Bei G-Code werden die Verfahrbewegungen perfekt interpoliert.
    Ich habe auch einige Software gesehen, bei der G-Code Verfahrwege visualisiert waren.
    Aber wenn ich genau darüber nachdenke waren die Schnittpunkte der einzelnden Liniensegmente teilweise zu lang und haben sich überschnitten.
    Dies könnte ein Indiez dafür sein, dass mit DrawArc gearbeitet worden ist.
    Ich werde mir mal die DLL von eiener guten open s. version ansehen.
    Vieleicht bringt mich die suche nach der DLL in die richtige Richtung.

    Zu dem Thema Methode, für einen Zeichensatz z.B. Arial habe ich 65 Schriftzeichen mit jeweils ca.30 unterschiedlichen variablen die gegen Zahlenwerte aus einer anderen Sub getauscht oder abgerufen werden. Diese werden zuvor aus der eingegebenen Schrifthöhe berechnet.
    Ich habe das ganze in verschiedene Stufen aufgeteilt, da ich die ganzen string am ende über RS232 (Seriell) an die Motorkarte senden muss.
    Die gegenseite hat nur einen sehr kleinen (156k) "Planner Buffer",senden geht also nur "Häppchenweise" sonst overflow.
    Zu dem kommuniziere ich zeitgleich noch über TCP mit einem Server, der den Zustand der ganzen Anwendung überwacht.

    Werde ich wohl noch ne Weile rumsinieren...
    @HotDot Zunächst arbeiten wir, ohne auch nur eine einzige Zeile Code zu schreiben :!: :!: :!:
    Fang an mit einer ultrapräzisen Aufgabenbeschreibung.
    Zerlege diese in Elementarbefehle, wie @VaporiZed schreibt.
    Jeden dieser einzelnen Elementarbefehle kannst Du dann einzeln implementieren, ohne die anderen anfassen zu müssen. 8o
    Mach Dir ein Testprogramm und dort für jeden Elementarbefehl einen oder mehrere Tests, die Du immer wieder ablaufen lässt, um Dich davon zu überzeugen, dass neuere Programmteile die älteren fertigen nicht beeinflussen :!:
    Dokumentiere Deinen Code präzise. Es ist nicht wichtig, wann Du eine Änderung gemacht hast, sondern warum.
    Wenn Du in einem halben oder ganzen Jahr wieder in den Code hineinsiehst, sollst Du sofort wissen, warum der Code so aussieht und nicht anders.
    Speichere den Code in einem Quellcodeverwaltungssystem, da kannst Du Änderungen nachverfolgen und rückgängig machen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!