Advanced Search

Seems you are looking at 'gmoccapy' documentation for using 'halui' pins.

Halui documentation is here:
linuxcnc.org/docs/html/man/man1/halui.1.html#Rapid%20Override

However you should really be using the pins provided by gmoccapy for this purpose.
If unsure comment all lines in your hal files that give errors and use the 'Halshow' tool on the Settings page of Gmoccpy.
Using 2.9.7 I get this (which seems to agree with the documentation for Gmoccapy):
 

I configured a step configuration with the wizard

 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/realtime-5.4.258-rtai-amd64/modules/linuxcnc
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.3
Machine configuration directory is '/home/cnc/linuxcnc/configs/my-mill'
Machine configuration file is 'my-mill.ini'
INIFILE=/home/cnc/linuxcnc/configs/my-mill/my-mill.ini
VERSION=1.1
PARAMETER_FILE=linuxcnc.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
DISPLAY=gmoccapy
COORDINATES=X Y Z
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
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
Found file(REL): ./my-mill.hal
Found file(REL): ./custom.hal
Starting TASK program: milltask
Starting DISPLAY program: gmoccapy
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
ERROR: Can't remove RTAI modules, kill the following process(es) first
1563Removing NML shared memory segments

Debug file information:
Exception ignored error evaluating path:
Traceback (most recent call last):
File "<frozen getpath>", line 575, in <module>
File "<frozen getpath>", line 210, in search_up
File "<frozen getpath>", line 210, in <genexpr>
ValueError: embedded null character
Fatal Python error: error evaluating path
Python runtime state: core initialized

Current thread 0x00007fb818429040 (most recent call first):
<no Python frame>
/usr/bin/linuxcnc: line 665: 1572 Segmentation fault $PIDOF $KILL_TASK >> $DEBUG_FILE
Traceback (most recent call last):
File "/usr/bin/axis-remote", line 26, in <module>
import sys, getopt, os
import sys, getopt, os
File "/usr/lib/python3.11/getopt.py", line 38, in <module>
from gettext import gettext as _
File "/usr/lib/python3.11/gettext.py", line 50, in <module>
import re
File "/usr/lib/python3.11/re/__init__.py", line 124, in <module>
import enum
File "/usr/lib/python3.11/enum.py", line 3, in <module>
from types import MappingProxyType, DynamicClassAttribute
SystemError: error return without exception set
1511
/usr/bin/linuxcnc: line 620: [: -gt: unary operator expected
1567
malloc(): unsorted double linked list corrupted
Stopping realtime threads
Unloading hal components
Waiting for component 'inihal' to become ready...................... USER PID ACCESS COMMAND
/dev/rtai_shm: cnc ....m halcmd
................
Kernel message information:
[ 511.133992] I-pipe: head domain RTAI registered.
[ 511.133998] RTAI[hal]: mounted. ISOL_CPUS_MASK: 0.
[ 511.134006] SYSINFO - # CPUs: 1, TIMER NAME: 'lapic', TIMER IRQ: 4355, TIMER FREQ: 10390249, CLOCK NAME: 'tsc', CLOCK FREQ: 1662499000, CPU FREQ: 1662499000, LINUX TIMER IRQ: 4355.
[ 511.186056] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[ 511.186122] kstacks pool size = 524288 bytes
[ 511.186133] RTAI[sched]: hard timer type/freq = lapic/10390249(Hz)
[ 511.186136] linear timed lists.
[ 511.186139] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 1662499000 hz.
[ 511.186142] RTAI[sched]: timer setup = 96 ns, resched latency = 0 ns.
[ 511.222685] USERMODE CHECK: OK.
[ 511.222690] USERMODE CHECK PROVIDED (ns): KernelLatency 4491, UserLatency 1954.
[ 511.222694] FINAL CALIBRATION SUMMARY (ns): KernelLatency 4491, UserLatency 1954.
[ 511.361573] RTAI[math]: loaded integrated musl libm version 1.2.3.
[ 511.767184] config string '0 out'
[ 512.090484] hal_manualtoolc[1557]: segfault at ab ip 0000000000561d90 sp 00007ffc12846810 error 4 in python3.11[41f000+2b3000]
[ 512.090506] Code: 40 08 48 85 c0 0f 85 7f 00 00 00 49 81 ff c0 9c 95 00 74 09 4d 85 ff 0f 85 9c 00 00 00 48 85 db 0f 84 1c 02 00 00 48 8b 43 08 <f6> 80 ab 00 00 00 40 0f 85 83 01 00 00 4d 85 ed 74 05 49 83 45 00
[ 512.189738] pidof[1572]: segfault at 18 ip 00007f6219198087 sp 00007ffe7fc3ec70 error 4 in libc.so.6[7f6219129000+156000]
[ 512.189756] Code: 1f 40 00 48 83 ec 08 48 8b 4f 08 48 89 c8 48 83 e0 f8 48 3b 04 07 0f 85 a9 00 00 00 f3 0f 6f 47 10 48 8b 57 18 66 48 0f 7e c0 <48> 3b 78 18 75 7b 48 3b 7a 10 75 75 48 8b 77 10 48 89 50 18 66 0f

Edit: i ran the command halrun -U
I think the rtapi module is not loaded
 
 

Mayby some GTK, GDK, Python3 package is missing.

Hi i'm trying to open a sim config on 12 inch monitor with 1024x768 at 4:3 but gmoccapy gives and error with every sim config.
I tried even the 800x600 but the same error.
I tried axis and it works but the windows is bigger than the display.
The system is debian 12 si linux cnc 2.9.3 and rtai kernel 5.4.258
btw why the forum gives me and error when i try to put the code ?(You have too many links in your message, please decrease them! )
I uploaded the error code.
 

I will also need to build a specific file for linuxcnc to recognize the board right? Is there any documentation about this?

To connect encoders, the following pins are exported:

gmoccapy.jog.jog-velocity.counts (s32 IN) - Jog velocity

gmoccapy.jog.jog-velocity.count-enable (bit IN) - Must be True, to enable counts

gmoccapy.feed.feed-override.counts (s32 IN) - feed override

gmoccapy.feed.feed-override.count-enable (bit IN) - Must be True, to enable counts

gmoccapy.feed.reset-feed-override (bit IN) - reset the feed override to *0%

gmoccapy.spindle.spindle-override.counts (s32 IN) - spindle override

gmoccapy.spindle.spindle-override.count-enable (bit IN) - Must be True, to enable counts

gmoccapy.spindle.reset-spindle-override (bit IN) - reset the spindle override to *0%

gmoccapy.rapid.rapid-override.counts (s32 IN) - Maximal Velocity of the *chine

gmoccapy.rapid.rapid-override.count-enable (bit IN) - Must be True, to enable counts

linuxcnc.org/docs/html/gui/gmoccapy.html

Its really important to read the instructions for the version of LInuxcnc you are using. Often a Google search will display dated info

Instead of rapid.rapid-override, it should be rapid-override.

What manual is this in and what LinuxCNC verison?

(the current halui man page does not have this error)

how about these instructions?
github.com/LinuxCNC/linuxcnc/blob/2.9/li.../designer/README.txt

Thanks for that.

With a bit of fiddling I have some code that is doing the job....
My halui was set up like this

[HALUI]
# add halui MDI commands here (max 64)
MDI_COMMAND = O<b01-go_to_switches> call
MDI_COMMAND = O<b02-go_to_wco> call
MDI_COMMAND = G10 L20 P0 X0 # zero x axis
MDI_COMMAND = G10 L20 P0 Y0 # zero y axis
MDI_COMMAND = G10 L20 P0 Z0 # zero z axis

and the code for the buttons ended up looking like this...

#

---

# Buttons to zero the axis of the machine.
#

---

addf AND-zero-x servo-thread
addf AND-zero-y servo-thread
addf AND-zero-z servo-thread

net zero-button <= input.0.btn-base3 => AND-zero-x.in0 => AND-zero-y.in0 => AND-zero-z.in0
net x-btn <= AND-zero-x.in1 <= input.0.btn-trigger
net y-btn <= AND-zero-y.in1 <= input.0.btn-thumb
net z-btn <= AND-zero-z.in1 <= input.0.btn-base

net zero-x <= AND-zero-x.out => halui.mdi-command-02
net zero-y <= AND-zero-y.out => halui.mdi-command-03
net zero-z <= AND-zero-z.out => halui.mdi-command-04

I'll post the files for anyone who is interested.

Thanks
Alex
 

Another mystery solved: My 7i54 pwm output to the proportional valve was extremely erratic, like all over its output range. I was ready to blame RFI/EMI interference problems, except only that channel was affected, everything else is very stable. I finally traced it to the snubber circuit on the solenoid coil. I removed that, then it worked fine. Now I have the ram jogging up and down open loop. It appears this rc snubber was messing with the current regulation. Attached a picture of it. It was sandwiched between the connector on the solenoid coil and the Hirschman plug. With that installed, its LED indicator flickered like a candle flame in a breeze whenever pwm output was live. The Ursviken schematics indicate the circuit contains a flyback diode, but I could not find any, neither does it seem to show up when I reverse the h-bridge. The snubber is unnecessary in this instance, I am powering it with an h-bridge designed for DC servo motors. A DC servo motor would not have this additional snubber anyway.

My suspicion has been confirmed: The 2 servo valves set the speed and direction of each ram cylinder. The proportional relief valve sets the tonnage. 0% pwm = no pressure, 100% pwm = max pressure.

I will edit my first post with this info. Once I have a complete working config, that will also be attached to the first post.

What inaccuracies? In the documentation?

I conducted a large series of experiments with different sensor settings and different ini + hal settings.
First, I achieved smooth operation of the sensor (of my own design) in version 2.8.4. The Chinese sensor could perform 40,000-50,000 continuous measurements (with 38.5 disabled). My sensor completed the entire task, more than 500,000.
That is, it has been established that the quality of the sensor directly affects the appearance of the error “Probe tripped during non-probe move”.
And with the same settings in version 2.9.7, the error “Queue is not empty after probing” recurs. That is, the appearance of the error does not depend on the sensor. The question remained: does this error appear during the working stroke 38.2-38.3 and the reverse?
I disabled the “until open” movement option, as in version 2.8.4, and the error “Queue is not empty after probing” did not appear. Previously, it was not possible to obtain more than 25,000 measurements. The experiment was interrupted at 40,000. Consequently, the error “Queue is not empty after probing” occurs when executing g38.5, during execution. After g38.3, I have a G1 up command.

To disable the possibility of 38.4-38.5 on the defunct Russian forum (к сожалению, я не помню имени автора решения, но честь ему и хвала), such a modification of hal was proposed and tested by me over hundreds of hours of work and hundreds of thousands of measurements -

Yes, I thought you wanted to use it in linuxcnc. That's how.
I'll tell you about dc synchronization tomorrow. It's a bit more writing and more code.