Advanced Search

Moin,

ich bin der Meinung, dass es nichts mit linuxcnc zu tun hat, sondern mit
fusion 360..?
Karlhe

Ich habe das Programm in fusion 360 mit dem Prozessor von estlcam rechnen lassen. der fährt die kontur ohne radius, dass hat 
funktioniert. Der Postprozesseor von linuxcnc sollte beim abfahren von Konturen vielleicht doch noch überarbeitet werden.

The Linux CNC FPGA control board I bought connects to the motor driver, and it works perfectly with the 74HC245.

There is no problem connecting the DM542 using the 74HC245.
 

The FPGA (3.3V) is directly connected to the 74HC245 (5V).
 

it's the data received by the controller from drives

Is the DH parameters below right?
 
 

Any LinuxCNC users that have an opinion of PureCutCNC?
I'm not involved but it look kind if nice.
purecutcnc.github.io/

Press the "home all" button, then issue MDI.

Tut mir Leid für die Falsche Fährte.

Ich habe das Problem nicht reproduzieren können in meinen Testconfigs. dürfte ich deine INI sehen um die zu vergleichen? 

mfg

managed to fix this by completely rebuilding the config, no idea what was causing it

    Danke, ich füge das nc programm hinzu.

ich habe das programm mit nc viewer laufen lassen, keine Fehler


Karlhe

viewsat wrote:

PCW wrote:

If this is a drive level issue, note that a 26C31 does not swing to 5V
and its output level is about 2 diode drops below 5V (3.6V) with a 5 mA load.
I connected the motor driver using +5V and A-.
 

 

Yes, connected that way you would get close to 5V drive.

The issue with the 26C31 is that the high level drive does not swing to 5V
but the low level drive does swing close to 0V.

 

G91.1 ist eigentlich standard für I,J,k , ausgehend vom Kreismittelpunkt. Diese parameter werden ässerst selten als absolutwert angewendet.
Das Problem mit Fusion360 und Kreisendpunktfehler taucht seit langer Zeit immer wieder auf. Vielleicht ist da was mit Nachkommastellen, 3 für metrisch und sonst 4

Einige Ideen bringt auch die websuche:

fusion360 linuxcnc end of arc differ
 

Can you tell me what encoder model you were pulling the data from? I know the resolution between the different generations can vary greatly. I think the latest generation claims about 10 million PPR.

Thanks

deleted

Das sieht nach einem Programmierproblem aus. Ist der Radiusmittelpunkt Absolut oder relativ? ich sehe in deinem Programmkopf G91.1 (relativ). Wechsle dies mal auf G90.1 und versuch es nochmal.
PS: Das Programm im Anhang würde helfen

It has a single MPG wheel mounted on the door/control. I might re-use it, but since most of the rest of the existing controls are going away (many worn out keys), I think a detachable pendant with some buttons might be nice for setting up longer work.

More importantly for anyone interested, I think I was wrong on the encoder/commutation stuff. After further investigation, it seems ABZ encoder outputs are available from the VCU and I don't need to worry about commutation, although there is a different wrinkle that's escaping me right now.

A couple of days after I posted about this, I got commandeered to look at a similar vintage milling machine for a repair, or similar refit. A week into that, I had to move on to a more urgent broken production tool. It's been fun. I'll update the thread with my lathe progress, success or failure when I get back to it, but it could be a while.

Having been using chat-bot assistance, I'm mindful that much of it's info on the topic is scraped and recombined from these very forums, so it's important to give back real accurate information about a project's actual viability and methodology when I can.