Advanced Search

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.pyand in ~/.designer/plugins/python/user_plugins.pyand in qt_handler.py at topIt 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!

   
Update: DRO is now showing only XYZB.

Edited dros_user.ui and offset_dros_user.ui removing the A and C rows and fixed the ZERO ALL command.

Added to INI:
DRO_DISPLAY = USER
USER_DROS_PATH = user_dro_display/
OFFSET_COLUMNS = XYZB

Screenshot attached.

The A+/A- jog buttons are still present — is there a way to remove them without touching system files?

Regarding the wrapped rotary test branch — ready to test. My setup is a standard XYZ milling machine with a B axis mounted parallel to Y. Where can I get the test branch and how do I get started?

I want to gave here few of my own suggestionos from my own expierence of working with gmoccapy

• Optional warning when feed override is zero during program start. I see many times confused people wondering why machine isn't moving and there is no error or something, the practice is known in another controls like Homag PowerControl
• making gmoccapy version for HD screens, as it becomes more common these days. perhaps it could be done with some .rc file like version for 800x600. It could also fit some extra buttons horizontally (I calculated 13) so we could show them or hide depending on screen proportions
• Fixing situation when I editing the code and someone activates external estop. Now it closes the editor and jumps to locked manual screen and my changes in file are lost. It should allow to save work and allow to go back to safety but not throwing you out of your work
• Maybe adding some basic controls to file editor like copy, cut, paste, delete and rename file. It would prevent the situation when I'm forced to go back to desktop for simple file copy from pendrive. This break the immersion of professional control
• also as we now logging situations in gmoccapy it would be nice to have graphical interface in program to read this entries (probably from settings page). In many professional controls there is a log of actions so the supervisor could diagnose the machine
• one last thing it will be good to have some kind of interface (again maybe in settings page) to quickly make a backup of config and nc files (maybe to choose). It is good practice in machinig to doing it periodicll

I'm open to discussion of my ideas. 
Also some of them I perhaps could incorporate myself as I already did some but versions going up quick and sad part is I still don't find time to understand github... sorry Mayby some could also help a bit