Advanced Search

Yes, I did. But it did not help.

I have seen that with master and 2.9

Did you 

make clean

after changing branches?

 

You can easy change it.

Add this code to gmoccapy.py file to "def on_btn_apply_tool_changes_clicked"
like this:
 

1) G43 must be activated
2) after input new value in cell you MUST confirm it for example by key ENTER, then you can click on Apply
3) after click on Apply button you will see right correction value
 

youtube.com/shorts/mWCeSrF2TUM
I did a new test 100 windows of glxgears and CPU stresstest active the PC is no longer responsive even the linuxcnc window but the servo continues to go and finishes the job. I don't understand why YouTube goes into error! I must say that today the drivers arrived and the new servos do not make a minimum of noise but I have to check them in the car better.

Hello,

I am learning git. I cloned data from Github. I compiled it with branches copied from master branche.
I made my first Pull Request with git.
github.com/LinuxCNC/linuxcnc/pull/3434
I celebrated. Everything was fantastic.

Then I needed work with 2.9 branche.

I checked out it:

Then I made:

I must do something wrong, because I tried compile branche 2.9 downloaded from Github in zip file and It worked.
I tried git clean and it did not help.

How should I work with different branches with git?

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