Advanced Search

2. The control station must issue step commands at a speed of 1000 Hz, in other words - 1000 steps per second. (As I understand it, not faster than this speed.) This is called the servo thread rate.

No, LinuxCNCs trajectory planner provides waypoints(position vectors)  at the servo thread rate.
For simple parallel port type systems these waypoints are sent to a stepgen component that runs
at a higher thread rate (the base thread) and interpolates between the waypoints. That is, the
stepgen component does the high speed step generation so as to reach the next waypoint at the next
servo thread invocation.

Eagerly waiting for tmc5160 support on stm32f4 board

PCW wrote:

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.

Thank you. It seems the fog is starting to clear. However, not completely yet.

Let me formulate how I understood you. And please correct me if I understood something incorrectly.

1. We are discussing devices with a two-bit discrete interface for controlling stepper drives. (For example, I have a ChinaCNCzone 3040Z 500W machine)
2. The control station must issue step commands at a speed of 1000 Hz, in other words - 1000 steps per second. (As I understand it, not faster than this speed.) This is called the servo thread rate.
3. Since the controllers do not have intelligence (only microstep functionality), the interpolation is done by the program.
4. To perform the interpolation, a certain second thread is used, faster than the first, and having strict requirements for real time. It is called the "base thread".

Then, the specifics end and the fog begins to thicken again. Inevitably, well-founded questions arise.

1. What interpolation algorithm does the program use?
2. How is the second thread, the so-called "base thread", used in it?
3. Why is it faster than the first?
4. What is the reason for the relatively strict requirements for the base thread's real time and relative to what?
5. Where can I read something about this algorithm?

(The goat is cool!)

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.