Advanced Search

The name must always match

file:
myfile.ngc

in the subroutine:
o<myfile> sub
  some code
o<myfile> endsub

call the sub:
o<myfile> call
 

yes I bet that's it. I notice you are using metric, so .006 is pretty small.
I'll try to track down where the rounding error comes from.

roycegb wrote:

In this case I had a dead simple routine named 'test.ngc' that called a dead simple subroutine named 'my file.ngc'.

No idea if this is the issue, but easy to test so:
-no spaces in file names, this was an issue way back, not sure if it still is
-use a file name like: my_file.ngc

I have always had problems with named subroutines but lately I cannot get them to work at all.I get the following message;

LinuxCNC Error Near line 4 of/home/rpi-first-boot-wizard/linuxcnc/nc_files/Utility_G_Code/test.ngc:Failed to find sub 'Omyfile.ngc' before EOF

In this case I had a dead simple routine named 'test.ngc' that called a dead simple subroutine named 'my file.ngc'.

The location of the files and subroutines was called out in the .init file.

I have used named subroutines in the past.  I now use Raspberry Pi 4 and 5 with Axis 2.9.4 versions.

Any fool proof method for handling these subroutines would be appreciated.
I have a boat load of specializedsub routines lying dormant.

amanker wrote:

Thanks for reply. That changes resolved the issue of not compiling on trixie, there was also some error on line 505 column 69 of remora-spi.c. I edited that, I don't if that's correct, but that line will only be used in case of using rpi5, don't bothered and compiled the remora component. But still same issue on trixie and bookworm.

Hope some will help.
 

Sorry if I ask obvious things that you already checked, but what message do you have if you start LinuxCNC from a terminal, and then try to get out of emergency stop state? I don't have an SPI version, but on the Ethernet version I get an error message like "Bad SPI payload = 0" if I don't have communication with my board.

I saved some installation files; I meant to delete them, but because they contained important information, they remained.

andypugh wrote:

The problem with the RTAI kernels is that they are stuck at v5 and they don't have such good hardware support as the preempt-rt kernels.It is also possible that there is a problem with the 5.4.290 kernel as mentioned here:https://forum.linuxcnc.org/9-installing-linuxcnc/53163-new-and-working-rtai-debs-for-2-9?start=60
 
would that be it?1 drive.google.com/file/d/1BwlJet6ZcWpXvAUzD2YcM9vvnPTuclaX/view   2 drive.google.com/file/d/1xICFF-2mq_rz-vi.../view?usp=drive_link 3 drive.google.com/file/d/14Z10IOZI5bvgmf_.../view?usp=drive_link 4 drive.google.com/file/d/1fwGb5Qo9pw8lGLp.../view?usp=drive_link
 

andypugh wrote:

I couldn't resist trying to fix this. Here is a new version of lathemacro.ui that appears to work for me.

Until yesterday, I was stuck with a broken macros screen like this when I tried to access the macros:



I went through all 40 something pages of this thread and noted everything that could be remotely relevant, then ticked them all off. Nothing fixed the issue until I changed the following line in my .ini file, in particular the "-g 300x200+0+0" element, at which point the svgs appeared and all the spinwheels, keypad etc appeared and seemed to function:
EMBED_TAB_COMMAND=halcmd loadusr -Wn gladevcp gladevcp -c gladevcp -u lathehandler.py -x {XID} -g 300x200+0+0 lathemacro.ui



Of course, the play button is greyed out and doesn't function, as noted and discussed in the above thread around post 271603. I tried that modified version of lathemacro.ui posted by AndyP, hoping this would bring the play button to life but when I substituted it for my existing copy, it reverted to a similar "broken" screen like the first one.
Obviously one simple answer would be to fit a hardware switch, as preferred by AndyP but I thought I'd just check first - was that updated .ui file expected / intended to make the screen play button work? It's significantly different to the original 2022 .ui file when I do a file compare in VSC, so I've no idea where the critical changes actually lie. I looked at the .ui file in the Glade editor and in VSC and I can see it will take me some time to figure out what I'm looking at.

I found a seemingly cleaner way: I changed the function names to variables that I set to 1 or 0 at places in the program where I wanted to call the functions.
Then I moved my nested functions to the end of the halcomp and rewrote them into if() checking which variables are set.

My original purpose for functions had been to avoid having duplicate blocks of code each place I want to run that sequence. The if()'s at the end serve my need just as well.

The problem with the RTAI kernels is that they are stuck at v5 and they don't have such good hardware support as the preempt-rt kernels.

It is also possible that there is a problem with the 5.4.290 kernel as mentioned here:
forum.linuxcnc.org/9-installing-linuxcnc...-2-9?start=60#333143

5.4.279 is supposedly better, but I can't find it.

rodw wrote:

Life has got more complicated. With proper kernel tuning, latency can be better with Debian 13. I am in the process of publishing a second video about this on YouTube. Please refer to my channel. www.youtube.com/@MrRodW
The yet to be published video should be watched before the current one.

I watched the videos, and I have some information.
1. Every time I tried to do a clean install, it returned a firmware error rtl_nic/rtl8168h-2.fw, and I believe that because of this firmware error, the Windows boot option did not appear in GRUB. "When I learned about that utility you used, Balena Etcher, to create the installation pendrive, it solved the problem." Rufus with Windows was the cause of not creating the installation media 100%.
2. Some modifications suggested in the video did not have a better effect for me, and I believe it's because of my CPU; with Debian 13, I didn't have any success with PREEMPT_RT.

3. I did a new procedure with RTAI and observed that if I create a machine without spindle controls, I don't have crashes or the segfault error. But another issue arose: the created machine does not communicate with the LPT.

PCW wrote:

Pretty sure Tommylight has some example files using SSI feedback (which is very similar at the HAL level)

Yes of course, they are attached in the Elumatec SBZ130/01 retrofit page, not sure if i updated to the latest version so you might have to go through quite a long topic to check, although might not need the latest as the encoders were the first thing working, after the initial wiring. The latest should also have the toolchanger with grayscale feedback.

Thank you for your help, I'll check that right away.

 

Thanks for reply. That changes resolved the issue of not compiling on trixie, there was also some error on line 505 column 69 of remora-spi.c. I edited that, I don't if that's correct, but that line will only be used in case of using rpi5, don't bothered and compiled the remora component. But still same issue on trixie and bookworm.

Hope some will help.