Advanced Search

Definitely check the torque curve on whatever motor you want to use, DMM or otherwise. Also: inertia mismatch between the spindle and motor is a thing. I think I ran into that when I initially tried to use a smaller motor, but hard to tell amongst my other tuning issues.

I've got the 1 KW 86mm motor (86M-DHT-A6MK1) on my baby BT30 machine (~14x8x10 XYZ travels and ~500 lbs, IIRC). It's geared ~1:1.5 (motor:spindle), so I can go up to ~7500 RPM at the spindle. After finally getting the tuning right (see below), I'm still finding where the limits actually are, but:

Aluminum: Have gone up to ~3 cubic inches/minute, with 1/4" and 3/8" tools. Haven't had issues.

Mild steel: No issues. I don't remember hard numbers for anything aside from drilling a couple holes in 1018 steel with a 6mm carbide drill. 5000 RPM, ~20 IPM, no problem.

Stainless: I've cut 304 and 17-4 H925. Both cut without issue. I don't remember MRRs for either.

Hardened steel: I modified a screwless vise body, which is probably ~60HRC. Mix of 1/4 and 3/8 tools IIRC, cut fine, albeit with light cuts.

All of the cutting I've done has been within the motor's "continuous" operation power range, per HSMAdvisor (well worth the price, IMO). Just about all of my non-finishing operations are HSM toolpaths, so I can't really comment on slotting.

This may also be of interest for tuning a DMM DYN4: www.forum.linuxcnc.org/38-general-linuxc...dle-servo-tuning-tip

I've recently cloned and built the linuxCNC live builder and created and installed a couple of ISO's without drama. If there are issues with Grub, I suspect I will be due to uefi/secure boot. This is outside of control in our ISO as its pure Debian! But then again Debian 13 has good uefi support.Try and disable it in your BIOS.

The only other issue I had was not finding a couple of obsolete firmware modules sometimes which broke the build process.
firmware-b43-installer
firmware-b43legacy-installer

Apparently, these are a wrapper around a download from flakey servers that have a history of failing. This broke the build process. I just deleted them. There are a number of other very old and probably obsolete Debian non-standard firmware drivers that seem to have been carried over from old builds which I suspect could also be removed.

Hi, I just called DMM and asked them about using the DST 1.8kv servo to do the same thing with my PM833 mill and they advised that running the motor continuously at 3000 rpm would put it outside it's peak torque range and reduce the torque by the drive ratio.

I wanted to do the same as what you have done and reach 5000-6000 rpm with potential for rigid tapping. My current 2hp motor is spun to 7000+ rpm and reduced by around 2.3:1 pulleys and leaves me with 3200 rpm max.

How has this servo motor worked out for you? Have you been able to take good size cuts with a 3/8" end mill in aluminum and have you machined steel with it?

I had also considered changing my pulleys closer to a 1:1 ratio, but the fan and motor noise are insane. A different fan could be an option and an encoder could be used.

My machine is similar in size to a tormach 1100, so I don't know how that compares to what you are working with.

Any advice or updates would be appreciated as I have only heard of a few people doing what you have done.

BTW2:
If you want do do helix milling, I created a macro. See It is called like that:

o<boring> call [-10.0] [4.0] [10.0] [1.0] [1000.0] [3000.0]

The center of the helix starts at [0 0 0]. To shift it, I was using a second coordinate system like that:

Probably there are better ways doing this, I'm also just starting writing G-Code. For example you could pass the starting location as a parameter or use variables to create the new coordinate system.

BTW: Not having a absolute move before a relative move is probably not anything a CAM software would ever do, but it's also not illegal.
However, a "normal" preview tool not knowing where you machine is could not show you anything in that case.

I just quickly tested it. That's a bug in gmoccapy. In axis, it works.

In axis, you have to reload the gcode after each other move, so the initial position of the circle is updated.

G2's I and J parameters are relative to the last position:
linuxcnc.org/docs/html/gcode/g-code.html#gcode:g2-g3

Now if you don't have a G0 or G1 command before, the preview in gmoccapy looks funny. I think the preview interpreter is not initialized with the actual position in the UI. The real machine interpreter has no issues afterwards.

For the first command, X,Y and Z has to be specified to work. G0 X0 Y0 is not enough, G0 X0 Y0 Z0 does the trick.

I suggest writing a bug report.

No, I did not really start a rewrite. I made a small program to communicate with the pendant, but it was more for troubleshooting than planned as the start of a new component. But I did make a new firmware for the dongle, which I have been using without issues so far.

Maybe it was not completely fair to compare it to the xhc-hb04 component. Anyway, I'm glad somebody made this component in the first place, and of course all your bugfixes and improvements are a clear step in the right direction.

I experienced an issue with arc preview just a few weeks ago that I made a post about. I think this may be a bug or limitation in the preview only rather than connected to the issue you mention. But I thought I might as well mention it, since it has some similarities to the issue you mention.
forum.linuxcnc.org/20-g-code/58285-stran...r-circular-arc-g2-g3

Many thanks for confirming than I’m not going mad.
The really strange part is the previous iso of LinuxCNC (2.9.7) is also based on debian13 and that installed without any grub issues and no internet access was available
However when trying to update 2.9.7 to 2.9.8 I hit loads of problems with broken packages

I’m in the process of moving all of my CNC machines from parallel ports to mesa cards and have taken the opportunity to update to the latest version and also update the PC’s from circa 2010 hardware to much newer intel NUC’s
As such I’ve installed linuxCNC 2.9.8 on three NUC’s over the last few days and allowed the graphic install to have access to my mobile phones internet connections via the NUC’s built in WiFi card. All three install have gone through perfectly

tiagounderground wrote:

probably is the time to the drivers to reach the op state. in my machine i lock the enable button with the op state from the servos
 

Thanks.
The problem was more complex, but you drived me to good way.
I found that the lines in my hal file like <net x-modes-of-operation  cia402.0.opmode => lcec.0.X.opmode> not always works, and sometimes op state never changes to "operational".
Fortunatelly I never use other opmodes than 8, and I can set these permanently.
I added to my halfile code as bellow, and it seems work properly.(It is ability to use more inputs in the logic hal component.)
 

grandixximo wrote:

Atsu wrote:

I could share my experience with this issue. Attached is a link to a video showing how the jitter sounds on StepperOnline A6 servos. This is exaggerated by disabling the synchronization. Once synchronization is enabled (syncToRefClock="true" or refClockSyncCycles="-1"), it still happens but much more rarely, just like grandixximo explained at the start of this post. Last week, I upgraded to the latest version of linuxcnc-ethercat, and am currently testing how the changes committed at the end of 2025 affect my machine configuration.

​​​https://imgur.com/a/FXSuvOS
 
Thank you for the independent testing, if you want a better version

github.com/linuxcnc-ethercat/linuxcnc-et...84ef36b53f0b734eaedf

this I have tested and works well, unfortunately Scott has not been around to merge it, so it is not in the main linuxcnc-ethercat repo yet, but it is a better version

Great, thanks! I'll switch to that version and continue testing.

After activation of PLL there shouldn't be any random clicks anymore.
Check dmesg if you get any errors there, it can be the network adapter too.

In my case, activation of PLL fixed the issue almost entirely, but the random clunk noises still occur every once in a while, just not nearly as often. After updating to the latest version from the linuxcnc-ethercat repo, I haven't had it occur during motion anymore, which is a good sign. However, I haven't run the machine much yet, so more testing is needed. I will also check the dmesg you pointed out.

Yes, too old. Use a negative number to refClockSyncCycles. That's equivalent to the syncToRefClock="true".

I have had the same issue today installing LinuxCNC 2.9.8 onto an OptiPlex 990. I don't have a network and skipped the network config, so my experience matches yours.


There must be something going on with Debian these days because I ran into a similar issue last month installing the latest version of base Debian on a brand new server. Ryzen 9 and 64GB of RAM. I was doing a non-graphical installation without a network connection, and the installation failed every time. It was a (near?) bare minimal installation that didn't include a GUI. There was some package like PostgreSQL or a DBMS portion of some SQL server that failed and killed the package installation process. I gave up and plugged an Ethernet cable into a dummy network, restarted the installation, went through the network portion, and everything worked. This is bad practice on their QA side to allow things like this to happen.

I cannot activate syncToRefClock="true". I get ‘invalid master attribute’. My EtherCAT version 1.6.8.g2543cc5-1+27.2 is probably too old, even though I installed it last autumn.

Ganz so schlimm ist es nicht ?

Ein Haus drehe ich damit nicht – aber es geht um eine Achse, auf der im Worst Case bis zu 11,5 t Achslast stehen können.
Wenn sauber verteilt wären es 5,75 t pro Rad, aber da die Lastverteilung nicht immer ideal ist, rechne ich konservativ mit ~7 t.

Der Motor selbst hat 51 Nm Nennmoment, dahinter sitzt ein 140:1 Getriebe.
Rein rechnerisch komme ich damit natürlich auf sehr hohe Haltemomente – aber das bedeutet nicht, dass ich permanent 7000 Nm fahre.

Ich habe bewusst eher „zu groß“ dimensioniert, weil:

* hohe Massenträgheit wirkt auf Motor und Getriebe
* Lastverteilung nicht konstant ist
* reproduzierbare Positionierung im mm-Bereich erforderlich ist
* Bewegung in beide Richtungen notwendig ist
* Sicherheitsreserve einkalkuliert wurde

Sollte sich im Prototyp später zeigen, dass deutlich Reserve vorhanden ist (über reale Drehmomentmessung), würde ich das System in einer späteren Ausbaustufe kleiner dimensionieren.

Was mich aktuell technisch mehr beschäftigt, ist der Drive selbst.

Wenn ich nach Servodrives schaue, finde ich fast nie eine explizite Drehzahlbegrenzung im Datenblatt.
4500 rpm sind bei mir die rechnerische Obergrenze, real erwarte ich eher 2200–3000 rpm.

Woran erkenne ich eigentlich, ob ein Drive diese Drehzahl sauber kann?

Ist das primär begrenzt durch:

* Zwischenkreisspannung / Back-EMF des Motors?
* maximale elektrische Frequenz des Drives?
* Encoder-Auswertefrequenz?
* interne Regelzykluszeit?

Oder ist bei der 400-V-Klasse eher Strom bzw. Leistung der limitierende Faktor und nicht die Drehzahl?

Falls jemand hier bereits 400-V-EtherCAT-Drives (CiA402) im Bereich 15–25 kW mit LinuxCNC (IgH + cia402.comp) im Einsatz hat, wären konkrete Erfahrungswerte sehr hilfreich.

Und ganz unabhängig davon:

Wer Interesse an dem Projekt hat – ich sitze im Großraum Stuttgart (nördlich).
Ihr seid herzlich eingeladen, auf ein Bier oder einen Tee vorbeizukommen, Euch meinen Mini-Prototypen anzuschauen und mit mir über mögliche Umsetzungen, Verbesserungen oder auch meine Denkfehler zu diskutieren.

Ich freue mich über jeden, der Lust und Zeit hat, sich das live anzusehen.

Viele Grüße
Mücke