Posts by millingpenguin

Hallo Josh,

du hast es selbst gesagt. Der Hersteller kann ja nicht wissen was an der Welle hängt.

Die Angaben auf dem Typenschild sind das was der Motor dauerhaft kann, und zwar an der Welle. Dauerhaft, weil DUTY-CONT, ansonsten heisst das auch S1 Betrieb. Dann steht da noch die Angabe SF 1.15 drauf. SF steht für Service factor, heisst der Motor darf kontinuierlich um den Faktor 1.15, d.h. 15% höher belastet werden, allerdings verringert sich dann die Lebensdauer.

Die Frage ist natürlich wie genau die Anzeige ist. Aber ich sage mal, man kann den Motor mit 1-1.1 A betreiben. D.h. du musst die Drehzahl etwas runter nehmen.

Hallo,

noch eine Möglichkeit wäre Arc Welder zu benutzen. Es ist zwar für 3D Druck gedacht, sollte aber auch funktionieren.

Arc Welder

Arc Welder: Anti-Stutter

Converts G0/G1 commands to G2/G3 commands. This can greatly compress some GCode files and can reduce the number of GCodes sent to your printer when streaming GCode from OctoPrint. This can reduce stuttering as long as your firmware correctly implements G2/G3 (arc) commands and is configured properly.

Ich benutze es unter Linux mit der Kommandozeile für meine 3D-Drucker.
Es ist ein Python Programm, also sollte es auch unter Windows laufen, wenn man sich nicht vor der Kommandozeile scheut :). Die für die einzelnen 3D-Drucker erhältlichen Plugins sind hier ja nicht von Bedeutung.

Danke Alex,

ich vergaß zu erwähnen, als Wine Version hatte ich auch die System Version und das ist 4.0 genommen.

Hallo Daniel,

das ist in der Tat seltsam. Ich habe mir eben das letzte Release 4.1 (nicht die beta) runter geladen und über PlayOnLinux in einem neuen virtuellen Laufwerk, Step für Step nach meiner Anleitung installiert, weil ich die Vermutung hatte, das es was mit einer neueren Installation zu tun hat. Das lief aber bei mir glatt durch und beim Start bekomme ich keine Fehlermeldung.

Installiert habe ich dotnet 4.5 .

Als Distri habe ich Mint 20.1 Cinnamon. Aber das dürfte dann hier keine Rolle spielen.

Welche PlayOnLinux Version hast du? Ich habe die 4.3.4.

Ich habe gerade gesehen er hat Windows 2003 eingestellt, da hatte ich wohl nicht aufgepasst. Läuft aber auch. Umgestellt auf Windows 7 ebenso.

Daniel,

erst mal die Frage, hast du die Installation über PlayOnLinux gemacht?

Hallo Daniel,

da kann ich auch nicht mehr erkennen als Alex. Wenn ich mich aber richtig erinnere, hatte ich eine höhere Version von dotnet genommen als 4.0. Es kann aber auch mit der verwendeten Wine Version zusammen hängen.

Der Wine Experte bin ich nun aber auch nicht. Vieles war Try und Error bis es bei mir lief.

Ich habe 2mm starke PVC Folie genommen, nachdem 4mm doch zu steif war.

Hi,

einen Eintrag im englischen Forum hatte ich gefunden, aber da gab es keine Lösung. Ich werde es auch dort mal posten. Ich vermute es hat was mit meiner Linux Version zu tun und bei den meisten scheint das mitgelieferte Skript auch zu funktionieren.

Ergänzung zu meinem alten Beitrag

Das gleiche Problem bestand bei mir auch mit CamBam 1.0. Auch wenn es dort inzwischen ein Skript gibt, welches in den Installationspfad wechselt und auch eine Umgebungsvariable LD_LIBRARY_PATH zu diesem Verzeichnis setzt, lief das bei mir unter Linux Mint 20.1 nicht. Auch hier wieder die Lösung von Oben.

Ich habe in den Dateien CamBam.CAD.dll.config und CamBam.exe.config jeweils den absoluten Pfad zu libcambam64.so setzen müssen, also

<dllmap dll="libcambam.so" target="/home/albert/CamBam1.0/libcambam64.so"/>

Dann darf aber in dem Shell Skript cambam.sh kein export von LD_LIBRARY_PATH mehr gemacht werden. Das funktionierte dann bei mir immer noch nicht.

D.h. cambam.sh sieht jetzt bei mir so aus

#!/bin/bash

cd ~/CamBam1.0

#the above line switches to CamBam dir

#LD_LIBRARY_PATH="$(pwd)"

#export LD_LIBRARY_PATH

mono ~/CamBam1.0/CamBam.exe

Damit kann ich jetzt Schriften auch in Cambam 1.0 (RC3) benutzen.

Am Tablet funktioniert es

Oh sorry,

in dem Python Skript cam_align.py

Kleines Update

Heute morgen nahm ich das Skript mit der Kamera in Betrieb.

Erstens in dem MDI Befehl von oben zum Anfahren des Nullpunkts ist ein Tippfehler drin.

natürlich muss es heissen MDI_COMMAND=G0 X0 Y0

Dann musste ich noch zwei kleine Änderungen im Python Skript machen. Grund: Ich habe ein XHC_HB04 Handrad und das belegt die MDI Befehle 0 - 17.

D.h. man muss im Skript die beiden Stellen mit CALL_INI_MDI suchen und die 0, bzw. 1 durch in meinem Fall 18 und 19 ersetzen.

ACTION.CALL_INI_MDI(0) -> ACTION.CALL_INI_MDI(18)

ACTION.CALL_INI_MDI(1) -> ACTION.CALL_INI_MDI(19)

Hallo,

ich wollte euch mal ein paar Bilder von meiner frisch installierten Absaugung, bzw. besser gesagt, dem gedruckten Absaugschuh zeigen. Der alte Schuh, aus MPX Platten gefräst, war mir zu groß und ragte zu tief nach unten. Da bin ich auch schon mal an einer Spannpratze hängen geblieben, bzw. konnte auch nie so ganz nah an den Rand fahren. Ziel war es deshalb einen möglichst kompakten und auch möglichst hohen Absaugschuh zu bekommen. Anbei mal ein paar Bilder.

Durch die Klappe kommt man bequem an die Überwurfmutter, um den Fräser zu wechseln, bzw. um den Gegenschlüssel anzusetzen. Die Mutter selbst schaut noch ca. 12mm über den Rand des Plastikrings.

Die beiden grauen Ringe auf der CAD Konstruktion halten mit Magneten am eigentlichen Körper und da sind die PVC Streifen aufgeklebt. Die Idee ist mindestens einen langen und einen kurzen Satz an PVC Streifen zu haben, für unterschiedliche Fräserlängen, was durch die Magnetbefestigung Ruckzuck getauscht ist.

Wo ich mir noch nicht sicher bin (Test steht noch aus), ob die im Moment so halten. Der PVC ist 1mm dick, weil es mich immer genervt hat, dass der dünne den ich vorher hatte immer angesaugt wurde und daher nutzlos war. Jetzt habe ich jedoch 1mm Abstand zwischen den Magneten (zwei sind in jeder Ringhälfte und zwei jeweils gegenüber im Körper). Mal schauen ob das hält, sonst muss ich bei der nächsten Variante beide Magnete weiter rausschauen lassen, so dass sie sich berühren und die Folie an der Stelle ausschneiden.

Die Lamellen habe ich schräg angestellt, damit sie nicht so leicht angesaugt werden. Die Klappe selber hält auch mit zwei Magneten zu und hat einen kleinen Absatz, damit man sie besser öffnen kann.

Die Öffnung in der Mitte ist im Durchmesser 2mm größer als die Welle, damit so wenig wie möglich Staub an die Lager kommt. Zusätzlich gibt es noch den inneren Ring, der die Luft ein wenig führen soll und von der Welle abhalten soll.

Im zweiten Bild kann man eine Rampe zwischen dem Innenring und der Aussenwand erahnen, die zusätzlich die Luft lenken soll, ob es was bringt weiss ich aber nicht.

Meine Spindel hat unten einen Absatz mit 76mm Durchmesser, darauf ist die Absaugung geklemmt und der Durchmesser des Hauptköpers ist 80mm, geht also theoretisch nahtlos in die Spindel über und macht einen schlanken Fuss.

Gedruckt habe ich mit PETG.

Konstruiert wurde mit Freecad. Das hat mich zwar ein paar Stunden gekostet, aber ich durfte viel lernen :).

Hätte mich auch gewundert bei dem Preis. Die zweipoligen kosten > 150Eur.

Hallo Ralf,

in der Tat ist das Thema sehr komplex und mein Satz in #5 stimmt so nicht! Ich streiche ihn durch.

Mein Halbwissen beziehe ich aus der Allstromfibel von Doepke. Dort ist es sehr gut erklärt, auch wie die Fehlerstöme in den einzelnen Szenarien aussehen, aber ich hatte das etwas unglücklich bzw. falsch ausgedrückt, mea culpa.

Ich sehe bei dem was du schreibst und was bei Doepke steht so ziemlich eine Übereinstimmung. Aber ich denke man muss noch einen Punkt von dir etwas differenzieren.

Quote from fraesoholic

Es ist dabei egal ob der Eingangsstrom 3- oder 1-phasig ist. Der Wechselstrom wird auch im einphasigen FU gleichgerichtet bevor dann 3 Phasen daraus emuliert werden.

Die Fehlerströme bei einphasig und dreiphasig betriebenen FUs sehen unterschiedlich aus und die einphasigen müssen nicht unbedingt Gleichströme enthalten, können aber.

Ich zitiere aus Seite 12 von Doepke, Kapitel 1.3.4

Einphasig betriebene Frequenzumrichter
Werden in einer elektrischen Anlage einphasig betriebene Frequenzumrichter verwendet, so ist in der Regel eine Fehlerstromschutzeinrichtung des Typs F ausreichend. Im Fehlerfall tritt je nach Fehlerstelle ein sinusförmiger Wech-
selfehlerstrom oder ein pulsierender Gleichfehlerstrom resultierend aus der Bemessungsfrequenz (50 Hz) auf. Üblicherweise sind weitere Spektralanteile der Ausgangsfrequenz und der Schaltfrequenz mit Oberschwingungen im Fehlerstrom vorhanden. Glatte Gleichfehlerströme können üblicherweise nicht auftreten.

Spezielle Ausführungen von einphasig betriebenen Frequenzumrichtern enthalten im Zwischenkreis jedoch eine PFC-Stufe oder einen Hochsetzsteller, um die Zwischenkreisspannung anzuheben, so dass auch Elektromotoren angeschlossen werden können, die für eine Bemessungsspannung von 400 V ausgelegt sind. Bei solchen Frequenzumrichtern können im Fehlerfall jedoch Fehlerströme auftreten, die einen hohen Gleichanteil haben und von RCDs des Typs A oder F nicht mehr erfasst werden. In diesem Fall dürfen nur RCDs des Typs B oder B+ verwendet werden. Der Hersteller des Frequenzumrichters muss entsprechende Hinweise dazu in seinen Unterlagen geben.

Also ein allgemeiner Rat von mir:

1. Ich gebe dazu keinen Rat.

2. Man sollte die Fachleute befragen, die täglich damit zu tun haben, bevor man was installieren lässt.

Hoi zsamme,

Bruno, du bist der Held des Tages .

Die Sache läuft jetzt. Problem 1, war ein kleiner Tippfehler meinerseits und dann fehlte noch python-opencv.

Also noch einmal zusammen gefasst:

Dies kommt in die ini Datei bei Gmoccapy (für Axis, siehe Link von Bruno oben)

EMBED_TAB_NAME          = Camera
EMBED_TAB_LOCATION      = ntb_preview
EMBED_TAB_COMMAND       = halcmd loadusr -Wn camera qtvcp -c camera -x {XID} cam_align

# for the camera tab
[MDI_COMMAND_LIST]
# X and Y are the offset values from the crosshairs to the torch
MDI_COMMAND = G10 L20 P0 X0 Y0
# origin move
MDI_COMMAND = G0 X0 X0

Dann braucht man noch die angehängte Datei, die im ini Verzeichnis steht, muss aber noch versuchen ob ich sie ins python Verzeichnis spielen kann und in der ini den Pfad angeben, dann ist es aufgeräumter. Die Datei muss noch in cam_align.py umgenannt werden.

QtPyVCP noch installieren nach den Angaben in QtVcp.

Und ich musste noch opencv mit "sudo apt-get install python-opencv" installieren.

Mit dem Skript kann man übrigens nicht nur den Nullpunkt setzen, sondern auch das Koordinatensystem drehen.

Jetzt brauche ich nur noch eine gescheite Kamera, weil bei meiner Endoskop Kamera die Linse total schief steht. Kann jemand was empfehlen?

Danke nochmal, ihr glaubt nicht wieviele Stunden ich schon mit der Konfiguration dieser Sch... Kamera verbracht habe.

Hallo Bruno,

heute Abend habe alles was ich für Camview installiert hatte wieder deinstalliert. Jetzt funktioniert auch tatsächlich wieder die Werkzeuglängenmessung.

Dann habe ich mir das Skript aus deinem Link runtergeladen und die Einstellungen in der ini gemacht wie angegeben. Zudem habe ich noch QtPyVCP nach diesem Angaben installiert QtVcp.

Bislang sehe ich aber noch kein Kamerabild im Tab. Ich muss morgen mal weiter schauen und Linuxcnc aus der Konsole starten, vielleicht sehe ich was.

Wenn die Steuerung einphasig läuft, reicht ein normaler FI. Typ B wird bei dreiphasigen benötigt.

Ignorieren, s.u.

Hallo Bruno,

nein das kenne ich nicht, muss ich nachher ausprobieren. Unter Debian habe ich die Kamera nur wieder mit camview zum Laufen bekommen, da ging es mit dem mplayer nicht, aber mit dem besagten Resultat, dass Gmoccapy einfriert.

Das Video von Talla kenne ich, aber er benutzt Axis und da ist das alles problemlos.