Advanced Search

Thanks! That was the problem.
I also set the P value back to 250 and FF1 to 0 and max output to 300.
The other settings were causing a following error, but now everything is working great and milling round circles now.

What is the program you were using to change the joint values in the video? Looks like you can change them without restarting linuxcnc?

I didn't tested by launching from terminal. But I tried with skr3 board which was tested working and octopus pro with newer(tmc5160) and regular remora both have same problem.

He did but you probably did not get a notification as he edited the existing post.

Share the gcode please, and we will take a look next week

Probably get no response, but figured I would try, I am currently in process of doing a similar retrofit and was trying to get a few more details on the homemade encoder for the spindle.  The fact that the OP has not posted here or on Youtube in three years makes me think I am SOL.

Thanks Chris,

I also notice previously I had 0 as deadband and the steppers all worked well. With 0 now they hunt 0.000 to 0.001 so are contstanly vibrating. I had to set the deadband to 0.001 to stop it. There are 6400 pules per rev and each rev is 5mm.

If you need anymore info please let me know.

Regards

Been poking at this a bit, finally got new ideas on this servo valve height control setup:

The servo valve pwm signal is basically a 'power' level command.
 The user interface commands position orders at more or less adjustable velocity.
 My PID controls position... I thought I might use pid.max-limit to control the velocity, but I do not expect that to work well for controlling non-linear hydraulics.

Aha! I think a second PID will serve the speed control. I have to try that.

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.