Advanced Search

No, if everything works now then you do not need it.

Awesome !!!!python3-opengl install made it to work !!

Thanks... Do I need python3-gi-cairo as well ?

I don't think the way to do this is with a g-code remap. Seems to me it should be job of a file filter that reads and translates the g-code file on loading. That is perfectly acceptable as a python script, or even a bash sed script. Then the time to process is only at file loading and it doesn't get in the way of the running realtime code.

try:
you may also need:

Did you try the official ISO from here:
www.linuxcnc.org/iso/linuxcnc_2.9.3-amd64.hybrid.iso
-
You also do not have the real time kernel installed, so even if you get OpenGL to work, you can not use it to run a machine.
Usually OpenGL issues are related to graphic cards, so if you have one as an add on, remove it and try again.

My machine is a Lenovo thinkcentre with M93P.

I am trying to build LCNC version 2.9.3 from source on Debian Bookworm.
Facing below issue seems related to OPENGL. Checked a few threads but the issue as per them shall have been fixed by now.
Just wondering if I am missing something obvious.

- Configured for ./configure --with-realtime=uspace

- All build deps are satisfied.

- No issues during build .

Here's the logs on running LCNC from cmdline.

rkc@debian:~/lcnc/linuxcnc-source-dir/bin$ linuxcnc
LINUXCNC - 2.9.3
Machine configuration directory is '/home/rkc/lcnc/linuxcnc-source-dir/configs/sim/axis/ngcgui'
Machine configuration file is 'ngcgui.ini'
Starting LinuxCNC...
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX non-realtime
Found file(LIB): /home/rkc/lcnc/linuxcnc-source-dir/lib/hallib/basic_sim.tcl
setup_kins: cmd=loadrt trivkins
Traceback (most recent call last):
  File "/home/rkc/lcnc/linuxcnc-source-dir/bin/axis", line 24, in <module>
    from OpenGL.GL import *
ModuleNotFoundError: No module named 'OpenGL'
Shutting down and cleaning up LinuxCNC...
link (updating variable file): No such file or directory
task: 140 cycles, min=0.000008, max=0.001132, avg=0.000969, 0 latency excursions (> 10x expected cycle time of 0.001000s)
Note: Using POSIX non-realtime
LinuxCNC terminated with an error.  You can find more information in the log:
    /home/rkc/linuxcnc_debug.txt
and
    /home/rkc/linuxcnc_print.txt

No I don't get precise revs.

Do you get precise 1.00 spindle position change for each turn,
If not, that must be fixed first.

Then you need to check index operation as described before:

Did you verify index operation:

watch spindle-index-enable then
sets spindle-index-enable 1
turn spindle slowly by hand
at the index position (and nowhere else)
spindle-index-enable should go false again

EDIT:

Also, is the spindle RPM ( spindle-vel-fb-rpm) correct?
(this would give a rough check of encoder operation)
 

I cannot comment on the example python code.
A python remap can certainly parse a file of logged point coordinates, do calculations on those points and then output the results as, say, a list of G1 X.. Y.. Z.. moves and write these into a ngc subroutine that is called later in the gcode.
The issue with python is the time it takes to do all these things so if you expect to be able to do something like this:

G01 X.. Y.. Z.. F...
G5.4 ...

and expect this to blend without pause then that is likely not possible because of the lag inherent to python. However if you can pause gcode execution for the time it takes the python script to do its thing then I don't see a problem.

In a python remap controlling the read-ahead is VERY important. The first thing you want to do is stop the read-ahead before it ingests the python remap. Hence there won't be any blending between the Gcode before the remap and the remap itself.

Hello, I am using the Orange Pi 5 Plus. I’m running Debian from the official Orange Pi website, and I have installed a real-time kernel patch (version 5.10.160). When I run LinuxCNC, I encounter this error when starting hm2:The real-time kernel is working very well, but I am experiencing many errors related to total_packet_errors, which was showed in hal

Pictures of the wiring? Upload here on this forum, not on third party sites, please.
The spindle in hal is set as stepgen 6 and encoder 3, Mesa 7i95T has 6 stepgens numbered from 0 to 5, so where is stepgen 6?
Also, do not use a BOB on a 7i95T unless you explicitly need more than what it has to offer, BOB are really, really slow compared to Mesa.

You need to fix the limits in the ini file, why would you have -100000 to 120000mm of travel? That is 220 meters of travel if in mm, half a city if in inches !
And if joint 1 and joint 2 are tandem axis, home_sequence must be -2, not 2

Graphic card is way to hot while doing nothing, is it an add on or built in?
That is the Radeon thingy, made by AMD.

Try a different mouse. If the mouse cable is nicked or worn it may cause huge delays in communications, or might be interference or bad USB chip in the mouse. Mouses are cheap.
Also, is the mouse a PS/2 one or USB?

This seems more of a PC issue as there are "seg fault" and "corruption" errors all over the log, or might be the RTAI kernel really, really does not like that PC.
If you do have another PC (even with no parallel port), yank the hard drive out and put it in the other PC and see if it boots and runs some SIM configs included with LinuxCNC.