Advanced Search

Initialling I was thinking this was simply rounding error, but I think it is something else. The fact that I cant set the Zero properly tells me there is some underlying problem with my configs of some thing the way calulations are being done different with openloop steppers.

Some further info. Always getting following error on Z axis (Joint 2). I have upgrade the PC now and have done all the tuning with the Os and interrupts.

I have been a week now, working every day to try and get this going after upgrading from from I think was 2.4, which seemed to work flawlessly for a good number of years.

I have also tried going back to 2.8.0, but still get the errors and the Zero button not working correctly.

When running a short program with the Z going up and down to cros the top of clamps the program will never run through, it always stops with a joint following error.

The other error i am getting is if I set the Deaband to 0, which it was the steppers are always vibrating.

Wondering if there are other hal file setting that have chnage since the earlier version.

This is driving me insane.

Picture of screen hot in next message showing that the position cmd and the fb are the same.

All help would be greatly appreciated.

Sorry, I was confused in spi. I assumed that both board use same single spi without seeing it's board pin maps. But after seeing SKR3 pin map I found that it's using separate spi for config and comms. But in Octopus it's same for config and comms. Thanks for pointing out.

Rod seems on the right track, there are several missing files that might be there but will not be found as it seems the user name and subsequently the file path was different.
Old user name was
cncmrue

Your errors show that there are some missing file paths. There are probably defined in your ini file.
The most likely issue is you are using a new user name.

However, also Python V 2.7 used in 2.8 was deprecated. Later versions of Debian use Python 3
I thought there was also a python syntax error so you may need to convert your script to Python 3.

Estley wrote:

I swapped computers for a i5 and now it all works fine, thanks!!

Perfect!

Hello,
I try to use a machine, which was flawlessly working under LinuxCNC 2.8.4 (LinuxMint 19.3), in LinuxCNC 2.9.8 (LMDE6), but no success.
It is a basic Milling Machine (GMOCCAPY), with added support for VistaCNC-P4S and some python scripts and macros for tool touch off.

I tried the full featured ISO for Debian 13 Trixie with LinuxCNC 2.9.8, getting the exact same result (error).
I tried setting up a new machine using PNCconf, wich works fine. As soon as I add the necessary lines for either the VistaCNC-pendant OR the lines for the touch off, I am getting the attached error down below.
while starting the machine, I can hear the relais clicking, but the GUI never shows, the error prompts before.
I tried using the the new python scripts from the sim directory, but no success.

Can somebody sparky shine a light here? what exactly changed between LinuxCNC 2.8 and 2.9 to make those machines incompatible?

My Installation:
-LMDE6-ISO, checksum checked.
-sudo apt-get update / upgrade
-sudo apt install linuxcnc-uspace -> gave me 2.9.0 wich threw the same error and was not wanted.
-downloaded linuxcnc-uspace_2.9.8_amd64.deb from linxCNC.org
-sudo apt install mesaflash
-copying files for VistaCNC-P4S and "make install".

Any help appreciated! Many thanks!
Cheers.
Martin.

 

I swapped computers for a i5 and now it all works fine, thanks!!

I'm having a problem where after I zero-out the Z axis, some of the time, it seems to be "forgotten" when I run the program. Before running the program, I can jog to (0, 0, 0) and the tool tip is in the right place, but when I run the program, the tool either cuts way above (annoying, but no harm) or way below where it should (crash, piece ruined). I can't quite put my finger on workarounds like re-setting Z, re-loading the program, etc. Often the second time I run the program is works fine. The X and Y setting is always fine.
What could be going on here?
What can I do to get to the root cause?
All ideas are welcome. Thanks
 

It's not a laptop, it's an i3 mini PC, I'll swap it for a i5 I have laying around and see what happens.

I'm a huge fan of your videos, I was actually watching one of them when you replied!!

The Mesa configuration tool does not generate bitfiles, it uses existing bitfiles
If you need a 7I97+7I89 configuration I can build that but it may require dropping some
encoders. Do you need all 14 high speed encoders?

On the watchdog timeout, what error do you get from LinuxCNC?

(Easiest way to log these error is to start LinuxCNC from the command line
all error will be printed there.
 

7I80HD configurations (both -16 and -25) for 7I48+7I52

 

No PktUART support not sure if you expected MODBUS support on this
I can add this later if desired

Congratulations! Your work is appreciated.

Dear Chris,

i wanna thank you for your help at first.Ive put your file in the given path under the name vacuum_popup_handler.py as i thought its a own handler data for the popup, qtdragon_hd_handler.py is already the main handler data for the whole programm or did you mean to add it in the main code? Then i did the EMBED Part like

DISPLAY = qtvcp -d qtdragon_hd
EMBED_TAB_NAME = vacuum_popup
EMBED_TAB_COMMAND = qtvcp vacuum_popup
EMBED_TAB_LOCATION = DIALOG

I think this is the way u meant it. Ive also safed the vacuum_popup.ui under qtvcp/panels/vacuum_popup/vacuum_popup.ui.Ive posted the crash code. It tells me a TypeError "Wrong base class"

There are many factors that can cause your issue, often due to periodic background processes. Normally I would say set the coalescing settings but that seems to be OK from your data.
I did a video series on tuning the RT Kernel including network optimisation.This should fix it. 
youtube.com/playlist?list=PLG0NtQtZPZyo1...&si=XD8x3y7Zi9gPbya4