Currently the value of the sliders can only be adjusted by the +/- buttons. This makes it impossible to change those values quickly.
Here are two implementations which opens a bigger slider with the possibility to drag the slider.

What do you guys think of those two versions?

The previous owner installed a magnetic encoder on the X axis. I did not disassemble it, so all there is to see is a thin cable coming out.

I installed a glass scale on Z. I will make photos tomorrow, there is perfect space for it behind the X-axis motor mount. The installation was really easy.

Oh, and to “home to switch (hall switch) and then to the next encoder count” that is what I did initially. That way I got about 0.4 mm variability on X.

I don't think you need to wire the motor encoder A and B signals in to LinuxCNC to try it. It is a standard LinuxCNC option to home to switch (Hal switch) and then to the next encoder count, which you already have wired in.

I am interested to see how they did the physical installation of the linear encoders. I considered adding them to mine, but didn't.

Found another bug/missing feature in tp1. Hitting feed hold sometimes breaks planning, I guess the remaining length of current segment is too short to calculate using ruckig?
Ruckig planning failed (first attempt),
Back to tp 0
feed_override: 0.330000
max_vel: 132.000000
cpos: 380.077500, tpos:
380.133525, dx: 0.056025
cvel: 33.000000, tvel: 132.000000
cacc: 3000.000000
maxa: 3000.000000, maxj: 120000.000000

I don’t think the linear scales are at fault. I tested them over the 20 mm range of my longest indicator in 1 mm steps, and that is flawless for both axes. I also had the axis move over nearly its full range for 5 minutes at rapid speeds and then come back to the indicator, again, no measurable deviation.

To test the motor encoder directly, I would have to solder them in, and I cannot imagine that this will be better, as I already use the index from there. But if I don’t have any other options, I may as well try it.

I can make some pictures tomorrow, do you mean the mechanical installation on the machine or the wiring, or both?

You are making great progress. Took me a year to get that far

I can't say why it is not working as it is, but I have no linear scales, so my homing is just the home Hal switch and then fine tuned off the motor encoder index, and that is rock solid. Could you ignore the linear scale, and home the same as mine (which I think is original Schaublin)?

Please upload some pictures of your linear encoder installations.
Cheers,
Mark

I’m a NativeCAM user and I really love it, so I’m very happy to see that you are taking care of it and moving it forward. Thanks a lot for the work you are putting into this!!! 

Are you planning further improvements as well?
Especially on the lathe side, NativeCAM has huge potential. In my opinion, it is really only missing one key feature: a polyline function for lathe.
As far as I know, Fern never implemented that because the G71, G72 and G73 contour cycles were not working properly at the time. Today this should probably be possible, but unfortunately it was never added, which is a real shame. sadly people who are not programmers like me, cant help, just cry. ^^
With that one addition, NativeCAM could become extremely powerful for lathe work, probably on the level of ShopTurn. Then many LinuxCNC lathe users would no longer need a separate CAD/CAM solution.

That said, I’m already very happy with what you have done now! I use NativeCAM a lot on the milling side, and it is a real time-saver and makes the work much easier.

greetings 

Tom

Hi,

I have a new update. Almost everything is working now. I have one hopefully last problem.

The X axis homing is not repeatable at all. Both axes have a hall switch (original Schaublin), and both axes have linear scales (these do not have index signals). I noticed the lack of repeatability and put the blame on the 50 year old hall switches.

I used the index from the motor encoder (provided by the motor drivers). I connected them to the index inputs on the encoder connector for each axis. So I don’t have the full motor encoder on a separate input on the 7i97T, but I have the A and B lines from the linear scale and the index from the motor on one connector per axis.

With this, the Z axis is rock solid, but the X axis is not.

I homed the axis and drove it against an indicator. Then I rehome and drive to the same position. This way I see about 0.25 mm of variance (I did this about 20 times). Without the index, it was about 0.4 mm.

For Z, the index increased the repeatability from about 0.03 mm to nothing I could measure with my indicators so around 0.001 mm.

What I tested already:

Mechanical: The axis has no noticeable backlash. Moving the axis by hand (with the motor dismounted and turning the pulley by hand) feels very smooth.

Index signal: Both HALScope and a “real oscilloscope” detect the index signal. It is not as clean as I would like it to be, but the pulse is clearly there, and the Z axis that works fine looks the same.

If anyone has an idea where this could come from, I would be thankful.

I'll add to this, this mostly works, but not perfectly, so any help appreciated about the reasons.

Answering this myself for the next person, it needs

import time
from interpreter import INTERP_OK, INTERP_EXECUTE_FINISH

def change_tool(self, **words):
# Perform actions
# ...

# Pause for 2 seconds, synchronized with motion
yield INTERP_EXECUTE_FINISH
time.sleep(2)

return INTERP_OK

I've created a pcb fiducial detector within camView, I'll assume this is running in the qtvcp/UI thread. 

I've exported HAL pins from the camView widget so I can control this, then added manual control buttons on the UI, and linked these in the postgui_hal file.

I want to control this manual button from a remapped m code, so I've exported another hal pin to do so.  The problem is that when I set this pin from the m code, the UI/qtvcp thread is never serviced, so nothing happens.

What are some ideas or solutions here?

What I've done is added to qtvcp_plugin.py and in ~/.designer/plugins/python/user_plugins.py and in qt_handler.py at top It works ok, just one root mode needed that way

I've done some work today to merge Sascha's new implementation of DC

github.com/grandixximo/linuxcnc-ethercat...ses/tag/v1.41.0-pre1

I'd love if users here could try it out, and let me know how it goes, the deb is built for debian 13

test with refClockSyncCycles
-1
1
5

About syncToRefClock, you can still use it if you want, but a more strict use will be enforced, to avoid confusion, settings that do NOT make sense will FAIL to open.

bladekel wrote:

I am using a Raspberry Pi 5 with the LinuxCNC Debian Bookworm image.
I have configured the system to communicate over SPI.
I can move all axes, but when I run a G-code file, I experience a drift in all axes.

To troubleshoot the issue, I wrote a simple G-code program that only moves the X-axis: it moves 10 cm in the positive direction and then 10 cm in the negative direction.
I set this program to run continuously in a loop. In every cycle, a small shift occurs in the positive direction.
After 20 repetitions, I observed that this drift reached approximately 5 mm.
The start and end points of the program shift slightly in the positive direction with each iteration.
I have also tested it at very low speeds, but the result remains the same.

I am certain there is no mechanical backlash or electrical interference/noise.

I am attaching my configuration files. What do you think could be causing this?
 

For those who might encounter this problem, just like me;

This problem is caused by the dir_delay. 
Solved by increasing the dir_delay value.

Hi Zbigi,

Of course, happy to help! Please open an issue on GitHub:

github.com/cnc-proton/nativecam-py3-gtk3/issues

Most likely you hit the critical bug fixed in latest commit —
duplicate option in cfg/lathe/material.cfg caused a crash on
Python 3.13 before the menu bar even appeared.

Quick fix:

sudo sed -i '/\[PARAM_Z_RAP\]/,/^\[/{/^header = h3/d}' \
/usr/share/linuxcnc/aux_gladevcp/NativeCAM/cfg/lathe/material.cfg

sudo cp /usr/share/linuxcnc/aux_gladevcp/NativeCAM/defaults/lathe/default_template.xml \
/usr/share/linuxcnc/aux_gladevcp/NativeCAM/catalogs/lathe/projects/

Then restart LinuxCNC. Let me know if it helps!