Shot in the dark here...

When I switched my spindle encoder to a fairly high resolution version I ran in to intermittent problems with the signal.  Turns out Mesa cards have a filter on the dedicated encoder inputs that can be adjusted:

Setting it to False sorted things out in my case.

I've no idea if this is causing you a problem, but it's a easy & free thing to test.

After that, next suggestion would be to remove all the PID loops and other stuff from the spindle motor control loop.  Run the VFD open loop, variator set to one position.  Take everything that changes spindle speed out of the equation and do another series of G33 tests.

I don't know that the spindle speed variations are affecting the threading, but it cant be helping things.  Listening to that WAAAHH-uuhhhh-WAAAHH-uuhhhh in the video was driving me nutsimage missing /media/kunena/emoticons/wink.png

Thank you for your support. One more silly question: how do I get updates? By updating to the latest version 2.10 of LNC?

It appears I'm on my own... again. So far nothing worked to get a repository to update LinuxCNC. So I said f-it and completely deleted the partition and reinstalled linuxcnc completely from scratch. I am gad I did.  The new installation resolved several issues. Most importantly, the editor in Linuxcnc that nothing I tried worked to get it resolved, is now resolved.
 
 

Sorry I meant to say Freecad version 1.1.1 and the CAM workbench, into Linuxcnc.

Hi All 

Thank you to everyone who commented.

Much appreciated indeed  

I re-wired some of it , that didnt help, but at least it confirmed that what I had seemed reasonable, which was good to know.

The scale with a minus sign did provide another option, which I used , the comments also provided a better understanding that I might have been changing the same thing over and over just in different ways and complicating matters.

In the end I iterated through as many possibilities as possible, and eventually it both homed, and it jogged in the correct direction.

I milled a square out of a piece of plywood (using Linuxcnc v1.1.1 and the CAM workbench),  and the machine seems to work fine. 

I am very greatful to everyone who contributed through this forum in order to get this machine going, and to keep me going too
 

I got one of these at Xmas and it's been excellent. It's often described as a Bambu clone. Currently £239 in the UK, arrived in 2 days and works locally without the need for internet or their Elegoo cloud. 320C, heated bed, wifi, webcam, PLA/PETG/ABS/ASA/TPU/PET/PC/PA etc. They do a multi colour version for £398 but I'm not a tart. I model stuff up in Fusion, export as STL and use the Orca slicer that supports it out of the box, controls it over wifi and doesn't seem to need any fiddling about.
Elegoo Centauri Carbon

That type of instruction executes correctly; the problem only occurs when executing one of type o<XXXX>. I tried executing it from the MDI in the form o<xxxxx> call and it also gives me an error.

Muecke wrote:

1. Der Motor hat eine integrierte Haltebremse.
   Benötige ich dafür zusätzlich ein 24 V DC Netzteil, um die Bremse überhaupt ansteuern bzw. lösen zu können?
   
   
   
   Ja, du benötigst noch ein separates 24V Netzteil um die Bremse zu lösen.   

Edit: Und natürlich ein entsprechendes Relais.

Just figured it out. I had a file called custompyvcp it was looking into for the ztouch code. Whoops. Thank you again for your help!

Hi Rodw nice to be in contact with you.
I have CR ELECTRONIC and i would like to replace the generator by the new one.
i have identified the signal PLASMA ON commning from the CNC,for operating the new generator. But the CNC are waiting a signal ARC TRANSFERT from the genrator. I can't identify where the signal must be connected on the CNC and which type of contact must be ( dry contact or other).
Do you have an idea please?
BR

No that is an error of the logger color formatter. I have pushed a fix for that now.