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.

LinuxCNC works identically to most CNC systems in that it outputs
a stream of joint/axis position coordinates (waypoints) at a fixed rate.

In LinuxCNC this rate is called the servo thread rate. This is typically
1 KHz in LinuxCNC but can be higher. In addition, either LinuxCNC or
downstream hardware interpolates between the position waypoints
so smooth motion is generated.

Simple LinuxCNC systems using a parallel port or GPIO do the interpolation
and step/dir generation with a second, faster real time thread, called the base thread.

More complex systems do the interpolation in external hardware or processors
(Mesa cards, Remora, RIO etc) or in the motor drive itself (EtherCAT) and typically
do not use a base thread.

 

unknown wrote:

The values for step & direction are part of the ini file and can be adjusted to suit many stepper driver products.
With a 25000 ns base thread motion will be based on this.
External motion control is usually based on a 1ms update period.

Hence the reason a known & steady latency is important, regularity is an important factor, like a band if the drummer isn't regular, uhmmm like Lars from Metallica, things don't work as well as they should.
 

Regarding the step value and the ini file. Correct me if I'm wrong, but its linear value is specified there, not the execution time. (When I set up my CNC, there was no talk about time.)
When we start discussing milliseconds, it means that we have accepted as a given the position about the need for parallel execution of commands on different axes.
Maybe this is true, but I do not yet fully understand the wisdom of this idea.
Where can I see materials about this?

How can use it with qtdragon_hd ?
Also the icons are missing from menus.

Does the servo spin when LinuxCNC is not running?

tommylight wrote:

What are you trying to do, exactly?

Einstein said that the basis of science is the flight from amaze. I am amazed and I trying to understand the meaning of what amazed me. This is important.
I have dealt with several professional control stations - Fanuc, Siemens. All of them issued control commands sequentially.
From you I learned that LinuxCNC uses a more progressive algorithm. Now I want to know about it.

I think it looks ok, maybe there is something with the exact kernel version and the module version but it should still work even with the "tainted" message.
We are just trying to find out why it doesn't work and make it work.
Actually, maybe the interface settings.
You showed some screenshots early in the thread with IPv4 settings and more.
Actually, ethercat and IPv4 are not compatible and one should not configure any IPv4 things on the interface.
On my system, the ethercat interface doesn't even show up on the first screen of that application that lists the interfaces.
This is how my interface is started, in /etc/network/interfacesThat hardware-irq-coelesce setting is a Intel card setting.

The output of my ethercat interface fromthe commadn "ip a"no ipv4 address