Advanced Search

About the cia402.0.pos-scale, I wrote 100 000 to just start with some value. My encoders are 23bit, therefore 8 388 608 pulses per motor revolution. On my current plasma machine I have a 1:10 planetary gearbox that I plan to use when I upgrade the machine motors to servo motors and LinuxCNC. The rack gear pitch diameter is 50 mm, therefore the circumference is 157.07963267949 mm. This the linear distance that the axis will travel for 1 revolution of the rack gear or 10 revolutions of the motor.

Therefore the cia402.0.pos-scale = ((encoder res * gear ratio)/distance per rev). I am not sure what value I should use for distance per rev - is it the linear distance per the rack gear revolution or the linear distance per motor revolution(that is linear distance per rack gear revolution / gear ratio)?

Hakan wrote:

It sounds like you get gravel in the servo motors from time to time.
Or you get click sounds from the motors. It repeats itself with a few or many minutes apart.
The first thing to do is to enable syncToRefClock and enable DC mode for the servos,
this will keep the servo loop in sync with the DC.

What grandixximo is doing here is fixing an effect that despite DC and servo loop are synchronized,
the two loops have been started with an undetermined/unfortunate phase between them.
The gravel sound is there all the time and it doesn't go away until linuxcnc is restarted.

Surprisingly, yesterday Sasha Ittner popped up in the PR log and mentioned he had been working
on a complete redesign of the DC system, eliminating all these problems (don't know details)
grandixximo seems to have reviewed that work and decided to adopt Sasha's work.
grandixximo will have to say himself. And if you don't know, Sasha Ittner is the author of linuxcnc-ethercat
from many (>10) years ago.
 

After reviewing on real hardware today, I found my original PR works better than what Sasha Ittner did in his repo, I reverted back to the original state before I started reviewing Sasha's work.
If anyone wants to help me test, I'd love feedback on the code in my repo, because for me this is what works.
github.com/grandixximo/linuxcnc-ethercat
But I need more data from other testers.
To prove the system works, you should get grinding noise, if you set sync0shift of your drive to be half your max servo latency, open halscope and scope your servo-thread and open a couple of glxgears to induce latency in the servo thread, this should induce the grinding noise, and the noise will not be anywhere else.
 

Initcmds can be used to set a configuration at startup github.com/linuxcnc-ethercat/linuxcnc-et...er/examples/initcmds

your cia402.0.pos-scale is very large. Double-check that one.

Set a negative value for refClockSyncCycles="–1", that switches on the PLL to synchronize
servo loop with DC clock. You also have "did not sync in 5000 cycles" in dmesg. I have no
good way of fixing that, eventually the drives will sync their time though.
 

that looks like its looking on the cd/DVD. If this is not on installation, edit your sources file to remove the CD/DVD settings

I talked to the manufacturer of the drives and they told me that the PDO mapping should be set in the control device on each start of the machine.

With the above mentioned configuration I tested the homing and it seems the motor find the index pulse but then it starts rotating very fast and following error is reported.

But the synchronization error is still present.

Hi @NWE,

No worries — things have been a bit busy on my side too

Over the last days I focused on validating the CiA402 logic layer in simulation using a HAL drive stub. The main pieces are behaving as expected now (PDS state machine, controlword composition, homing supervision, etc.).

I also added a small gantry supervisor component on top of the CiA402 layer to experiment with safe decouple/recouple behaviour when drives perform internal motion like CiA402 homing.

At the moment everything is running inside HAL with two simulated drives.
Next step is reconnecting this to the EtherCAT side through an adapter layer.

I'm also planning to write a small Python CLI diagnostic tool to read the HAL signals and print a quick snapshot of the CiA402 state to help with testing.

Your Lichuan drive with 4 axes in one unit is quite interesting — that could be a very good test case once the EtherCAT adapter is wired.

I might also open a separate thread later describing the small framework this is turning into and include your two drives as example adapters.

No rush at all

I saw this in a recent PR sent by Sascha Ittner:

github.com/sittner/linuxcnc/pull/70

github.com/LinuxCNC/linuxcnc/pull/3845/c...7ac47d8c5d436a843202

Description: joint_ctrl_main.c
* Standalone HAL realtime component for single-joint control.
*
* Provides: homing, keyboard jogging, jogwheel jogging, trapezoidal
* trajectory planning, following-error monitoring, limit-switch
* handling, and backlash compensation — all as a self-contained
* HAL component independent of the full LinuxCNC motion controller.

If the installation fails and you want to see what is going on, go back to "Configure the package manager."

Hit Ctrl Alt F4.

You will likely see something like the attached output scrolling down the screen. What is odd in my situation is that even with the network cable plugged in, I am able to ping the host that it claims to be unable to reach.

Hit Ctrl Alt F5, and that will take you back to the GUI where it has gone on to the GRUB installation portion and likely failed at this point.

This is an odd issue to have!

any other suggestions? I can get my enc-index-c-enable to trigger once but I have to turn it on in hal each time. it will also freeze unless i connect the latch. does linuxcnc only care about the Z or does it need a/b as well

Marcos wrote:

Sorry for the late reply — I was a bit busy the last days.


 

Same here. It'll be several more days till I get back to this project.

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.