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

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

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?

Regarding DRO — I already did exactly that, edited dros_user.ui removing the A and C rows. DRO now shows only XYZB. However the A+/A- jog buttons remain — they are controlled separately from the DRO file. Is there a way to remove the unused jog buttons without touching system files?

Regarding wrapped rotary — very interesting! I am ready to test. What do I need to get started with the test branch and what machine model is required?

You will probably find a 7i96s is cheaper in the end but there is a lot more wiring to do. Ethercat encoders are expensive and probably difficult to configure if you can't close things on the drive. Either way, try to get an Intel NIC. The balance probably falls in favour of Mesa if you can get away with a 7i96s

Except for versa probe and basic probe, the short answer is no general way to customize widgets.
Versa probe and basic probe look for customized ui and handler files.
This describes the process for them:
linuxcnc.org/docs/devel/html/gui/qtdrago..._probe_screen_widget

You can always add your own widget to qtdesigner.
the plugin link should be in a hidden file in your home folder:
.designer/plugins/python/Link to qtvcp_plugin.py
you could add more links, but it's a fair amount of work.

What widgets do you wish to customize?

Yes that sound more reasonable thanks for that info I wanted to go by ethercad to have a small HMI PC for Linux CNC but if mesa card makes more sense sure than I go that way.

Can you maybe give me some info what to look for I need a computer with PCi port and the the card is the driver or do I need extra drivers and than the stepper motors ?

Maybe someone can recommend me a setup that would be nice thanks so far for the help I really appreciated it 

The commanded C position should come directly from LinuxCNC, It should not have steps
nor be affected in any way by PID settings.

Can you post your HAL/INI files?

 

do you have the plot turned on for machine bounds in the ui? sidebar tab "PLOT"

for the dro display, you can use the user custom dro template and setup however you desire, just remove the rows for a and c and leave xyzb

for the wrapped rotary, this will be something coming down the line, we are currently working on multi axis plotting and simulation so if you have a model of your machine and would like to be a tester for the currently existing test branch you can give it a try if you like, the feedback would be good for us to have someone outputting multiaxis gcode for testing.