you mean :
sudo ethtool -C enp0s25 rx-usecs 0
I did that, it does not change anything.

In the implementation of the version of the respected comrade. AkkiSan from forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#333578

there is a typo that emerged during compilation -
instead of -
esleep(0.010);

necessary -
usleep(0.010);

I don't think it's a "bug", there does seem to have been some debate in the forum and GitHub as to the "correct" behaviour.
github.com/LinuxCNC/linuxcnc/issues/2956

github.com/LinuxCNC/linuxcnc/issues/3464

Thanks for the explanation, it really helped. I made indicators for e-stop, on/off, manual mode, and MDI. There was a slight issue with auto mode. I wanted to make indicators for auto mode, running programs, and pause. This is the only way I could do it:
Is this ok, or is there a more elegant way?

I don't think modern drives loose torque with microstepping. I ran 25x microstepping on my machines.....But yes I was considering how much microstepping I could use. Maybe 8x. Adding a belt reduction is often the wise choice.

Yes, I found the specs in the manual. Seems like you could increase velocities

Sekai wrote:

i tried with the ethtool but no change
 

after reading some more i disable AMT setting from bios but the value remain the same

Please fix the coalscing setting and report back also energy efficient Ethernet could impact from time to time if enabled.. 

Sorry, I based he code on my experience but now I see your situation is different. You could modify the code to achieve what you desire. Just swap things around.

I made fresh install from 2.9.4 ISO then update & upgrade to 2.9.7 and you can add new mdi command only after the previous one has been executed
I though this bug was already fixed, can anyone tell me is this only problem with my config 
thanks
 

abs32 wrote:

it seems to me that this is "not sporty". Together we must force the correctly given commands to be executed correctly. G38.3 should not produce such errors.
You suggested changing the interface to qtplasmac, but it uses the same g-code and linuxCNC. And I have a milling machine.

The difference is that  qtplasmac does not use gcode to control the torch height and it does not use Gcode to probe for the surface. Any gcode affecting the Z axis are ignored as they are filtered out when the file is opened.\. As I said that is al done with external offsets. That is, external to the motion controller. Please watch my video overview wnad read the comprehensive explanation in the comments. 

Hello,
your problem is not the amdgpu.
That is the "normal" raspi-firmware-bug. Please use: sudo dpkg -P raspi-firmware
I think the amdgpu error message you can ignore. I have the same on my old amd-test-pc

Beovoxo wrote:

Hi all, i tested again today with a fresh download of  2.9.4 from the main page. And now i am stuck as all the other ones are at, the missing "amdpgu fault". 
Was there a solution on that fault ?, i cant decipher if there was one, on all the other forum posts with that fault. 
ibb.co/G4FrwL3t

If there is not a solution i will try the "mint" Tommylight uploaded 

 

 

Please correct me if I'm wrong.
Dealing with a previous mistake
forum.linuxcnc.org/38-general-linuxcnc-q...ue-with-g38-5#337899
it was completed with a victory via a patch -
github.com/LinuxCNC/linuxcnc/pull/3537/c...54ead378bbe05398b9d2

This patch changes the src/emc/motion/control.c file
I prefer the idea of using versions with a real-time kernel, which obliges me to use version 2.9.4. The version of this file in the source code 2.9.4 and 2.9.7 differs in the inserts for this patch. Therefore, I bring this file for version 2.9.4. to the state version 2.9.7 = error correction "probe tripped during non probe move"
Then to implement the version of the respected comrade. AkkiSan from forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#333578
changes should be made to the src/emc/rs274ngc/rs274ngc_pre.cc file (this file is the same in versions 2.9.4 and 2.9.7 before the fix).
Then you need to build and run.
The trouble is that I have an ArchLinux fast car, but a combat car with a machine tool is leisurely. I'll try to collect it.

Did you also get the M19 and axis-to-spindle switch to work as you said there were some issues?
My first thought there was to just verify the drive is actually switching modes, you have the 
opmode-display from lcec you can watch.

Published error traversal methods based on wrapping a signal through a digital input cause g38.5 to fail and be replaced by G0 or G1 - an erroneous path due to poor accuracy and surface finish speed. I experimented and compared the smoothness of the result with G38.5 versus G0\G1. To use G0\G1 for rebound, you need to set an excessively large amount of upward rebound, which radically reduces the speed of surface treatment and just as significantly increases the noise of the operation.
Conclusion: we must fight to correct the error.