I'll provide a detailed explanation of some of the things I'm currently working on and the issues I've encountered:
1、Python is not used for real-time processing tasks. Its role is solely to read and invoke relevant APIs from the LinuxCNC Python module, as I have rewritten the GUI using HTML.
2、I use the ECR60 to drive stepper motors, and I haven't connected the NPN limit switches to the ECR60's IO; instead, I've connected them to the GPIO pins on the Raspberry Pi.
3、To display the position information of each axis in the HTML GUI and the calculation formula for tool position simulation, here are the details:
actual_position[i] - g5x_offset[i] - tool_offset[i] - g92_offset[i]
Based on the above situation, the motor control and the triggering of the NPN limit switches are working perfectly fine. The axis position information obtained during normal machining processes is accurate. Now, the issues I am encountering are as follows:
1、After triggering the NPN limit switches, the motors rotate as expected, but there is no change in the data for actual_position
. This results in a lack of synchronization in the axis position information and tool position simulation displayed in the HTML GUI.
I also tried some experiments based on your feedback:
1、I compiled a component named "armcnc_home" following the documentation (linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html) and made relevant configurations in the INI and HAL files, but it seems like it didn't provide any effective assistance:
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.000
BASE_PERIOD = 200000
SERVO_PERIOD = 1000000
HOMEMOD = armcnc_home
#*******************
# AXIS X
#*******************
setp cia402.0.csp-mode 1
setp cia402.0.pos-scale 10000
net x-statusword lcec.0.0.cia-statusword => cia402.0.statusword
net x-opmode-display lcec.0.0.opmode-display => cia402.0.opmode-display
net x-drv-act-pos lcec.0.0.actual-position => cia402.0.drv-actual-position
net x-drv-act-velo lcec.0.0.actual-velocity => cia402.0.drv-actual-velocity
net x-enable <= joint.0.amp-enable-out => cia402.0.enable
net x-amp-fault => joint.0.amp-fault-in <= cia402.0.drv-fault
net x-pos-cmd <= joint.0.motor-pos-cmd => cia402.0.pos-cmd
net x-pos-fb => joint.0.motor-pos-fb <= cia402.0.pos-fb
net x-controlword cia402.0.controlword => lcec.0.0.cia-controlword
net x-modes-of-operation cia402.0.opmode => lcec.0.0.opmode
net x-drv-target-pos cia402.0.drv-target-position => lcec.0.0.target-position
net x-drv-target-velo cia402.0.drv-target-velocity => lcec.0.0.target-velocity
net debounce-home-x debounce.1.0.in <= armcncio.gpio.x-home
net both-home-x debounce.1.0.out
net both-home-x => joint.0.home-sw-in
net both-home-x => joint.0.neg-lim-sw-in
net both-home-x => joint.0.pos-lim-sw-in
# Here are the two added configurations:
net x-request-custom-homing <= joint.0.request-custom-homing
net x-is-custom-homing => joint.0.is-custom-homing
2、After triggering the NPN limit switches, during the homing process, I observed that the data from the "LinuxCNC Python module" API, including "joint," "joint_actual_position," and "joint_position," are continuously changing in real-time. I was considering using these values for synchronizing the axis position information and tool position simulation in the HTML GUI. However, I've noticed that after each LinuxCNC restart, the values of "joint
.ferror_highmark," "joint_actual_position," and "joint_position" become extremely large. I believe that my idea of using these values for synchronization in the HTML GUI is not correct.
3、The values of "actual_position" only change after the homing process has been completed.
After these few days of tinkering, things seem to have become more complicated, and my goal is simply to ensure that the correct axis position information is displayed in the HTML GUI during the homing process. I appreciate the discussions and support you've provided regarding my issue, but I've only been working with LinuxCNC for three months, and my understanding of LinuxCNC is still at a shallow level. Therefore, I'm currently struggling to pinpoint where the problem might be occurring.
Thank you very much.