Advanced Search

I have installed and created a working configuration for my mill. I'm very happy with it so far. I previously had the mill controlled by mach4, which had some issues. There were some things that I like about the mach4 gui, though. I want to modify my linuxcnc gui to include some of these features and thought I might be able to use gladeVCP to do it.

The installation I used for linuxcnc is the newest and recommended install. When I follow the gladeVCP documentation section 3.1, which says that if the Glade command is miss, install it with the command sudo apt install glade.

The glade command is indeed missing, but sudo apt install glade fails with unable to locate package glade.

What am I missing? Where can I find the glade package?
 

Yeah forgot about the permission errors. With calling this script from crontab it will solve that:
#!/usr/bin/bash
sleep 10 &&
echo "-1" > /proc/sys/kernel/sched_rt_runtime_us
echo 20 > /proc/irq/63/smp_affinity & echo 20 > /proc/irq/64/smp_affinity

The last ones to pin the Ethernet irqs, you should take yours which you can find with "cat /proc/interrupts"

Then save the file somewhere and chmod +x /location/filename
And enter "sudo crontab -e" and enter "@reboot /location/filename"
After that at least you should have LinuxCNC working again.
For the acceleration I'll have a look for that one of these days.

Now I see that the previous time your nvme didn't work until I reverted the got patch. Is it working now? Because I didn't do that on this kernel.

At least the Panfrost and the Panthor drivers are built in the kernel so it should be a system config or Mesa problem. Is the Mali firmware installed? "ls /usr/lib/firmware/mali*"
Which image are you using?

I believe the axis GUI doesn't respond to changes such as you described, that can be seen in the example Sim configurations supplied with the standard Linuxcnc install.
Just thinking out loud, it would probably require digging into the axis code, exposing Hal pins for the GUI elements you would want to modify and implementing the code to respond to the Hal pins. This is part speculation.

But yes I've often thought that external interaction with the Axis GUI elements would be an idea, I still very much like axis. As much as many call the look dated, it works reliably.
But word on the street has it Axis is written in some language that only vets of The Editor Wars truly understand. I not too sure how many Vi or Emacs users are left.

Sorry for the dad joke at the end of this post, it really doesn't add much to answer your initial question.

unknown wrote:

I believe that can implemented in a web browser via careful implementation of bookmarking.

+1

Oh yeah, forgot to add, modules 1631 and probably 1632 have data values ​​output to port 2^16, so you'll need a bitslice conversion, not individual bit values ​​for input/output in your *.hal file

I believe that can implemented in a web browser via careful implementation of bookmarking.

For the RPi I created a topic that has links to various solutions to issues with the RPi.

Or copying and pasting links to a local html file. One could even create a GitHub repo for this purpose, organising links of similar topics into folders.

Or even a simple database on one's home computer, which would give you the ability to search by keywords. Or you could get real fancy and use PHP to connect to the database and have a browser based solution GUI for searching and returning the results as a direct link.

Look the current version of the forum software has a barely usable editor, anyways this kind of feature would be best suggested to the authors of the forum software.

Start with the configuration with the lpt port, then make changes to the *.hal file linuxcnc, if there is no physical lpt, then just comment out the lines using it... Attached is xml for 1631 and aq0810 from amsamotion
 

I've tried to run your config. Firstly corrected

BASE_PERIOD = 1000000
SERVO_PERIOD = 5000000

to

BASE_PERIOD = 0
SERVO_PERIOD = 1000000

You config also seems to be setup for imperial yet using mm?

I can jog with that above correction without following errors.

For your DRV8825 have you added the micro stepping jumpers? The DRV8825 wont enable without this, which I tried on my SKR3EZ. I unfortunately killed my normal SKR3 so cannot test with that board.

This may sound dumb as I am no gcode expert, but is there a way to "push" the current gcode settings
and restore them later?

ini values can be changed using the 'ini.*' hal pins. Changes can be made while a program is running but will only become active after a queue buster command (eg M66 E0 L0) which will restart the motion planner with the updated ini values.

I have found that I often stumble across interesting topics while searching for info on the forum site that I would like to go back to at a future date.  It would be awesome if posts could be tagged and saved to a user's account list for easy retrieval in the future.  The list should be editable to remove old links that are no longer needed.

Kind Regard,

Big thanks Chris, that was a really quick fix from you!

Fixing the bug in the normal uses cases is what's most important as probing errors are not that common once you get used to the various probing functions.

The abort handling seems tricky to solve indeed. I went through the documentation in search for a solution. I was looking for a hook to detect when a program has been halted but I came up with nothing.

Maybe some of the more experienced LinuxCNC gurus here on the forum has some input on how this could be solved.

Any update?

thanks Royka for the kernel.
I rebuilt the system today with Armbian Trixie and rt-kernel 6.1.115. I couldn't get the 3D accelerator to work. I think something was not set when the kernel was created.
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 19.1.7, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 25.0.7-2
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5 (Compatibility Profile) Mesa 25.0.7-2
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.0.7-2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Linuxcnc 2.10 won't start.
~$ linuxcnc
LINUXCNC - 2.10.0~pre0
Machine configuration file is 'gmoccapy.ini'
Starting LinuxCNC...
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX realtime
Found file(REL): ./core_sim.hal
rtapi_task_start(): Operation not permitted
HAL_LIB: could not start task for thread base-thread: -1
MOTION: failed to create 100000 nsec base thread
MOTION: init_threads() failed
motmod: rtapi_app_main: Operation not permitted (-1)
./core_sim.hal:7: waitpid failed /usr/bin/rtapi_app motmod
./core_sim.hal:7: /usr/bin/rtapi_app exited without becoming ready
./core_sim.hal:7: insmod for motmod failed, returned -1
Shutting down and cleaning up LinuxCNC...
USRMOT: ERROR: command 30 timeout (seq: 1)
emcMotionInit: emcTrajInit failed
USRMOT: ERROR: command 3 timeout (seq: 2)
Note: Using POSIX realtime
LinuxCNC terminated with an error. 

What do you think?

In my gladevcp panel I have configured two buttons to set the jog rate. One to set to the lowest value that I use for positioning my crosshair laser, the other to set to the max value that I use. I have tried both ACTION.SET_JOG_RATE(rate) and GSTAT.set_jog_rate(rate), but neither affect the jog rate display in AXIS.  The documentation for GSTAT.set_jog_rate(rate) mentions that after setting the jog rate, the jograte-changed signal is emitted which I would expect to update the AXIS display but there is no feedback indicating that the rate has changed. Is this a known issue or am I doing something wrong?

FYI - I also have a combo box to select the current system offset system which does change the AXIS display after a new offset is selected, so I would expect these two functions to work the same.

Kind Regards,