Advanced Search

unknown wrote:

Warning: Spoiler!

Have the servos been properly tuned ? Steppers are basically wire up and forget, servos are a different beast and require tuning or you may hear grumbling noises.

stepper sorry.... 

Have the servos been properly tuned ? Steppers are basically wire up and forget, servos are a different beast and require tuning or you may hear grumbling noises.

Depending on the drives, you might have enough I/O from the built in digital I/O on the drives themselves

Not quite true, disabling hyper threading is well worth it, as are a number of other generic options that have been discussed.

As for the kernel config, the most important settings are the preempt_rt ones, infact one of the easiest ways is to base the config for the new kernel on the running one.
If you really feel the issue is with the GPU I don't think a different kernel will fix much.

I instaled linuxcnc scurve compact with the install script from cmake folder
Is it different from the one in the root scurve compact folder?

In the conventional method, if the table bottom is always set to G54_Z0, there is no problem with setting [BLOCK HT], but if the work top is set to WCS, [BLOCK HT] must be changed frequently.
Changing is troublesome, and checking the current setting value is also cumbersome.
If the WCS or [BLOCK HT] changes, the tool table value also changes.
Also, I cannot read what the offset value in the tool table indicates.

---

After the change,
Z height can be set in WCS as well as XY,
so the situation can be checked from the main screen.
In particular, the Z height is consistent, and is reflected when the WCS is switched.

The tool is always consistent with positive compensation.
The Z_offset in the tool table is easy to read because it lists the tool length.

Since the tool offset is consistent, it can be approached at high speed in advance when probing. This is expected to reduce probe time, especially on slow-moving machines.
If the previous tool length could be displayed in the tool change dialog, human error would also be reduced.

So far we haven't had any major issues,
but we'd like other people to take an interest and find ways to improve it.

I just realized there are also EtherCAT IO interfaces, so if that's supported, I could indeed get away with basically "ethercatting" everything without any extra "controller board"? That'd be incredible :O does it actually work with stuff like this too? www.aliexpress.com/item/1005006811064267.html

Yes, I understand that, but I still need some hardware that can do the following:
1. Interface with other peripherals such as relays, emergency stop button, endstops (unless I use sensorless homing), VFD
2. Have ethernet
3. Host a raspberry pi
4. Ideally offer photocouplers for some inputs

So I guess at the very least, I'd need some kind of a breakout board for Raspberry Pi that is known to also work with Linux CNC. Does it make sense? I'm really lost in this whole topic. Ideally it would be something proven that people have already tested in a similar configuration that I require. I just know that if you have something like Sinumerik controller or even Acorn Hicory, it's kinda what I wrote above, minus the Raspberry Pi and I thought I will need something similar to run LinuxCNC on and have the IO exposed.

With EtherCAT you typically do not use a motion control card (Mesa, Remora, etc)
but rather use EtherCAT capable motor drives.