Advanced Search

Not able to help here but this is a continuation of the deprecation of Python 2.7 back when Debian Bullseye (v 11) was released. You need to convert your handler to Python 3. 

Inside the Basic.hal file, you have trivkins called twice as noted in the error report
"trivkins: already exists"

Update:
i have copied the "working" fies from page 1 into my axis.sim folder, removed the date in their names and put the Basic.hal to be called in the axis.ini file. now the axis.sim does not start and i get this error log: 
Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.8
Machine configuration directory is '/home/christian/linuxcnc/configs/sim.axis'
Machine configuration file is 'axis.ini'
INIFILE=/home/christian/linuxcnc/configs/sim.axis/axis.ini
VERSION=1.1
PARAMETER_FILE=sim.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(lib): /usr/share/linuxcnc/hallib/core_sim.hal
Found file(lib): /usr/share/linuxcnc/hallib/sim_spindle_encoder.hal
Found file(lib): /usr/share/linuxcnc/hallib/axis_manualtoolchange.hal
Found file(lib): /usr/share/linuxcnc/hallib/simulated_home.hal
Found file(lib): /usr/share/linuxcnc/hallib/check_xyz_constraints.hal
Found file(REL): ./cooling.hal
Found file(REL): ./Basic.hal
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
trivkins: already exists
./Basic.hal:3: waitpid failed /usr/bin/rtapi_app trivkins
./Basic.hal:3: /usr/bin/rtapi_app exited without becoming ready
./Basic.hal:3: insmod for trivkins failed, returned -1
2381
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

Hi maruf1777,

I’m an engineer with Teknic and I came across your thread. There are a lot of good recommendations from other users, and it looks like you’ve got some solid next steps to test. If you want direct help from Teknic, feel free to contact us at 585‑784‑7454 or www.teknic.com/contact/ and one of our engineers will be happy to assist.

Also to build on dbtayl’s quadrature note: when ClearPath is set to quadrature input, it treats each edge transition on the A and B signals as a count. So if you keep the same command resolution (counts/rev), the required signal rate on each line is actually 1/4 the pulse frequency you'd need when using step & direction. If your Mesa card supports quadrature output, you can set ClearPath’s Input Format to Quadrature in ClearPath‑MSP, which can help if you’re running into pulse‑rate limits or signal‑integrity issues.

Best regards,
Nick D. - Teknic Servo Systems Engineer

Stimmt das ist Pflicht 

At 75 and 185mVPP, those look like noise, not a signal of any kind, although the first one is weirdly clean sinusoidal.

thank you for this very helpfull hint!! it´s back online!!

the grandixximo repo did it!

cheers

miniwini

 

OK if you have +24V on TB1 pin 5 relative to TB1 pin 8
and no red LED above TB1 when LinuxCNC is not running,
The 7I76EUs field I/O section has failed or been damaged.

Lcvette wrote:

Maybe send as screen shot of your roster settings and probe page settings as well as your z travel.

Attached. I think this is what you were asking for.

Also have you edited your var file and added all of the parameter numbers shown in the probe basic docs so the settings are persistent?

Yes, my ini includes a ref to the var file. Settings are persistent across executions of LinuxCNC. Or at least I think so.

github.com/kello711/linuxcnc/blob/main/c...ntnc/probe_basic.var

Lcvette wrote:

Where is your zero home in z

Zero is at the top of travel with -6.3 at the bottom.

The first thing I'd try is to load your glade file in the Glade (Version 3) editor and save it.

Also check for error output when starting your config from a terminal.

Der groesste Vorteil fuer mich bei einem EtherCAT System ist die Nutzung von Servos mit Absolut-Encoder. Maschine starten, LinuxCNC liesst die aktuelle absolute Position, "Home All" druecken, fertig (nichts verfaehrt da absolut). Selbst diesen Schritt koennte man sich mit ein paar Verbindungen in der HAL sparen und gleich bei "Machine On" bereit sein.

Falls das gewerblich genutzt werden soll dann nur Servos mit STO.

Also Empfehlung meinerseits.
Wenn A6 dann richtig!
Bestellt zu den Servos die Encodercabel mit Batteriebox, erspart euch jede menge Ärger.
Die Servos dann auf Absolutwert Multiturn umstellen und noch ein einziges mal das Homing durchführen. 
Derzeit sieht es leider so aus, dass der Ethercat hall Treiber, sowie die CIA402 Homing Komponenten noch eine große Baustelle sind.
Es gibt zwar hierzu Entwicklungen, aber keiner weiß, wann die in den Hauptzeig einfließen. Näheres zu den Problemen sind im englischen Teil zu finden.
Zum EMV:
EMV ist ein richtiges Problem, ich hatte hier zu kämpfen bevor die Ausgabe von dmesg fehlerfrei war, dennoch reagieren die Servos empfindlich auf Störungen. 
Die empfohlenen Netzfilter für jeden Servo findet ihr Hier:
Stepperonline-A6
Netzwerkkabel Cat 6 sind Pflicht, besser Industriestandart und diese mit Feritkernen entstören, keine Schlaufen legen.
Netzwerkkarte mit Intelchip benutzen. Hier einfach mal bei Beckhoff vorbeischauen, die haben eine Liste mit Zertifizierten Chips.
Andere Karten gehen auch, aber können Probleme machen. 

I had a similar issue. Was running an older linuxcnc-ethercat version - which worked well but when I went to the latest version to address the "random jitter" issue it crashed with signal 11.

forum.linuxcnc.org/ethercat/58103-etherc...-fix?start=60#344310

Try grandixximo's linuxcnc-ethercat repo - which has the "jitter fix" and the "zero-initialized" fix.

Make your custom mods and compile:

github.com/grandixximo/linuxcnc-ethercat

I'm still not getting anywhere with this. This GadeVCP worked fine with Linuxcnc 2.7 on Debian 7, but on the upgraded control PC running Linuxcnc 2.9 on Debian 13, The Python handler file doesn't seem to work. The problem is that it isn't creating any of the hal pins that it used to.  I've tried this with several different GladeVCPs that I had created a number of years ago for these machines. and all of them are giving similar issues.