- Posts: 62
- Thank you received: 0
In using ECR60+NPN(GPIO), I encountered an issue.
2 years 11 months ago #286748
by MakerYang
Replied by MakerYang on topic In using ECR60+NPN(GPIO), I encountered an issue.
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:
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:
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.
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.
Attachment not found
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:
Code:
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:
Code:
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.000
BASE_PERIOD = 200000
SERVO_PERIOD = 1000000
HOMEMOD = armcnc_home
Code:
#*******************
# 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.
Please Log in to join the conversation.
2 years 11 months ago #286756
by rodw
Replied by rodw on topic In using ECR60+NPN(GPIO), I encountered an issue.
I'm not sure if what you are expecting is normal behaviour.
I'm not sure that you require a custom homing module if you are homing using GPIO pins.
I don't whhen I home to a pin on the ethercat IO module I use.
I have attached my HAL. Its remarkably similar to yours except I set my signal names to be based on Slave/Joint numbers instead of XYZ.
You will see my home switches are connected to Slave 3, my I/O module
I have noticed that during homing, the DRO values are meaningless until it is homed.
But once homed, the machine is remarkably repeatable if asked to go to X0 Y0 in a new session if I set the coordinates with a probe in the previous session.
Drives are Rtelligent ECT86 (Nema 34 version of the ECT60)
I'm not sure that you require a custom homing module if you are homing using GPIO pins.
I don't whhen I home to a pin on the ethercat IO module I use.
I have attached my HAL. Its remarkably similar to yours except I set my signal names to be based on Slave/Joint numbers instead of XYZ.
You will see my home switches are connected to Slave 3, my I/O module
I have noticed that during homing, the DRO values are meaningless until it is homed.
But once homed, the machine is remarkably repeatable if asked to go to X0 Y0 in a new session if I set the coordinates with a probe in the previous session.
Drives are Rtelligent ECT86 (Nema 34 version of the ECT60)
Please Log in to join the conversation.
2 years 10 months ago #287162
by MakerYang
Replied by MakerYang on topic In using ECR60+NPN(GPIO), I encountered an issue.
This issue has not been resolved yet. It might be due to the fact that I am using open-loop stepper motors, and the XML and HAL configurations might not have been properly set up for this.
I now have a new problem that I need assistance with:
I have configured the start/stop and speed control of the spindle in the following way.
I encountered the following error.
When I test the 'armcncio' separately, I can control the spindle normally. However, when integrated into LinuxCNC, it results in an error. Where could the problem be?
I now have a new problem that I need assistance with:
I have configured the start/stop and speed control of the spindle in the following way.
Code:
loadrt [KINS]KINEMATICS
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[KINS]JOINTS
loadusr -W armcncio [TRAJ]COORDINATES
loadusr -W lcec_conf machine.xml
loadrt lcec
loadrt cia402 count=[KINS]JOINTS
loadrt debounce cfg=1,8
addf debounce.0 base-thread
addf debounce.1 base-thread
setp debounce.0.delay 100
setp debounce.1.delay 60
addf lcec.read-all servo-thread
addf cia402.0.read-all servo-thread
addf cia402.1.read-all servo-thread
addf cia402.2.read-all servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf cia402.0.write-all servo-thread
addf cia402.1.write-all servo-thread
addf cia402.2.write-all servo-thread
addf lcec.write-all servo-thread
#*******************
# AXIS X
#*******************
setp cia402.0.csp-mode 1
setp cia402.0.pos-scale [JOINT_0]SCALE
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-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
#*******************
# AXIS Y
#*******************
setp cia402.1.csp-mode 1
setp cia402.1.pos-scale [JOINT_1]SCALE
net y-statusword lcec.0.1.cia-statusword => cia402.1.statusword
net y-opmode-display lcec.0.1.opmode-display => cia402.1.opmode-display
net y-drv-act-pos lcec.0.1.actual-position => cia402.1.drv-actual-position
net y-drv-act-velo lcec.0.1.actual-velocity => cia402.1.drv-actual-velocity
net y-enable <= joint.1.amp-enable-out => cia402.1.enable
net y-pos-cmd <= joint.1.motor-pos-cmd => cia402.1.pos-cmd
net y-pos-fb <= joint.1.motor-pos-fb => cia402.1.pos-fb
net y-controlword cia402.1.controlword => lcec.0.1.cia-controlword
net y-modes-of-operation cia402.1.opmode => lcec.0.1.opmode
net y-drv-target-pos cia402.1.drv-target-position => lcec.0.1.target-position
net y-drv-target-velo cia402.1.drv-target-velocity => lcec.0.1.target-velocity
net debounce-home-y debounce.1.1.in <= armcncio.gpio.y-home
net both-home-y debounce.1.1.out
net both-home-y => joint.1.home-sw-in
net both-home-y => joint.1.neg-lim-sw-in
net both-home-y => joint.1.pos-lim-sw-in
#*******************
# AXIS Z
#*******************
setp cia402.2.csp-mode 1
setp cia402.2.pos-scale [JOINT_2]SCALE
net z-statusword lcec.0.2.cia-statusword => cia402.2.statusword
net z-opmode-display lcec.0.2.opmode-display => cia402.2.opmode-display
net z-drv-act-pos lcec.0.2.actual-position => cia402.2.drv-actual-position
net z-drv-act-velo lcec.0.2.actual-velocity => cia402.2.drv-actual-velocity
net z-enable <= joint.2.amp-enable-out => cia402.2.enable
net z-pos-cmd <= joint.2.motor-pos-cmd => cia402.2.pos-cmd
net z-pos-fb <= joint.2.motor-pos-fb => cia402.2.pos-fb
net z-controlword cia402.2.controlword => lcec.0.2.cia-controlword
net z-modes-of-operation cia402.2.opmode => lcec.0.2.opmode
net z-drv-target-pos cia402.2.drv-target-position => lcec.0.2.target-position
net z-drv-target-velo cia402.2.drv-target-velocity => lcec.0.2.target-velocity
net debounce-home-z debounce.1.2.in <= armcncio.gpio.z-home
net both-home-z debounce.1.2.out
net both-home-z => joint.2.home-sw-in
net both-home-z => joint.2.neg-lim-sw-in
net both-home-z => joint.2.pos-lim-sw-in
#*********************
# SPINDLE
#*********************
net spindle-rpm spindle.0.speed-out armcncio.gpio.spindle-pwm
# net spindle-enable spindle.0.on armcncio.gpio.spindle-enable
#*********************
# E-STOP
#*********************
net debounce-estop-ext debounce.1.5.in <= armcncio.gpio.estop
net estop-ext debounce.1.5.out
net estop-out <= iocontrol.0.user-enable-out
net estop-ext => iocontrol.0.emc-enable-in
I encountered the following error.
Code:
Debug file information:
Can not find -sec DISPLAY -var INTRO_GRAPHIC -num 1
Can not find -sec DISPLAY -var INTRO_TIME -num 1
Note: Using POSIX realtime
HAL: ERROR: signal 'spindle-rpm' already has output or I/O pin(s)
./machine.hal:110: link failed
9343
Stopping realtime threads
Unloading hal components
When I test the 'armcncio' separately, I can control the spindle normally. However, when integrated into LinuxCNC, it results in an error. Where could the problem be?
Please Log in to join the conversation.
Time to create page: 0.042 seconds